Bluecoat Admin guide

July 21, 2016 | Author: netleets | Category: N/A

Short Description

Bluecoat 2.2 Admin Guide Brought to you by Netleets.com...

Description

Blue Coat® Systems SG™ Appliance

Volume 1: Getting Started

SGOS Version 5.2.2

Volume 1: Getting Started

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02838 Document Revision: SGOS 5.2.2—09/2007

ii

Third Party Copyright Notices

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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. 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 `ÀS 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.

iii

Blue Coat

UNIX is a registered trademark in the US and other countries, licensed exclusively through X/Open Company Ltd. MD5 RSA Data Security, Inc. MD5 Message-Digest Algorithm Copyright (c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing this software or this function. License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind. THE BEER-WARE LICENSE" (Revision 42): wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp Microsoft Windows Media Streaming Copyright (c) 2003 Microsoft Corporation. All rights reserved. Novell and eDirectory are [either] registered trademarks [or] trademarks of Novell, Inc. in the United States and other countries. LDAPSDK.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. LDAPSSL.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. LDAPX.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. The following are copyrights and licenses included as part of Novell's LDAP Libraries for C: HSpencer Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California. Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and redistribute it, subject to the following restrictions: 1. The author is not responsible for the consequences of use of this software, no matter how awful, even if they arise from flaws in it. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever read sources, credits must appear in the documentation. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. Since few users ever read sources, credits must appear in the documentation. 4. This notice may not be removed or altered. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Copyright (c) 1994 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS `ÀS 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. @(#)COPYRIGHT

8.1 (Berkeley) 3/16/94

OpenLDAP Copyright 1998,1999 The OpenLDAP Foundation, Redwood City, California, USA All rights reserved. Redistribution and use in source and binary forms are permitted only as authorized by the OpenLDAP Public License. A copy of this license is available at http://www.OpenLDAP.org/license.html or in file LICENSE in the top-level directory of the distribution. Individual files and/or contributed packages may be copyright by other parties and use subject to additional restrictions. This work is derived from the University of Michigan LDAP v3.3 distribution. Information concerning is available at http://www.umich.edu/~dirsvcs/ldap/ldap.html.

iv

Copyrights

This work also contains materials derived from public sources. Additional Information about OpenLDAP can be obtained at: http://www.openldap.org/ or by sending e-mail to: [email protected] Portions Copyright (c) 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided `às is'' without express or implied warranty. The OpenLDAP Public License Version 2.0.1, 21 December 1999 Copyright 1999, The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. 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. Redistributions must also contain a copy of this document. 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. The name "OpenLDAP" must not be used to endorse or promote products derived from this Software without prior written permission of the OpenLDAP Foundation. For written permission, please contact [email protected]. 4. Products derived from this Software may not be called "OpenLDAP" nor may "OpenLDAP" appear in their names without prior written permission of the OpenLDAP Foundation. OpenLDAP is a trademark of the OpenLDAP Foundation. 5. Due credit should be given to the OpenLDAP Project (http://www.openldap.org/. THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND CONTRIBUTORS `ÀS 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 OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 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. LICENSE ISSUES ============== The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected]. OpenSSL License --------------==================================================================== Copyright (c) 1998-2000 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected]. 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 `ÀS 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. ====================================================================

v

Blue Coat

This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]). Original SSLeay License ----------------------Copyright (C) 1995-1998 Eric Young ([email protected]) All rights reserved. This package is an SSL implementation written by Eric Young ([email protected]). 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 aheared 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 ([email protected]). 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 ([email protected])" The word 'cryptographic' can be left out if the rouines 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 ([email protected])" THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS 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 licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.] [end of copyrights and licenses for Novell's LDAP Libraries for C] 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 `ÀS 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.

vi

Copyrights

1) As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell". [Tatu continues] However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that are not under my direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and can be used freely for any purpose (the GNU license being the most restrictive); see below for details. [However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he talks about have been removed from OpenSSH, i.e., - RSA is no longer included, found in the OpenSSL library - IDEA is no longer included, its use is deprecated - DES is now external, in the OpenSSL library - GMP is no longer used, and instead we call BN code from OpenSSL - Zlib is now external, in a library - The make-ssh-known-hosts script is no longer included - TSS has been removed - MD5 is now external, in the OpenSSL library - RC4 support has been replaced with ARC4 support from OpenSSL - Blowfish is now external, in the OpenSSL library [The licence continues] Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major bookstore, scientific library, and patent office worldwide. More information can be found e.g. at "http://www.cs.hut.fi/crypto". The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility. You will be responsible for any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in your country, and I am not taking any responsibility on your behalf. NO WARRANTY BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license. Cryptographic attack detector for ssh - source code Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF THIS SOFTWARE. Ariel Futoransky 3) ssh-keygen was contributed by David Mazieres under a BSD-style license. Copyright 1995, 1996 by David Mazieres . Modification and redistribution in source and binary forms is permitted provided that due credit is given to the author and the OpenBSD project by leaving this copyright notice intact. 4) The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public domain and distributed with the following license: @version 3.0 (December 2000) Optimised ANSI C code for the Rijndael cipher (now AES) @author Vincent Rijmen @author Antoon Bosselaers @author Paulo Barreto This code is hereby placed in the public domain. THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

vii

Blue Coat

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 `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 6) Remaining components of the software are provided under a standard 2-term BSD licence with the following names as copyright holders: Markus Friedl Theo de Raadt Niels Provos Dug Song Aaron Campbell Damien Miller Kevin Steves Daniel Kouril Wesley Griffin Per Allansson Nils Nordman Simon Wilkinson Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE AUTHOR `ÀS 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 ([email protected]). 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 ([email protected]). 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 ([email protected]). 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.

viii

Copyrights

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 ([email protected])" 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 ([email protected])" THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License.] Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected]. 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 `ÀS 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 ([email protected]). This product includes software written by Tim Hudson ([email protected]). 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.

ix

Blue Coat

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: 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 `ÀS 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.

x

Copyrights

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

xi

Blue Coat

The SG Client software is based in part on the work of the Independent JPEG Group The SG Client software is based in part on the work of the FreeType Project (www.freetype.org) The SG Client software is based in part on the work of Chris Maunder and info-zip LEGAL ISSUES ============ In plain English: 1. We don't promise that this software works. (But if you find any bugs, please let us know!) 2. You can use this software for whatever you want. You don't have to pay us. 3. You may not pretend that you wrote this software. If you use it in a program, you must acknowledge somewhere in your documentation that you've used the IJG code. In legalese: The authors make NO WARRANTY or representation, either express or implied, with respect to this software, its quality, accuracy, merchantability, or fitness for a particular purpose. This software is provided "AS IS", and you, its user, assume the entire risk as to its quality and accuracy. This software is copyright (C) 1991-1998, Thomas G. Lane. All Rights Reserved except as specified below. Permission is hereby granted to use, copy, modify, and distribute this software (or portions thereof) for any purpose, without fee, subject to these conditions: (1) If any part of the source code for this software is distributed, then this README file must be included, with this copyright and no-warranty notice unaltered; and any additions, deletions, or changes to the original files must be clearly indicated in accompanying documentation. (2) If only executable code is distributed, then the accompanying documentation must state that "this software is based in part on the work of the Independent JPEG Group". (3) Permission for use of this software is granted only if the user accepts full responsibility for any undesirable consequences; the authors accept NO LIABILITY for damages of any kind. These conditions apply to any software derived from or based on the IJG code, not just to the unmodified library. If you use our work, you ought to acknowledge us. Permission is NOT granted for the use of any IJG author's name or company name in advertising or publicity relating to this software or products derived from it. This software may be referred to only as "the Independent JPEG Group's software". We specifically permit and encourage the use of this software as the basis of commercial products, provided that all warranty or liability claims are assumed by the product vendor. ansi2knr.c is included in this distribution by permission of L. Peter Deutsch, sole proprietor of its copyright holder, Aladdin Enterprises of Menlo Park, CA. ansi2knr.c is NOT covered by the above copyright and conditions, but instead by the usual distribution terms of the Free Software Foundation; principally, that you must include source code if you redistribute it. (See the file ansi2knr.c for full details.) However, since ansi2knr.c is not needed as part of any program generated from the IJG code, this does not limit you more than the foregoing paragraphs do. The Unix configuration script "configure" was produced with GNU Autoconf. It is copyright by the Free Software Foundation but is freely distributable. The same holds for its supporting scripts (config.guess, config.sub, ltconfig, ltmain.sh). Another support script, install-sh, is copyright by M.I.T. but is also freely distributable. It appears that the arithmetic coding option of the JPEG spec is covered by patents owned by IBM, AT&T, and Mitsubishi. Hence arithmetic coding cannot legally be used without obtaining one or more licenses. For this reason, support for arithmetic coding has been removed from the free JPEG software. (Since arithmetic coding provides only a marginal gain over the unpatented Huffman mode, it is unlikely that very many implementations will support it.) So far as we are aware, there are no patent restrictions on the remaining code. The IJG distribution formerly included code to read and write GIF files. To avoid entanglement with the Unisys LZW patent, GIF reading support has been removed altogether, and the GIF writer has been simplified to produce "uncompressed GIFs". This technique does not use the LZW algorithm; the resulting GIF files are larger than usual, but are readable by all standard GIF decoders. We are required to state that "The Graphics Interchange Format(c) is the Copyright property of CompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServe Incorporated." The FreeType Project LICENSE 2006-Jan-27 Copyright 1996-2002, 2006 by David Turner, Robert Wilhelm, and Werner Lemberg Introduction ========= The FreeType Project is distributed in several archive packages; some of them may contain, in addition to the FreeType font engine, various tools and contributions which rely on, or relate to, the FreeType Project. This license applies to all files found in such packages, and which do not fall under their own explicit license. The license affects thus the FreeType font engine, the test programs, documentation and makefiles, at the very least. This license was inspired by the BSD, Artistic, and IJG (Independent JPEG Group) licenses, which all encourage inclusion and use of free software in commercial and freeware products alike. As a consequence, its main points are that: o We don't promise that this software works. However, we will be interested in any kind of bug reports. (às is' distribution) o You can use this software for whatever you want, in parts or full form, without having to pay us. (`royalty-free' usage) o You may not pretend that you wrote this software. If you use it, or only parts of it, in a program, you must acknowledge somewhere in your documentation that you have used the FreeType code. (`credits') We specifically permit and encourage the inclusion of this software, with or without modifications, in commercial products. We disclaim all warranties covering The FreeType Project and assume no liability related to The FreeType Project.

xii

Copyrights

Finally, many people asked us for a preferred form for a credit/disclaimer to use in compliance with this license. We thus encourage you to use the following text: “Portions of this software are copyright (c) 2007The FreeType Project (www.freetype.org). All rights reserved." Legal Terms ========= 0. Definitions Throughout this license, the terms `package', `FreeType Project', and `FreeType archive' refer to the set of files originally distributed by the authors (David Turner, Robert Wilhelm, and Werner Lemberg) as the `FreeType Project', be they named as alpha, beta or final release. `You' refers to the licensee, or person using the project, where ùsing' is a generic term including compiling the project's source code as well as linking it to form a `program' or èxecutable'. This program is referred to as à program using the FreeType engine'. This license applies to all files distributed in the original FreeType Project, including all source code, binaries and documentation, unless otherwise stated in the file in its original, unmodified form as distributed in the original archive. If you are unsure whether or not a particular file is covered by this license, you must contact us to verify this. The FreeType Project is copyright (C) 1996-2000 by David Turner, Robert Wilhelm, and Werner Lemberg. All rights reserved except as specified below. 1. No Warranty THE FREETYPE PROJECT IS PROVIDED ÀS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL ANY OF THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY DAMAGES CAUSED BY THE USE OR THE INABILITY TO USE, OF THE FREETYPE PROJECT. 2. Redistribution This license grants a worldwide, royalty-free, perpetual and irrevocable right and license to use, execute, perform, compile, display, copy, create derivative works of, distribute and sublicense the FreeType Project (in both source and object code forms) and derivative works thereof for any purpose; and to authorize others to exercise some or all of the rights granted herein, subject to the following conditions: o Redistribution of source code must retain this license file (`FTL.TXT') unaltered; any additions, deletions or changes to the original files must be clearly indicated in accompanying documentation. The copyright notices of the unaltered, original files must be preserved in all copies of source files. o Redistribution in binary form must provide a disclaimer that states that the software is based in part of the work of the FreeType Team, in the distribution documentation. We also encourage you to put an URL to the FreeType web page in your documentation, though this isn't mandatory. These conditions apply to any software derived from or based on the FreeType Project, not just the unmodified files. If you use our work, you must acknowledge us. However, no fee need be paid to us. 3. Advertising Neither the FreeType authors and contributors nor you shall use the name of the other for commercial, advertising, or promotional purposes without specific prior written permission. We suggest, but do not require, that you use one or more of the following phrases to refer to this software in your documentation or advertising materials: `FreeType Project', `FreeType Engine', `FreeType library', or `FreeType Distribution'. As you have not signed this license, you are not required to accept it. However, as the FreeType Project is copyrighted material, only this license, or another one contracted with the authors, grants you the right to use, distribute, and modify it. Therefore, by using, distributing, or modifying the FreeType Project, you indicate that you understand and accept all the terms of this license. 4. Contacts There are two mailing lists related to FreeType: o [email protected] Discusses general use and applications of FreeType, as well as future and wanted additions to the library and distribution. If you are looking for support, start in this list if you haven't found anything to help you in the documentation. o [email protected] Discusses bugs, as well as engine internals, design issues, specific licenses, porting, etc. Our home page can be found at http://www.freetype.org ====================== zip.cpp—which is used by the Data Collector utility included in the SG Client software—is almost entirely based upon code by info-zip. It has been modified by Lucian Wischik. The modifications were a complete rewrite of the bit of code that generates the layout of the zipfile, and support for zipping tofrom memory or handles or pipes or pagefile or diskfiles, encryption, unicode. The original code may be found at http:www.info-zip.org. The original copyright text follows. This is version 1999-Oct-05 of the Info-ZIP copyright and license. The definitive version of this document should be available at ftp:ftp.cdrom.compubinfoziplicense.html indefinitely. Copyright (c) 1990-1999 Info-ZIP. All rights reserved. For the purposes of this copyright and license, "Info-ZIP" is defined as the following set of individuals: Mark Adler, John Bush, Karl Davis, Harald Denker, Jean-Michel Dubois, Jean-loup Gailly, Hunter Goatley, Ian Gorman, Chris Herborth, Dirk Haase, Greg Hartwig, Robert Heath, Jonathan Hudson, Paul Kienitz, David Kirschbaum, Johnny Lee, Onno van der Linden, Igor Mandrichenko, Steve P. Miller, Sergio Monesi, Keith Owens, George Petrov, Greg Roelofs, Kai Uwe Rommel, Steve Salisbury, Dave Smith, Christian Spieler, Antoine Verheijen, Paul von Behren, Rich Wales, Mike White This software is provided "as is," without warranty of any kind, express or implied. In no event shall Info-ZIP or its contributors be held liable for any direct, indirect, incidental, special or consequential damages arising out of the use of or inability to use this software.

xiii

Blue Coat

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. Redistributions of source code must retain the above copyright notice, definition, disclaimer, and this list of conditions. 2. Redistributions in binary form must reproduce the above copyright notice, definition, disclaimer, and this list of conditions in documentation andor other materials provided with the distribution. 3. Altered versions--including, but not limited to, ports to new operating systems, existing ports with new graphical interfaces, and dynamic, shared, or static library versions--must be plainly marked as such and must not be misrepresented as being the original source. Such altered versions also must not be misrepresented as being Info-ZIP releases--including, but not limited to, labeling of the altered versions with the names "Info-ZIP" (or any variation thereof, including, but not limited to, different capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the explicit permission of Info-ZIP. Such altered versions are further prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP e-mail addresses or of the Info-ZIP URL(s). 4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its own source and binary releases. Written by Chris Maunder ([email protected]) Copyright (c) 1998-2003. This code may be used in compiled form in any way you desire. This file may be redistributed unmodified by any means PROVIDING it is not sold for profit without the authors written consent, and providing that this notice and the authors name is included. If the source code in this file is used in any commercial application then acknowledgement must be made to the author of this file (in whatever form you wish). This file is provided "as is" with no expressed or implied warranty. The author accepts no liability for any damage caused through use.

xiv

Contents Contact Information Third Party Copyright Notices Chapter 1: About Getting Started About This Book ................................................................................................................................................19 Document Conventions....................................................................................................................................19 Chapter 2: Licensing About Licensing.................................................................................................................................................21 Licensable Components....................................................................................................................................21 About the Trial Period ......................................................................................................................................22 Disabling the Components Running in Trial Period....................................................................................23 About License Expiration.................................................................................................................................23 About the System Serial Number ...................................................................................................................24 Obtaining a WebPower Account.....................................................................................................................24 Registering and Licensing Blue Coat Hardware and Software ..................................................................24 Retrieving the License.......................................................................................................................................26 Manual License Installation .............................................................................................................................26 Manually Updating a License..........................................................................................................................29 Automatically Updating a License .................................................................................................................29 Chapter 3: Accessing the SG Appliance Before You Begin: Understanding Modes .....................................................................................................31 Accessing the SG Appliance ............................................................................................................................32 Accessing the CLI.......................................................................................................................................32 Accessing the Management Console.......................................................................................................32 Accessing the Management Console Home Page ........................................................................................33 Logging On .................................................................................................................................................33 Logging Out ................................................................................................................................................33 Changing the Logon Parameters.....................................................................................................................34 Changing the Username and Password .................................................................................................34 Changing the SG Appliance Realm Name .............................................................................................36 Changing the SG Appliance Timeout .....................................................................................................37 Viewing the Appliance Health ........................................................................................................................37 Chapter 4: Configuring Basic Settings Configuring the SG Appliance Name ............................................................................................................39 Viewing the Appliance Serial Number ..........................................................................................................39 Configuring the System Time..........................................................................................................................40 Network Time Protocol ....................................................................................................................................41

xv

Volume 1: Getting Started

Configuring HTTP Timeout ............................................................................................................................ 42 Chapter 5: Archive Configuration Sharing Configurations .................................................................................................................................... 45 Archiving a Configuration............................................................................................................................... 48 Chapter 6: Adapters About Adapters................................................................................................................................................. 51 About Virtual LAN Configuration ................................................................................................................. 51 About VLAN Deployments...................................................................................................................... 51 The Blue Coat Solution.............................................................................................................................. 53 Configuring an Adapter................................................................................................................................... 54 Configuring Interface Settings ........................................................................................................................ 57 Disabling Transparent Interception ........................................................................................................ 57 Rejecting Inbound Connections............................................................................................................... 58 Using reject-inbound and allow-intercept ............................................................................................. 58 Manually Configuring Link Settings ...................................................................................................... 59 Configuring Proxies................................................................................................................................... 59 Detecting Network Adapter Faults ................................................................................................................ 59 Chapter 7: Software and Hardware Bridges About Bridging.................................................................................................................................................. 61 About Traffic Handling............................................................................................................................. 62 About Bridging Methods .......................................................................................................................... 62 About the Pass-Through Adapter .................................................................................................................. 63 Reflecting Link Errors....................................................................................................................................... 63 Configuring a Software Bridge ....................................................................................................................... 63 Configuring Programmable Pass-Through/NIC Adapters ....................................................................... 65 Customizing the Interface Settings................................................................................................................. 67 Setting Bandwidth Management for Bridging ............................................................................................. 67 Configuring Failover ........................................................................................................................................ 68 Setting Up Failover .................................................................................................................................... 68 Bridging Loop Detection.................................................................................................................................. 69 Adding Static Forwarding Table Entries ....................................................................................................... 71 Bypass List Behavior......................................................................................................................................... 72 Chapter 8: Gateways About Gateways................................................................................................................................................ 73 SG Appliance Specifics..................................................................................................................................... 73 Switching to a Secondary Gateway......................................................................................................... 74 Routing ............................................................................................................................................................... 74 Using Static Routes .................................................................................................................................... 75 Notes ............................................................................................................................................................ 77

xvi

Contents

Chapter 9: DNS SG Appliance Specifics..................................................................................................................................... 79 Configuring Split DNS Support...................................................................................................................... 80 Changing the Order of DNS Servers.............................................................................................................. 81 Unresolved Hostnames (Name Imputing).................................................................................................... 82 Changing the Order of DNS Name Imputing Suffixes ............................................................................... 82 Caching Negative Responses .......................................................................................................................... 82 Appendix A: Glossary Index

xvii

Volume 1: Getting Started

xviii

Chapter 1: About Getting Started

Volume 1: Getting Started describes how to access the Blue Coat SG appliance using the CLI or Management Console, and provides basic configuration information that is required in every environment.

About This Book This book deals with the following topics: ❐

Chapter 2: "Licensing" on page 21

❐

Chapter 3: "Accessing the SG Appliance" on page 31

❐

Chapter 4: "Configuring Basic Settings" on page 39

❐

Chapter 5: "Archive Configuration" on page 45

❐

Chapter 6: "Adapters" on page 51

❐

Chapter 7: "Software and Hardware Bridges" on page 61

❐

Chapter 8: "Gateways" on page 73

❐

Chapter 9: "DNS" on page 79

❐

Appendix A: "Glossary" on page 85

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

19

Volume 1: Getting Started

20

Chapter 2: Licensing

This chapter describes the SG appliance licensing behavior.

About Licensing SGOS 5.x features a global licensing system for the SGOS software. License key files are issued on a per-appliance basis. One license key file includes all of the component licenses for whichever SGOS features you have elected to use. Note: When your Blue Coat appliance order was completed, you received an e-mail that contained serial numbers for licensable components. Those numbers are required for the procedures in this chapter.

Licensable Components There are three types of licensable components: ❐

Required—The SGOS 5 Base; these features are required on the SG appliance.

❐

Included—Additional SGOS 5.x features, which are provided by Blue Coat and that are included in the SGOS 5 base license.

❐

Optional— Any additional (purchased) features.

When the license key file is created, it contains components of all three types. The following table lists the SG appliance licensable components, categorized by type. Table 2-1. Licensable Components Type

Component

Description

Required

SGOS 5 Base

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

Included

3rd Party Onbox Content Filtering

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

Included

Websense Offbox Content Filtering

For Websense off-box support only.

Included

ICAP Services

External virus and content scanning with ICAP servers.

Included

Bandwidth Management

Allows you to classify, control, and, if required, limit the amount of bandwidth used by different classes of network traffic flowing into or out of the SG appliance.

Included

Windows Media

MMS and RTSP proxy for Windows Media content; content caching and splitting. Full policy control over MMS and RTSP traffic for Windows Media content. When the maximum concurrent streams is reached, all subsequent streams are denied and the client receives a message.

21

Volume 1: Getting Started

Table 2-1. Licensable Components (Continued) Type

Component

Description

Included

Real Media

RTSP proxy for Real Media content; content caching and splitting. Full policy control over RTSP traffic for Real Media content. When the maximum concurrent streams is reached, all subsequent streams are denied and the client receives a message.

Included

Apple QuickTime

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

Included

Netegrity SiteMinder

Allows realm initialization and user authentication to SiteMinder servers.

Included

Oracle COREid

Allows realm initialization and user authentication to COREid servers.

Included

Peer-to-Peer

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

Included

HTTP Compression

Allows reduction to file sizes without losing any data.

Optional

SSL (Native SSL Proxy and Reverse HTTPs Proxy, also called SSL Termination)

Native SSL proxy and Reverse HTTPS Proxy (SSL termination) on the SG appliance. You must also purchase an SSL accelerator card to enable SSL termination.

Optional

IM

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

Optional

SG Client— Acceleration

Entitles you to support a certain number of SG Clients in your enterprise; however, the license does not limit the number of ADN tunnels to which clients can have access. SG Client licenses are upgradeable so you can support a larger number of users.

Note: Only the appliance designated as the SG Client Manager requires a license. To use SG Clients in your enterprise, apply the license only to the Client Manager and not to any other appliances in the ADN network.

About the Trial Period Blue Coat provides a trial period, enabled by default. During initial configuration of new hardware, you can specify an edition of SGOS to run during the trial period. The SG appliance can run either the MACH5 or Proxy Edition of SGOS during the trial period.

22

Chapter 2: Licensing

Note: If you select Proxy Edition for the trial period but you purchase a MACH5 Edition license, the SG appliance configuration is reset when you install the license. Note also that a few defaults—default proxy policy, trust destination IP address, and tolerating HTTP requests—differ between the two editions.

The initial system boot-up triggers the 60-day trial; during this time you can evaluate the SGOS functionality. For the first 60 days, all licensable components for the trial edition you chose are active and available to use. When a license or demo license is installed during the trial period, components previously available in the trial period, but not part of that license, remain available and active for the remainder of the trial period. However, if the license edition is different than the trial edition you selected, only functionality available in the edition specified in the license remains available for trial. Each time you navigate to the Management Console License Warning page, you see a text message that identifies the expiration date of your trial period; the Maintenance > Licensing > View tab shows the license components with expiration dates. If you require more time to explore the SGOS features, a demo license is available; refer to your reseller or contact Blue Coat Sales. In the trial period, the Base SGOS user limit is unlimited. When a full license is installed, any user limits imposed by that license are enforced, even if the trial period is still valid.

Disabling the Components Running in Trial Period You have the option to not let users access features that are currently running in trial period; however, you cannot selectively disable trial period features. You must either enable all of them or disable all of them. To disable trial period components: 1.

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

2.

Click Apply.

3.

Click Refresh Data. All licenses that are in trial period switch from Yes to No. Users cannot use these features, and no dialogs warning of license expiration are sent.

Also notice that this option text changes to Trial Components are disabled: Enabled. Repeat this process to re-enable trial licenses.

About License Expiration At the end of the trial or demo period or, subsequently, when any normally licensed component expires, components that have not been licensed do not process requests. A license expiration notification message is logged in the Event Log (refer to the Event log information in Volume 8: Managing the Blue Coat SG Appliance for details). If a license expires, users might not receive notification, depending upon the application they are using. Notifications do occur for the following: ❐

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

❐

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

❐

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

23

Volume 1: Getting Started

❐

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

❐

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

❐

SG Client—After the trial license has expired, clients cannot connect to the ADN network.

You can still perform SGOS configuration tasks, 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.

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

Obtaining a WebPower Account Before you can register your SG appliance and retrieve the license key, you must have a Blue Coat WebPower user account. If you do not have a WebPower account or have forgotten your account information, use the following procedure. To obtain a WebPower account: 1.

Select Maintenance > Licensing > Install.

2.

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

3.

Perform one of the following: To obtain a new account, click the link for Need a WebPower User ID. Enter the information as prompted. To obtain your current information for an existing account, click the Forgot your password link.

Registering and Licensing Blue Coat Hardware and Software This section describes how to automatically register the hardware and software with Blue Coat. ❐

If you have not manually registered the hardware, you can automatically register the hardware and install the software license in one step. Continue with “To register the hardware and software” on page 25.

❐

If you have new hardware (SG210, SG510, SG810, SG 8100) that previously has been registered, the license is already associated with the hardware. Go to Maintenance > Licensing > Install and click Retrieve to obtain the license. For more information, see “To retrieve the software license:” on page 26.

24

Chapter 2: Licensing

❐

If you have older hardware that previously has been registered or if the SG appliance does not have Internet access, you can install the software license under Maintenance > Licensing > Install. For more information, see “Manual License Installation” on page 26.

To register the hardware and software 1.

Open a browser and ensure pop-up blocking is disabled.

2.

Enter the SGOS Management Console URL. https://IP_address:8082

3.

Enter the access credentials specified during initial setup.

4.

Click Management Console. The license warning/registration page displays.

5.

Enter your WebPower credentials and click Register Now. It might take up for a minute for the Registration Status field to display the results.

6.

Click Continue.

7.

Select Maintenance > Licensing > View.

25

Volume 1: Getting Started

Figure 2-1. Viewing licensed components

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

To view the most current information, click Refresh Data.

•

Highlight a license component and click View Details. A dialog displays with more detailed information about that component.

•

If the trial period is enabled and you click Maintenance > Licensing > View, the Management Console displays a check box to disable the trial components. If the trial period is disabled, the Management Console displays a check box to enable the trial components.

Retrieving the License If the SG appliance is a new system and the hardware has been registered, you can retrieve the associated license by completing the following steps: To retrieve the software license: 1.

Go to Maintenance > Licensing > Install.

2.

Click Retrieve. The Request License Key dialog displays.

3.

Enter your WebPower account login information.

4.

Click Send Request. The Confirm License Install dialog displays.

5.

Click OK.

6.

Click OK when the License Install Succeeded message displays.

7.

Click Close to close the Request License Key dialog.

Manual License Installation You might need to use manual license installation if: ❐

The SG appliance serial number is not associated with a software license (you have registered the hardware separately)

❐

The SG appliance does not have Internet access

26

Chapter 2: Licensing

To manually obtain and install the license: 1.

Select Maintenance > Licensing > Install.

2.

Click Register/Manage. A new browser window opens and prompts you for your WebPower login information.

3.

Enter your WebPower username and password and click Login. The Support - License Management page displays.

4.

Click the serial number of the unit. The Support - License Management Manage Serial Numbers/Obtain IM License page displays.

5.

Click Manage Software Serial Numbers. The License Self Service Change Hardware Record displays.

27

Volume 1: Getting Started

6.

The next action depends on whether you have internet access. a.

b.

If the SG appliance has internet access: •

Click Add to add a software license to the appliance.

•

Using the serial numbers you received when the Blue Coat appliance shipment was delivered, add the serial numbers.

•

Click Apply when finished. The software license is now associated with the hardware.

•

From Management Console > Maintenance > Licensing > Install, click Retrieve and provide the WebPower login information again. For more information on the Retrieve procedure, see “To retrieve the software license:” on page 26.

If the SG appliance does not have internet access: •

In the Cust Info > Links panel, click Get License. You are prompted to save a .bin file with the license information.

•

Save the .bin file.

•

From Management Console > Maintenance > Licensing > Install, select one of the following from the License Key Manual Installation drop-down list and click Install:

28

Chapter 2: Licensing

Note: A message is written to the event log when you install a license through the SG appliance.

•

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

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

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

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

Manually Updating a License After the initial license installation, you might decide to use another feature that requires a license. The license must be updated to support the new feature. To update a license: 1.

Select Maintenance > Licensing > Install.

2.

Click Register/Manage.

3.

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

4.

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

Automatically Updating a License The license automatic update feature allows the SG appliance 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. If a new license is not available on the Web site, the SG appliance continues to contact the Web site daily for a new license until the current license expires. Outside the above license expiration window, the SG appliance 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: 1.

Select Maintenance > Licensing > Install.

2.

Select Use Auto-Update.

3.

Select Apply to commit the changes to the SG appliance.

29

Volume 1: Getting Started

Note: If the automatic license update fails and you receive a Load from Blue Coat

error 1.

you must log on to your License Management account: https://services.bluecoat.com/eservice_enu/licensing/mgr.cgi.

2.

Click Update License Key.

Related CLI Syntax to Manage Licensing SGOS# licensing {disable-trial | enable-trial} SGOS# licensing request-key [force] user_ID password SGOS# licensing update-key [force] SGOS# licensing register-hardware [force] user_ID password SGOS# licensing mark-registered

30

Chapter 3: Accessing the SG Appliance

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

“Before You Begin: Understanding Modes” on page 31

❐

“Accessing the SG Appliance” on page 32

❐

“Accessing the Management Console Home Page” on page 33

❐

“Changing the Logon Parameters” on page 34

❐

“Viewing the Appliance Health” on page 37

Important: This chapter assumes that you have completed the first-time setup of the SG appliance 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 SG appliance by logging on to and using one of the following: ❐

An SSH session to access the CLI.

❐

The Management Console graphical interface.

You can also use a serial console to access the CLI. Note: To use a Telnet session, you must use a serial console connection until you configure Telnet for use. (For security reasons Blue Coat does not recommend using Telnet).

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

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

❐

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

❐

Configuration is a mode within the Enabled mode. From this level, you can perform permanent changes to the SG appliance configuration.

If you use the Management Console, you are in configuration mode when you log into Enabled mode and type conf t.

31

Volume 1: Getting Started

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 Volume 11: 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 SG Appliance You can access the SG appliance 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 SG appliance, but you cannot use SSHv1 or Telnet without additional configuration. Note: Enabling the Telnet-Console introduces a security risk, so it is not recommended.

To use SSHv1, you must first create an SSHv1 host key. For more information on creating SSH host keys, refer to Volume 2: Proxies and Proxy Services. To log on to the CLI, you must have: ❐

the account name that has been established on the SG appliance

❐

the IP address of the SG appliance

❐

the port number (22 is the default port number)

You must log on from your SSH client.

Accessing the Management Console The Management Console is a graphical Web interface that allows you to manage, configure, monitor, and upgrade the SG appliance from any location. In the Web browser, enter HTTPS, the SG appliance IP address, and port 8082 (the default management port). For example, if the IP address configured during first-time installation is 10.25.36.47, enter the URL https://10.25.36.47:8082 in the Web browser.

32

Chapter 3: Accessing the SG Appliance

The Management Console consists of a set of Web pages stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages. From the SG home page on the appliance, you can access the configuration, maintenance, and statistics pages, and the documentation. The Management Console is supported with a complete online help facility to assist you in defining the various configuration options. Note: If, when you access the Management Console home page, you get a “host mismatch” or an “invalid certificate” message, you need to recreate the security certificate used by the HTTPS-Console. For information on changing the security certificate, refer to the console services information in Volume 2: Proxies and Proxy Services.

Accessing the Management Console Home Page When you access the Management Console home page (see “Accessing the Management Console” on page 32), you are prompted to log on to the system.

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

❐

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

❐

The Realm is a configurable name that can be anything you choose. The SG appliance IP address is the default. For more information on configuring the realm name, see “Changing the SG Appliance Realm Name” on page 36.

❐

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

❐

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

You can change the username and password for the console or the CLI. See “Changing the Logon Parameters” on page 34. Note: All successful and failed logon attempts are logged to the event log.

Logging Out Once you have logged on, you do not have to log on again unless you exit the current session or the session times out. The session timeout period, with a default of 900 seconds (15 minutes), is configurable.

33

Volume 1: Getting Started

Thirty seconds before the session times out, a warning dialog displays. Click the Keep Working button or the X in the upper-right-corner of the dialog box to keep the session alive. Note: The Keep Working button saves your changes. However, you must log back on to

work in other pages.

If you do not click Keep Working or the X in the upper-right-hand corner within the thirtysecond period, you are logged out. You must log back on to access the Management Console. Click the hyperlink to log back on. Note: If you are on the Management Console home page when the session times out, you are logged out without seeing the logout warning dialog. You might not be aware that you are logged out until you try to access a Management Console page. You must enter the logon information again.

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

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

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

Select Configuration > Authentication > Console Access > Console Account.

34

Chapter 3: Accessing the SG Appliance

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

2.

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

3.

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

4.

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

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

Select Configuration > Authentication > Console Access > Console Account.

2.

Click Change Password.

35

Volume 1: Getting Started

3.

Enter and re-enter the console password that is used to view and edit configuration information. The password must be from 1 to 64 characters long. As you enter the new password, it is obscured with asterisks. Click OK. Note: This does not change the enabled-mode password. You can only change the enabled-mode password through the CLI.

4.

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

5.

(Optional) Restrict access by creating an access control list or by creating a policy file containing layer rules. For more information, see Volume 4: Securing the Blue Coat SG Appliance: Chapter 3: "Controlling Access to the Internet and Intranet".

Related CLI Syntax to Change the Username and Password Note: Usernames and passwords can each be from 1 to 64 characters in length, but the

passwords must be in quotes. Usernames that contain \ (backward slash), * (asterisk), or ? (question mark) must be escaped when viewing users from the command line interface. The escape character is \. For example: ❐

user1* is searched as #(config users) view users user1\*

❐

user1? is searched as #(config users) view users user1\?

❐

user1\ is searched as #(config users) view users user1\\ SGOS#(config) security {username username | password “password” | front-panel-pin pin}

Changing the SG Appliance Realm Name The realm name displays when you log on to the Management Console. The default realm name is the connection used to access the SG appliance, usually the IP address of the system. To change the realm name: 1.

Select Configuration > Authentication > Console Access > Console Account.

2.

Enter a new realm name.

36

Chapter 3: Accessing the SG Appliance

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

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Change the Realm Name SGOS#(config) security management display-realm name

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

Changing the SG Appliance 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: 1.

Select Configuration > Authentication > Console Access > Console Account.

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 value (in seconds). This is the allowable length of time on the SG appliance 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 Management Console page.

3.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Change the Timeout SGOS#(config) security management auto-logout-timeout seconds

Viewing the Appliance Health The Management Console displays a visual representation of the overall health state of the SG appliance. The health states are based on the health monitoring metrics, which are described in the Monitoring chapter of Volume 8: Managing the Blue Coat SG Appliance. The health icon is located in the upper right corner of the Management Console.

The following health states are possible: ❐

Ok (Green)

❐

Warning (Yellow)

❐

Critical (Red)

These states are represented by a text string and a color that corresponds to the health of the system (green, yellow or red). The system health changes when one or more of the health metrics reaches a specified threshold or returns to normal. The Management Console polls the SG appliance every 10 seconds and updates the health state indicator accordingly.

37

Volume 1: Getting Started

For More Information To obtain more information about the health state, click the health icon. Clicking the health icon displays the Statistics > Health page, which lists the current condition of the system’s health monitoring metrics. Refer to Volume 8: Managing the Blue Coat SG Appliance for more information about the health monitoring metrics.

38

Chapter 4: Configuring Basic Settings

The SG appliance global configurations include: defining the SG appliance name and serial number, setting the time, and configuring NTP for your environment. The following topics are discussed in this section: ❐

“Configuring the SG Appliance Name” on page 39

❐

“Viewing the Appliance Serial Number” on page 39

❐

“Configuring the System Time” on page 40

❐

“Network Time Protocol” on page 41

❐

“Configuring HTTP Timeout” on page 42

Configuring the SG Appliance Name You can assign any name to a SG appliance. A descriptive name helps identify the system. To set the SG appliance name: 1.

Select Configuration > General > Identification.

2.

In the Appliance name field, enter a unique name for the appliance.

3.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax for Setting the SG Appliance Name SGOS#(config) hostname name

Viewing the Appliance Serial Number The SG appliance serial number assists Blue Coat Systems Customer Support when analyzing configuration information, including heartbeat reports. This number is found on the SG appliance. The serial number is visible on the Management Console home page.

39

Volume 1: Getting Started

Configuring the System Time To manage objects, the SG appliance must know the current Coordinated Universal Time (UTC), which is the international time standard and is based on a 24-hour clock. However, time stamps can also record in local time. To do this, local time must also be set based on time zones. By default, the SG appliance attempts to connect to an NTP server, in the order the servers appear in the NTP server list on the NTP tab, to acquire the UTC time. The appliance ships with a list of NTP servers available on the Internet. If the appliance cannot access any of the listed NTP servers, you must manually set the UTC time. Additionally, the SG appliance ships with a limited list of time zones. If a particular time zone is missing from the included list, the list can be updated at your discretion. Also, the time zone database might need to be updated if the Daylight Savings rules change in your area. The list can be updated by downloading the full time zone database from http:// download.bluecoat.com/release/timezones.tar. To set local time: 1.

Select Configuration > General > Clock > Clock.

2.

Click Select Time zone. A popup appears, displaying a list of time zones based on geopolitical regions.

40

Chapter 4: Configuring Basic Settings

3.

Select the time zone that represents your local time. Once the local time zone is selected, event logs record the local time instead of GMT. To add additional time zones to the list, update the appliance's time zone database, as described in the following procedure.

To update the database: 1.

Select Configuration > General > Clock > Clock.

2.

Enter the URL from which the database will be downloaded or click Set to default.

3.

Click Install.

Related CLI Syntax for Adding New Time Zones to the Database: SGOS# (config) timezone database-path [url | default] SGOS# (config) load timezone-database

To acquire the UTC: 1.

Ensure that Enable NTP is selected.

2.

Click Acquire UTC Time.

Related CLI Syntax for Acquiring and Setting UTC Time: SGOS# acquire-utc SGOS#(config) clock [subcommands]

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 SG appliance ships with a list of NTP servers available on the Internet, and attempts to connect to them in the order they appear in the NTP server list on the NTP tab. You can add others, delete NTP servers, and reorder the NTP server list to give a specific NTP server priority over others. The SG appliance uses NTP and the Coordinated Universal Time (UTC) to keep the system time accurate.

41

Volume 1: Getting Started

You can add and reorder the list of NTP servers the SG appliance uses for acquiring the time. The reorder feature is not available. To add an NTP server: 1.

Select Configuration > General > Clock > NTP.

2.

Click New to add a new server to the list.

3.

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

4.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax for Acquiring and Setting UTC Time: SGOS#(config) ntp [subcommands]

To change the access order: 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.

2.

Select an NTP server to promote or demote.

3.

Click Promote entry or Demote entry as appropriate.

4.

Select Apply to commit the changes to the SG appliance.

Configuring HTTP Timeout You can configure various network receive timeout settings for HTTP transactions. You can also configure the maximum time that the HTTP proxy waits before reusing a clientside or server-side persistent connection. You must use the CLI to configure these settings.

42

Chapter 4: Configuring Basic Settings

To configure the HTTP receive timeout setting: 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: At the (config) command prompt, enter the following command: SGOS#(config) http persistent-timeout {client | server} #_seconds

where :

client

#_seconds

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

server

#_seconds

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

43

Volume 1: Getting Started

44

Chapter 5: Archive Configuration

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

“Sharing Configurations” on page 45

❐

“Archiving a Configuration” on page 48

Sharing Configurations You can share configurations between two SG 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 SG appliance and push it to a newly-manufactured system. Note: Blue Coat Director allows you to push a configuration from one SG

appliance to multiple appliances at the same time. For more information on using Director, see Volume 8: Managing the Blue Coat SG Appliance. 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. To share configurations, you must ❐

Change all "encrypted-password" entries to "password" followed by the actual password in quotes.

❐

Change any "hashed-password" entries to "password" followed by the actual password in quotes.

❐

Make sure that no services are tied to a specific proxy IP address.

❐

Download a content filter database, if the configuration includes content filtering.

You can use either the Management Console or the CLI to create a post-setup configuration file on one SG appliance 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 SG appliance: From the already configured SG appliance: 1.

Select Configuration > General > Archive.

45

Volume 1: Getting Started

2.

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

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

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

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

•

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

•

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

pushed to the system. 3.

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

4.

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

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

•

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

To install the configuration on a newly manufactured SG appliance: 1.

Launch the Management Console in a new browser window.

2.

Select Configuration > General > Archive.

3.

The Archive Configuration tab displays.

4.

In the Install Configuration panel, install the configuration using one of the following methods: •

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.

46

Chapter 5: Archive Configuration

Note: A message is written to the event log when you install a configuration through the SG appliance.

5.

Click Close.

To create and push a configuration to a newly manufactured SG appliance: From the already configured SG appliance: 1.

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

where:

2.

3.

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.

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

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

•

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

On the newly-manufactured SG appliance, retrieve the configuration file by doing 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”

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

47

Volume 1: Getting Started

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 SG appliance 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 SG appliance 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 SG appliance. Archive and restore operations must be done through the CLI. Note: You can archive a system configuration to an FTP or TFTP server that allows either anonymous logon or requires a specific username and password. Likewise, to restore a system configuration, the server storing the archive can be configured either to allow anonymous logon or to require a username and password.

To prepare to archive a system configuration 1.

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

2.

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

where hostname is the IP address of the server. Note: TFTP does not require a password, path, or username. SGOS#(config) archive-configuration password password -orSGOS#(config) archive-configuration encrypted-password encryptedpassword

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 SG appliance creates a name with a timestamp and the filename SG_last-ip-octet_timestamp. For % string substitutions, see Volume 8: Access Logging. SGOS#(config) archive-configuration username username

where user_name is the username used to access the server.

48

Chapter 5: Archive Configuration

Example Session SGOS#(config) ok SGOS#(config) ok SGOS#(config) ok SGOS#(config) ok SGOS#(config) ok

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

Note: 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 archiveconfiguration path “”.

To archive a system configuration: At the enable command prompt, enter the following command: SGOS# upload configuration

To restore a system configuration: At the enable command prompt, enter the following command: SGOS# configure network “url”

See “Sharing Configurations” on page 45 for more information about formatting the URL for FTP.

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

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

❐

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

❐

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

administrator console passwords (not needed for shared configurations)

•

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

•

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

•

access log FTP client passwords (primary, alternate)

•

archive configuration FTP password

•

RADIUS primary and alternate secret

•

LDAP search password

•

SmartFilter download password

•

WebSense3 download password

49

Volume 1: Getting Started

•

SNMP read, write, and trap community strings

•

RADIUS and TACACS+ secrets for splash pages

❐

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

❐

SSH certificate keys must be imported.

❐

SSL certificate keys must be imported

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

50

Chapter 6: Adapters

This chapter describes SG network adapters and the adapter interfaces; the following topics are discussed: ❐

“About Adapters” on page 51

❐

“About Virtual LAN Configuration” on page 51

❐

“Configuring an Adapter” on page 54

❐

“Configuring Interface Settings” on page 57

❐

“Detecting Network Adapter Faults” on page 59

About Adapters SG appliances ship with one or more network adapters installed on the system, each with one or more interfaces. This chapter describes how to change interface parameters or configure additional adapters or virtual LANs 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. As you select adapters from the picklist, the Adapter panel (Configuration > Network > Adapters) displays the state of the configured adapter and its interfaces. Note: In Blue Coat documentation, the convention for the interface is adapter.interface. For example, 0:0.

About Virtual LAN Configuration This section discusses Virtual LAN (VLAN) deployments.

About VLAN Deployments VLANs are created to group multiple physical network segments into individual broadcast domains. The benefit to this is that clients can be organized logically—for example, based on organization—rather than limited to physical connections to interfaces. Because networks recognize VLANs as they do physical LANs, each VLAN can have an IP prefix assigned to it. This enables IP routing of traffic flow between VLANs, which allows for targeted traffic relaying rather than broadcasting to all connected hosts. VLAN configuration occurs on the switch. The network administrator specifies which ports belong to which VLANs. The following diagram illustrates a port-based VLAN configuration. Clients on network segments attached to switch ports 1 and 2 belong to VLAN 1, which has the network address 10.0.1.x; network segments attached to switch ports 14 and 15 belong to VLAN 2, which has the network address 10.0.2.x.

51

Volume 1: Getting Started

Figure 6-1. Multiple VLANs connected to ports on one switch

As also illustrated in the diagram, clients of different OS types can reside within a VLAN. However, not all clients are able to detect (send or receive) VLAN-tagged packets.

About VLAN Trunking On the packet level, VLAN identification is achieved by the switch tagging, or inserting, the VLAN ID (VID) into the packet header. This allows the next switch inline to know the location of the destination VLAN. When VLANS span multiple switches, a trunk data link between switches that carries traffic associated with multiple VLANs is required. The trunk link is attached to a switch port designated for inter-switch communication. In the following diagram, multiple VLANs are connected by trunk data link between two switches.

Figure 6-2. Two switches connected by a trunk

About Native VLANs Each switch port has a designated native VLAN. On any given switch, each port might have a different Native VLAN configured on it. While native VLAN connections themselves are not tagged, they can carry both tagged and untagged VLAN traffic. Connections destined to the native VLAN have their packets sent out untagged, and connections destined to non-native VLANs have their packets sent out tagged. The default VID on most switches is 1. The trunk link carries both the native VLAN (untagged) and all other VLAN (tagged) packets, as illustrated in the following diagram.

52

Chapter 6: Adapters

Figure 6-3. A switch broadcasting native and regular VLAN traffic over a trunk

In this example, the client attached to port 7 belongs to VLAN 2. Even though it is part of VLAN2, it does not set tags or receive VLAN-tagged packets. The switch knows the packet belongs to VLAN 2 and tags it accordingly. Conversely, it strips the VLAN 2 tag on the response. The trunk link broadcasts VLAN 1 (the native) and 2 traffic to a router that accepts the subnets of those VLANs. Deployment complications arise when a device (other than a router) is required between switches. Without VLAN tagging support, any network device deployed in between switches either drops all VLAN-tagged traffic or passes it through by a bridging configuration. This creates a problem if, for example, users located on different floors all belong to VLAN 1, but are separated by proxy that does not recognize VLAN-tagged packets. Note: In Blue Coat documentation, the convention for VLAN is adapter.interface.VLAN_ID. For example, 0:0.1 is the native VLAN on adapter 0, interface 0.

The Blue Coat Solution SGOS 5.1.4 and later supports VLAN tagging; therefore, a SG appliance can be deployed inline with switches that are routing VLAN traffic. This allows for uninterrupted VLAN service, plus enables benefits gained with the proxy features. The Management Console enables you to configure VLAN interfaces the same way you configure physical interfaces. After a VLAN is added, it appears in the list of network interfaces. Properties such as allow-intercept and reject-inbound are applicable to VLAN interfaces. The most common deployment is a SG appliance residing between two switches or a switch and a router that is forwarding or bridging traffic; in these cases, preserving tagged packets is essential to your network.

53

Volume 1: Getting Started

Figure 6-4. SG appliance deployed between two switches

As the SG appliance strips outgoing native VLAN tags, trunking on both interfaces is required to both recognize and preserve the tagged packets.

Figure 6-5. Trunking enabled on two SG appliance physical interfaces

Based on this deployment: ❐

The SG appliance accepts all packets, regardless of their tag, and, if configuration and policy allows, passes them from one interface to the other with the original VLAN tagged preserved.

❐

If a packet arrives on one interface on VLAN 2, it remains on VLAN 2 when it is forwarded out another interface. If a packet arrives untagged and the destination interface has a different native VLAN configured, the SG appliance adds a tag to ensure the VLAN is preserved. Similarly, if a tagged packet arrives and the VLAN ID matches the native VLAN of the destination interface, the SG appliance removes the tag before forwarding the packet.

Note: Bridge groups cannot be based on VLANs.

Configuring an Adapter The following procedure describes how to configure an adapter. Repeat the process if the system has additional adapters.

54

Chapter 6: Adapters

To configure a network adapter: 1.

Select Configuration > Network > Adapters > Adapters. Note: Different SG appliance models have different adapter configurations, and the appearance of the Adapters tab varies accordingly.

2

5 3 4 6a 6b 6c

2.

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

3.

(Optional) If you have a multiple-interface adapter, select an interface from the dropdown list.

4.

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

5.

(Optional) To configure link settings, restrict inbound connections, or set up browser proxy behavior for the adapter, select the interface and click Settings. Enter any changes and click OK to close the Settings dialog. See “Configuring Interface Settings” on page 57 for more information about configuring adapter settings. Note: The default is to permit all inbound connections. You should always manually configure link settings to avoid problems. The browser default is to use the proxy’s default PAC file. (See “Configuring Interface Settings” on page 57 below for more information on link settings and inbound connections.)

6.

If applicable, configure Virtual LAN (VLAN) options (see “About Virtual LAN Configuration” on page 51):

55

Volume 1: Getting Started

a.

By default, the native VID for any SG appliance interface is 1, as most switches by default are configured to have their native VIDs as 1. Only change this value if the native VID of the switch connected to this interface is a value other than 1; match that value here.

b.

If this SG appliance is inline to forward or bridge traffic, select enable trunking to make the link to this interface a data link from the router that recognizes VLAN-tagged packets from multiple-VLAN sources.

c.

To add more VLANs (not the native VLAN) to the interface, click Configure > VLANs.

6e 6f

6d

7.

d.

Click Add to display the VLAN dialog.

e.

Specify the VLAN ID (VID) number of the VLAN accepted on this interface.

f.

Specify the VLAN IP address and subnet mask.

g.

The receiving packet and browser behavior is the same as for physical interfaces. See “Configuring Interface Settings” on page 57”.

h.

Click OK in both dialogs.

Click Apply.

56

Chapter 6: Adapters

Related CLI Syntax to Configure an Adapter/Native VLAN ❐

To enter configuration mode: SGOS#(config) interface fast-ethernet adapter:interface SGOS#(config) interface adapter:interface

❐

The following VLAN subcommands are available: SGOS#(config interface adapter:interface) native-vlan # SGOS#(config interface adapter:interface.vlan_id) vlan-trunk {enable | disable}

Configuring Interface Settings The Settings button in the Interfaces field allows you to restrict inbound connections on the selected adapter, and to select manual or automatic configuration of the adapter link settings. The default for Inbound connections is to permit all incoming connections. Although link settings can be automatically configured, Blue Coat recommends manually setting them. Note: Rejecting inbound connections improperly or manually configuring link settings improperly might cause the SG appliance to malfunction. Ensure that you know the correct settings before attempting either of these. If the SG fails to operate properly after changing these settings, contact Blue Coat Support.

Disabling Transparent Interception This feature enables the administrator to specify the interfaces that will intercept traffic. By default, the SG appliance intercepts connections in both directions. Using this feature, the administrator can configure it to intercept the connection in only one direction. Note: To use this feature, reject-inbound must be disabled.

To bypass transparent interception: 1.

Select Configuration > Network > Adapters > Adapters.

2.

Select an adapter from the Adapter drop-down list.

3.

Click Settings.

4.

Select Bypass Transparent Interception.

5.

Click OK to close the Settings dialog.

6.

Click Apply.

57

Volume 1: Getting Started

Related CLI Syntax to Disable Transparent Interception ❐

To enter configuration mode for standard interfaces: SGOS#(config interface adapter:interface) allow-intercept {enable | disable}

❐

To enter configuration mode for VLAN interfaces: SGOS#(config interface adapter:interface.vlan_id) allow-intercept {enable | disable}

Rejecting Inbound Connections This feature enables the administrator to reject all inbound traffic. If enabled, all inbound traffic is silently dropped—except for console access traffic. The default setting is disabled; the SG appliance allows inbound connections on all network adapters. To reject inbound connections: 1.

Select Configuration > Network > Adapters > Adapters.

2.

Select an adapter from the Adapter drop-down list.

3.

Click Settings.

4.

Select Firewall Incoming Traffic.

5.

Click OK to close the Settings dialog.

6.

Click Apply.

Related CLI Syntax for Rejecting Inbound Connections ❐

To enter configuration mode for standard interfaces: SGOS#(config interface adapter:interface) reject-inbound {enable | disable}

❐

To enter configuration mode for VLAN interfaces: SGOS#(config interface adapter:interface.vlan_id) reject-inbound {enable | disable}

Using reject-inbound and allow-intercept The allow-intercept and reject-inbound commands are interface-level configurations and are not bridge-specific. The reject-inbound command always has precedence. The following table describes how traffic is handled for the three possible settings of these options.

58

Chapter 6: Adapters

Table 6-1. Command Interaction for Reject-Inbound and Allow-Intercept rejectinbound

allowintercept

Non-proxy ports (mgmt-console, ssh, etc)

Explicit proxy ports

Transparent proxy ports

Other ports

Disabled

Enabled

Terminated

Terminated

Terminated

Forwarded

Disabled

Disabled

Terminated

Terminated

Forwarded

Forwarded

Enabled

Enabled/ Disabled

Silently dropped

Silently dropped

Silently dropped

Silently dropped

Manually Configuring Link Settings By default, the SGOS software automatically determines the link settings for all network adapters. However, Blue Coat strongly recommends manually setting the link settings to avoid problems. To manually configure link settings: 1.

Select Configuration > Network > Adapters > Adapters.

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.

Related CLI Syntax to Manually Configure Link Settings ❐

To enter configuration mode for standard interfaces: SGOS#(config interface adapter:interface) {full-duplex | half-duplex}

Configuring Proxies To configure proxies, refer to Volume 2: Proxies and Proxy Services.

Detecting Network Adapter Faults The SG appliance 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 SG appliance 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.

59

Volume 1: Getting Started

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

60

Chapter 7: Software and Hardware Bridges

This chapter describes the SGOS hardware and software bridging capabilities. Network bridging through the SG appliance provides transparent proxy pass-through and failover support. The following topics are discussed: ❐

“About Bridging”

❐

“About the Pass-Through Adapter” on page 63

❐

“Configuring a Software Bridge” on page 63

❐

“Configuring Programmable Pass-Through/NIC Adapters” on page 65

❐

“Customizing the Interface Settings” on page 67

❐

“Setting Bandwidth Management for Bridging” on page 67

❐

“Configuring Failover” on page 68

About Bridging Bridging functionality allows SG appliances to be easily deployed as transparent redirection devices, without requiring the additional expense and maintenance of L4 switches or WCCP-capable routers. Bridging is especially useful in smaller deployments in which explicit proxies or L4 switches are not feasible options. Bridges are used to segment Ethernet collision domains, thus reducing frame collisions. Unlike a hub, a bridge uses a frame’s destination MAC address to make delivery decisions. Because these decisions are based on MAC addressing, bridges are known as Layer 2 devices. To make efficient delivery decisions, the bridge must discover the identity of systems on each collision domain, and then store this information in its bridging table. After learning the identity of the systems on each collision domain, the bridge uses the source MAC address of frames to determine from which interface a given system can be reached. A branch office that would take advantage of a bridging configuration is likely to be small; for example, it might have only one router and one firewall in the network, as shown below. LAN

LAN Router

Figure 7-1. A Bridged Configuration

61

Volume 1: Getting Started

To ensure redundancy, the SG appliance supports both serial and parallel failover modes. See “ Configuring Failover” for more information about serial and parallel failover configurations.

About Traffic Handling Because the bridge intercepts all traffic, you can take advantage of the powerful proxy services and policies built into the SG appliance to control how that traffic is handled. If the SG appliance recognizes the intercepted traffic, you can apply policy to it. Unrecognized traffic is forwarded out. This traffic handling flow is shown in the following figure.

Figure 7-2. Traffic Flow Decision Tree

Because policy can be applied only to recognized protocols, it is important to specify port ranges that will capture all traffic, even that operating on lesser-known ports.

About Bridging Methods The SG appliance 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. See “Configuring Programmable Pass-Through/NIC Adapters” on page 65 for more information.

❐

Hardware—A hardware, or pass-through, bridge uses a 10/100 dual interface Ethernet adapter. This type of bridge provides pass-through support. See “ About the Pass-Through Adapter” for more information. Note: If you want to use an L4 switch or an explicit proxy instead of bridging, you must disable the bridging pass-thru card.

62

Chapter 7: Software and Hardware Bridges

About the Pass-Through Adapter A pass-through adapter is a 10/100 dual interface Ethernet adapter designed by Blue Coat to provide an efficient fault-tolerant bridging solution. If this adapter is installed on an SG appliance, SGOS detects the adapter upon system bootup and automatically creates a bridge—the two Ethernet interfaces serve as the bridge ports. If the SG appliance is powered down or loses power for any reason, the bridge fails open; that is, Web traffic passes from one Ethernet interface to the other. Therefore, Web traffic is uninterrupted, but does not route through the appliance.

Important: This scenario creates a security vulnerability. Once power is restored to the SG appliance, the bridge comes back online and Web traffic is routed to the appliance and thus is subject to that appliance’s configured features, policies, content scanning, and redirection instructions. Note that bridging supports only failover; it does not support load balancing. Note: The adapter state is displayed on Configuration > Network > Adapters.

Reflecting Link Errors When the SG appliance is deployed transparently with bridging enabled, link errors that occur on one interface can be reflected to the other bridge interface. This allows a router connected to the SG appliance on the healthy link to detect this failure and recompute a path around this failed segment. When the interface with the original link error is brought back up, the other interface is automatically restarted as part of the health check process. Reflecting link errors requires that two interfaces be available and connected in a bridging configuration; it also requires that the propagation-failure option is enabled. By default, propagation-failure is disabled. Note: This feature is only applicable to a two-interface hardware or software bridge. The propagation-failure option sets itself to disabled in any other scenario.

If the link goes down while propagation-failure is disabled, the previous link state is immediately reflected to the other interface if propagation-failure is enabled during this time.

Configuring a Software Bridge This section describes how to use the Management Console or the CLI to link adapters and interfaces to create a network bridge. Before configuring a software bridge, ensure that your adapters are of the same type. Although the software does not restrict you from configuring bridges with adapters of different speeds (10/100 or GIGE, for example), the resulting behavior is unpredictable. To create and configure a software bridge: 1.

Select Configuration > Network > Adapters > Bridges.

2.

Click New.

63

Volume 1: Getting Started

3 4 5

6

3.

4.

In the New Bridge Name field, enter a name for the bridge—up to 16 characters. The bridge name is case insensitive, that is, you cannot name one bridge “ABC” and another bridge “abc”. (Optional) If you want to assign the bridge to a failover group select it from the Failover Group drop-down list.

See “Configuring Failover” on page 68 for more information about configuring failover. 5.

If you have a two-interface bridge and want to enable link error propagation, select the Propagation Failure check box.

6.

Click Add. The Add Bridge Interface dialog displays.

64

Chapter 7: Software and Hardware Bridges

7a 7b

7c

7d

7.

Configure the bridge interface options: a.

From the Interface drop-down menu, select an interface.

b.

(Optional) To enable bridging loop avoidance, select Enable Spanning Tree. See “Bridging Loop Detection” on page 69 for more information about the Spanning Tree Protocol.

c.

If you are using firewall configurations that require the use of static forwarding table entries, add a static forwarding table entry that defines the next hop gateway that is on the correct side of the bridge. For more information on static forwarding table entries, see“Adding Static Forwarding Table Entries” on page 71.

d.

Click OK.

e.

Repeat Step 7 for each interface you want to attach to the bridge.

8.

Click OK to close the Create Bridge Interface and Create Bridge dialogs.

9.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure a Software Bridge SGOS#(config) bridge SGOS#(config bridge) edit bridge_name

Configuring Programmable Pass-Through/NIC Adapters Some Blue Coat appliances ship with a network adapter card that can be used as a passthrough adapter or as a Network Interface Card (NIC), depending on the configured mode. If the network adapter mode is set to disabled, the adapter interfaces can be used as NICs or as part of a software bridge. If your appliance includes a programmable adapter card, the Edit Bridge dialog displays a Mode option that allows you to specify the card behavior. The following programmable

adapter modes are available: ❐

Disabled—Disables the bridge and allows the adapter interfaces to be reused as NICs or as part of another bridge.

65

Volume 1: Getting Started

❐

Fail Open—If the SG appliance fails, all traffic passes through the bridge so clients can still receive data.

❐

Fail Closed—If the SG appliance fails, all traffic is blocked and service is interrupted. This mode provides the same functionality as a user-configured software bridge.

Note: If you create a software bridge, the programmable bridge card mode is implicitly Fail Closed (if the appliance fails, the software bridge is non-functional).

The following procedure describes programmable adapter configuration. To configure the function of the programmable adapter: 1.

Select Configuration > Network > Adapters > Bridges.

2.

In the Bridges section, select the bridge you want to configure.

3.

Click Edit. The Edit Bridge dialog displays.

4 5 6

4.

Select the desired mode from the Mode drop-down list.

5.

If you have a two-interface bridge and want to enable link error propagation, select the Propagation Failure check box.

6.

(Optional) Use Clear Bridge Statistics to reset the traffic history of the bridge, which includes packet and byte counts, to 0.

7.

Click OK to save your changes and close the Edit Bridge dialog.

8.

Click Apply to commit the changes to the SG appliance.

66

Chapter 7: Software and Hardware Bridges

Related CLI Syntax to Configure a Programmable Adapter Card SGOS#(config) bridge SGOS#(config bridge) edit bridge_name SGOS#(config bridge bridge_name) mode fail-open SGOS#(config bridge bridge_name) mode fail-closed SGOS#(config bridge bridge_name) mode disable Note: If the bridge adapters are not programmable, the mode commands are not visible.

Customizing the Interface Settings To further customize the bridge, edit the interface settings. Editing the interface settings allows you to ❐

Allow transparent interception. It is bypassed by default. You must configure the WAN interface to allow transparent interception. Note:

If you have a MACH5 license, a programmable bridge card, and labeled WAN/LAN interfaces, the WAN interface allows transparent interception by default. ❐

Firewall incoming traffic. Firewalls must be specifically configured.

See “Configuring Interface Settings” on page 57 for more information. The Bridge Settings options allow you to clear bridge forwarding table and clear bridge statistics.

Setting Bandwidth Management for Bridging After you have created and configured a bandwidth management class for bridging, you can manage the bandwidth used by all bridges. Refer to Volume 5: Advanced Networking for more information on bandwidth management. To configure bandwidth management for bridging: 1.

Select Configuration > Network > Adapters > Bridges.

2.

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

3.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Set a Bridging Bandwidth Class SGOS#(config bridge) bandwidth-class bridge_name

67

Volume 1: Getting Started

SGOS#(config) bandwidth-management SGOS#(config bandwidth-management) [subcommands]

Configuring Failover In failover mode, two appliances are deployed, a master and a slave. The master sends keepalive messages (advertisements) to the slaves. If the slaves do not receive advertisements at the specified interval, the slave takes over for the master. When the master comes back online, the master takes over from the slave again. The SGOS bridging feature allows two different types of failover modes, parallel and serial. Hardware and software bridges allow different failover modes: ❐

Software bridges allow serial or parallel failover. However, note that if the SG appliance fails, serial failover also fails.

❐

Hardware bridges allow serial failover only.

Parallel Failover In parallel failover mode, two systems are deployed side by side on redundant paths. In parallel failover, the slave does not actively bridge any packets unless the master fails. If the master fails, the slave takes over the master IP address and begins bridging. A parallel failover configuration is shown in the following figure.

Because of the redundant paths, you must enable Spanning Tree to avoid bridge loops. See “Bridging Loop Detection” on page 69 for more information about STP. Serial Failover In serial failover mode, the slave is inline and continuously bridges packets, but does not perform any other operations to the bridged traffic unless the master fails. If the master fails, the slave takes over the master IP address and applies policy, etc. A serial configuration is shown in the following figure.

Setting Up Failover Failover is accomplished by doing the following: ❐

Creating virtual IP addresses on each proxy.

❐

Creating a failover group.

❐

Attaching the bridge configuration.

68

Chapter 7: Software and Hardware Bridges

❐

Selecting a failover mode (parallel or serial).

Both proxies can have the same priority (for example, the default priority). In that case, priority is determined by the local IP address—the SG appliance with the highest local IP will assume the role of master. 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 interface mirroring. ❐

SG A—software bridge IP address: 10.0.0.2. Create a virtual IP address and a failover group, and designate this group the master. SG_A#(config) virtual-ip address 10.0.0.4 SG_A#(config) failover SG_A#(config failover) create 10.0.0.4 SG_A#(config failover) edit 10.0.0.4 SG_A#(config failover 10.0.0.4) master SG_A#(config failover 10.0.0.4) enable

The preceding commands create a failover group called 10.0.0.4. The priority is automatically set to 254 and the failover interval is set to 40. ❐

SG B—software bridge IP address: 10.0.0.3. Create a virtual IP address and a failover group. SG_B#(config) virtual-ip address 10.0.0.4 SG_B#(config) failover SG_B#(config failover) create 10.0.0.4 SG_B#(config failover) edit 10.0.0.4 SG_B#(config failover 10.0.0.4) enable In the bridge configuration on each SG appliance, attach the bridge configuration to the failover group: SG_A#(config bridge bridge_name) failover group 10.0.0.4 SG_B#(config bridge bridge_name) failover group 10.0.0.4

❐

Specify the failover mode: SG_A#(config bridge bridge_name) failover mode serial SG_B#(config bridge bridge_name) failover mode serial

Bridging Loop Detection Bridging now supports the Spanning Tree Protocol (STP). STP is a link management protocol that prevents bridge loops in a network that has redundant paths that can cause packets to be bridged infinitely without ever being removed from the network. STP ensures that a bridge, when faced with multiple paths, uses a path that is loop-free. If that path fails, the algorithm recalculates the network and finds another loop-free path. The administrator can enable or disable spanning tree participation for the interface.

69

Volume 1: Getting Started Enable spanning tree participation: 1.

Select Configuration > Network > Adapters > Bridges.

2.

Select the desired bridge.

3.

Click Edit.

4

4.

In the Edit Bridge window, highlight the interface you want to configure and click Edit. The Edit Bridge Interface dialog displays.

70

Chapter 7: Software and Hardware Bridges

5

6

5.

Click Enable Spanning Tree.

6.

Click OK to close the Edit Bridge Interface and Edit Bridge windows.

7.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Enable Spanning Tree Participation: SGOS#(config bridge bridge_name) spanning-tree adapter#:interface# {enable | disable}

Adding Static Forwarding Table Entries Certain firewall configurations require the use of static forwarding table entries. Failover configurations use virtual IP (VIP) addresses and virtual MAC (VMAC) addresses. When a client sends an ARP request to the firewall VIP, the firewall replies with a VMAC (which can be an Ethernet multicast address); however, when the firewall sends a packet, it uses a physical MAC address, not the VMAC. The solution is to create a static forwarding table entry that defines the next hop gateway that is on the correct side of the bridge. To create a static forwarding table: 1.

Select Configuration > Network > Adapters > Bridges.

2.

Select the bridge you want to edit and click Edit. The Edit Bridge Interface dialog displays.

71

Volume 1: Getting Started

3a

3c

3d

3b

3.

Add the static forwarding table entry. a.

In the Edit Bridge window, select the interface on which to create the static forwarding table entry.

b.

Click Edit.

c.

In the Edit Bridge Interfaces window, click Add.

d.

In the Add Mac window, add the MAC address of the next hop gateway and click OK.

4.

Click OK to close the Edit Bridge Interface and Edit Bridge windows.

5.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Create a Static Forwarding Table Entry SGOS#(config bridge bridge_name) static-fwtable-entry adapter#:interface# mac-address

Bypass List Behavior The dynamic bypass list is handled differently, depending on the OS version. In SGOS 4.x, packets matching the dynamic bypass list are forwarded in the IP layer. In SGOS 5.x, the packets are forwarded in the bridge layer, which is more appropriate and efficient. For more information on using bypass lists in SGOS 5.x, refer to Volume 2: Proxies and Proxy Services. The behavior of the static bypass list stays the same. The packets are forwarded in IP layer.

72

Chapter 8: Gateways

A key feature of the SGOS software is the ability to distribute traffic originating at the appliance through multiple gateways. You can also fine tune how the traffic is distributed to different gateways. This feature works with any routing protocol (such as static routes or RIP). Note: Load balancing through multiple gateways is independent from the perinterface load balancing the SG appliance automatically does when more than one network interface is installed.

This chapter discusses: ❐

“About Gateways”

❐

“SG Appliance Specifics” on page 73

❐

“Switching to a Secondary Gateway” on page 74

❐

“Routing” on page 74

About Gateways During the initial setup of the SG appliance, you optionally defined a gateway (a device that serves as entrance and exit into a communications network) for the SG appliance. 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.

SG Appliance Specifics Which gateway the SG appliance 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 SG appliance can have from 1 to 10 preference groups. If you have only one gateway, it automatically has a weight of 100. Initially, all gateways in the lowest preference group are considered to be the active gateways. If a gateway becomes unreachable, it is dropped from the active gateway list, but the remaining gateways within the group continue to be used until they all become unreachable, or until an unreachable gateway in a lower preference group becomes reachable again. If all gateways in the lowest preference group become unreachable, the gateways in the next lowest preference group become the active gateways.

73

Volume 1: Getting Started

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 SG appliance 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 networking code detects the unreachable gateway in 20 seconds, and the switch over takes place immediately if a secondary gateway is configured. All configured gateways are affected, not just default gateways, as was the case in earlier releases. To configure multiple gateway load balancing: 1.

Select Configuration > Network > Routing > Gateways.

2.

Click New.

3.

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

4.

Click OK.

5.

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

6.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Multiple Gateway Load Balancing SGOS#(config) ip-default-gateway ip_address preference_group weight

Routing By default, routing is done transparently if the SG appliance can verify (trust) the destination IP addresses provided by the client. If the destination IP addresses cannot be trusted, the SG appliance uses static routes.

74

Chapter 8: Gateways

Note: If your environment uses explicit proxy or Layer-4 redirection, or if the destination IP addresses cannot be verified by the SG appliance, static routes must be configured.

Hardware or software bridges can be transparently routed if the destination IP address/ hostname can be verified. If the client-provided destination IP address is not in the list of resolved IP addresses for the particular host, then the SG appliance uses static routes instead. For hostname-less protocols such as CIFS and FTP, the IP address can always be trusted. For other protocols, such as HTTP, RTSP, and MMS, which have a hostname that must be resolved, verification can be an issue. URL rewrites that modify the hostname also can cause verification to fail. Transparent ADN connections that are handed off to an application proxy (HTTP or MAPI, for example) can utilize L2/L3 transparency. Also, transparent ADN connections that are tunneled but not handed off can utilize the functionality. Note: IM is not supported with trust client addressing. In order to login and chat, the default router must have Internet access. Other IM features require direct connections, so static routes are required.

This feature is not user-configurable.

Using Static Routes If you use an explicit proxy or layer-4 redirection deployment, or a Blue Coat feature such as forwarding where the destination IP cannot be verified by the SG appliance, you can use static routes. A static route is a manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network, and a default static route already exists. Situations in which static routes are used include: ❐

DNS load balancing. Sites that use DNS load balancing and return a single IP address cause a mismatch between the IP address provided by the client and the IP address resolved by the SG appliance.

❐

Anywhere that appropriate client-side routing information is unavailable, such as for forwarding hosts, dynamic categorization, and ADN peers. Note:

For bridged deployments, transparent routing, in most cases, overrides any static route lookups. The routing table is a text file containing a list of IP addresses, subnet masks, and gateways. You are limited to 10,000 entries in the static routes table. The following is a sample router table: 10.25.36.0 10.25.37.0 10.25.38.0

255.255.255.0 255.255.255.0 255.255.255.0

10.25.36.1 10.25.37.1 10.25.38.1

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

75

Volume 1: Getting Started

You can install the routing table several ways. ❐

Using the 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 SG appliance 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 SG appliance.

❐

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

❐

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

Note: If you upgrade to SGOS 5.x from SGOS 4.x, entries from the central and local bypass lists are converted to static route entries in the static route table. The converted static route entries are appended after the existing static route entries. Duplicate static route entries are silently ignored.

All traffic leaving the SG appliance is affected by the static route entries created from the SGOS 4.x bypass lists.

Installing a Routing Table To install a routing table: 1. 2.

Select Configuration > Network > Routing > Routing. From the drop-down list, select the method used to install the routing table; click Install.

•

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

•

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

•

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

3.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Install a Routing Table To install a routing table, you can use the inline command to install the table directly, or enter a path to a remote URL that has an already-created text file ready to download.

76

Chapter 8: Gateways

❐

To paste a static route table directly into the CLI: SGOS#(config) inline static-route-table end-of-file_marker paste static routing table eof ok

❐

To enter the static route table manually: 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: SGOS#(config) static-routes path url SGOS#(config) load static-route-table

Notes ❐

Any deployment that causes traffic to traverse the link from the SG appliance to the home router twice is not supported. Some WCCP configurations might not work as expected.

❐

If you use URL host rewrite functionality in your policies, mismatches can occur between the client-provided IP address and the resolved, rewritten hostname. In these cases, static routing is used.

77

Volume 1: Getting Started

78

Chapter 9: DNS

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

“SG Appliance Specifics”

❐

“Configuring Split DNS Support” on page 80

❐

“Changing the Order of DNS Servers” on page 81

❐

“Unresolved Hostnames (Name Imputing)” on page 82

❐

“Changing the Order of DNS Name Imputing Suffixes” on page 82

❐

“Caching Negative Responses” on page 82

SG Appliance Specifics If you have defined more than one DNS server, the SGOS software uses the following logic to determine which servers are used to resolve a DNS host name and when to return an error to the client: ❐

SGOS 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 SG appliance does not receive a response from the current server.

❐

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

❐

The SG appliance only sends requests to servers in the alternate DNS server list if a server in the primary list indicates that a DNS host name cannot be resolved. If a DNS server returns any other error (other than an indication that a DNS host name could not be resolved), the SG appliance 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 SG appliance always attempts to contact the first server in the primary DNS server. If a response is received from this server, no attempts are made to contact any other DNS servers in the primary list. If the response from the first primary DNS server indicates a name error, the SG appliance sends a DNS request to the first alternate DNS server, if one is defined. If no alternate DNS servers have been defined, an error is returned to the client indicating a name error. If the first alternate DNS server is unable to resolve the IP address, a name error is returned to the client, and no attempt is made to contact any other DNS servers in either the primary or alternate DNS server lists.

79

Volume 1: Getting Started

If a response is not received from any DNS server in a particular DNS server list, the SG appliance sends a DNS request to the next server in the list. The SG appliance returns a name error to the client if none of the servers in a DNS server list responds to the DNS request. Note: The alternate DNS server is not used as a failover DNS server. It is only used

when DNS resolution of primary DNS server returns name error. If a timeout occurs when looking up the primary DNS server, no alternate DNS server is contacted. If the SG appliance receives a negative DNS response (a response with an error code set to Name Error), it caches that negative response. You can configure the SG appliance’s negative response time-to-live value. (A value of zero disables negative caching.) If the SG appliance is not configured (the default), the SG appliance caches the negative response and uses the TTL value from the DNS response to determine how long it should be cached.

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

Select Configuration > Network > DNS > DNS.

2.

Click New.

3.

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

4.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Add a DNS Server To add a primary DNS server: SGOS#(config) dns server ip_address

80

Chapter 9: DNS

To Add an Alternate DNS Server 1.

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

2.

Select Alternate DNS in the drop-down list.

3.

Click New.

4.

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

5.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Adding an Alternate DNS Server To add an alternate DNS server: SGOS#(config) dns alternate ip_address

Repeat until alternate DNS servers have been defined.

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

Select Configuration > Network > DNS > Imputing.

2.

Select the DNS server to promote or demote.

3.

Click Promote entry or Demote entry as appropriate.

4.

Select Apply to commit the changes to the SG appliance.

81

Volume 1: Getting Started

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

To add names to the imputing list: 1.

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

2.

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

3.

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

4.

Select Apply to commit the changes to the SG appliance.

Related CLI Syntax to Add Names to the Imputing List To add names to the imputing list: SGOS#(config) dns imputing suffix

For example, to use company.com as the imputing suffix, enter dns-imputing company.com. Repeat until all imputing suffixes have been entered.

Changing the Order of DNS Name Imputing Suffixes The SG appliance uses imputing suffixes in the order displayed. You can organize the list of suffixes so the preferred suffix appears at the top of the list. This functionality is only available through the Management Console. You cannot configure it through the CLI. To change the order of DNS name imputing suffixes: 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.

Select Apply to commit the changes to the SG appliance.

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

82

Chapter 9: DNS

Note: The SG appliance generates more DNS requests when negative caching is

disabled. The SG appliance supports caching of both type A and type PTR DNS negative responses. This functionality is only available through the CLI. You cannot configure DNS negative caching through the Management Console. To configure negative caching TTL values: From the (config) prompt: SGOS#(config) dns negative-cache-ttl-override seconds

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

83

Volume 1: Getting Started

84

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

85

Volume 1: Getting Started

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

86

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

87

Volume 1: Getting Started

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

88

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

89

Volume 1: Getting Started

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

90

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

91

Volume 1: Getting Started

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

92

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

93

Volume 1: Getting Started

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

94

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

95

Volume 1: Getting Started

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

96

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

97

Volume 1: Getting Started

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

98

Index

A administrator read-only and read-write access 31

B Blue Coat SG DNS server 79 read-only and read-write access 31 realm name, changing 36 realm name, changing through CLI 37 subnet mask for 55 time, configuring 40 timeout, changing 37 bridging about 61 bandwidth management 67 configuring failover 68 software bridge 63 interface settings for 58 loop detection 69 pass-through card 63 prerequisites 65 programmable adapters 65 static forwarding table 71 browser accessing the Management Console with 32

C CLI accessing 32 configuration sharing between systems 45 configuration mode, understanding 31 console account tab in Management Console 34 console password, see password

D DNS adding alternate server 81 adding primary 80 negative caching, disabling 83

negative caching, enabling 83 understanding 79 DNS servers addresses, specifying 79 changing name imputing order 82 changing order 81 name imputing 82 document conventions 19

E enable mode, understanding 31

G gateways load balancing 74 switching to secondary 74 understanding 73 using multiple default IP gateways 73 global configurations 39

H HTTP persistent timeout, setting 43 receive timeout, setting 43 timeout, configuring 42

I imputing adding names 82 changing suffix order 82 definition of 82 see also DNS 79 understanding 82 inbound connections, rejecting 58

L licensing about 21 components 21 expiration, about 23 trial period, about 22 updating, automatic 29 updating, manual 29

99

Volume 1: Getting Started

link settings 59 load balancing gateways 74 using multiple default IP gateways 73 login parameters 33

M Management Console accessing 32 changing username and passwords in 34 console account 34 home page 33 logging in 33 logging out 33 modes, understanding 31

N name imputing, see imputing name, configuring 39 negative caching disabling for DNS responses 83 enabling for DNS responses 83 network adapter advanced configuration 58 link faults 59 link settings 59 programmable 65 rejecting inbound connections 58 Network Time Protocol server, see NTP NTP adding server 42 server order, changing 42 time server, definition of 40 understanding 41

P password changing 34 default for 34 see also privileged-mode password privilege (enabled) mode, understanding 31 privileged-mode password changing 34 default for 34 proxies setting up 19

100

R read-only access in Blue Coat SG 31 read-write access in Blue Coat SG 31 realm name, changing 36 timeout, changing 37 routes static 75 static, installing 76 transparent 74 routing static routes 75

S static routes loading 82 table, 81 table, installing 80 static routes, using 75 subnet mask, configuring 55

T time, configuring in the Blue Coat SG 40 timeout HTTP, configuring 42 timeout, realm, changing 37

U Universal Time Coordinates, see UTC username changing 34 default for 34 UTC time 40

V Virtual LAN about 51 adapter configuration 54 deployment 53 native 52 trunk 52

W Web interface, definition of 32

Blue Coat® Systems SG™ Appliance

Volume 2: Proxies and Proxy Services

Version SGOS 5.2.2

Volume 2: Proxies and Proxy Services

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02839 Document Revision: SGOS 5.2.2 10/2007

ii

Contents Contact Information Chapter 1: About Proxies and Proxy Services Creating or Enabling a Proxy Service...............................................................................................................9 Configuring Proxies ..........................................................................................................................................10 About This Book ................................................................................................................................................10 Document Conventions....................................................................................................................................10 About Procedures.......................................................................................................................................11 Illustrations .................................................................................................................................................11 Chapter 2: About Console Services About Console Services ....................................................................................................................................13 Notes on Managing the HTTP Console .........................................................................................................15 Managing the HTTPS Console (Secure Console)..........................................................................................15 Selecting a Keyring ....................................................................................................................................15 Selecting an IP Address.............................................................................................................................16 Enabling the HTTPS Console Service .....................................................................................................16 Managing the SSH Console .............................................................................................................................17 Managing the SSH Host ............................................................................................................................18 Managing SSH Client Keys.......................................................................................................................18 Notes on Managing the Telnet Console .........................................................................................................21 Chapter 3: About Proxy Services About Proxy Listeners ......................................................................................................................................23 Section A: Proxy Services About Multiple Listeners .................................................................................................................................26 About Service Attributes ..................................................................................................................................27 About Access Logging with Proxy Services..................................................................................................28 Creating or Editing a Proxy Service................................................................................................................28 Viewing Proxy Services ....................................................................................................................................30 Section B: Bypass List Adding Static Bypass Entries...........................................................................................................................31 Using Policy to Configure Dynamic Bypass .................................................................................................32 Notes ............................................................................................................................................................32 Configuring Dynamic Bypass ..................................................................................................................33 Section C: Using Restricted Intercept

iii

Volume 2: Proxies and Proxy Services

Section D: Configuring General Options for Proxy Services Trusting the Destination IP Address Provided by the Client..................................................................... 37 Enabling the SG Appliance to Trust the Client-Provided Destination IP Address ......................... 37 Tip ................................................................................................................................................................ 38 Managing User Limits ...................................................................................................................................... 38 Determining Behavior if User Limits are Exceeded ............................................................................. 39 Setting User Limits Notifications............................................................................................................. 39 Viewing Concurrent Users ....................................................................................................................... 41 Configuring General Options.......................................................................................................................... 41 Chapter 4: Managing the CIFS Proxy About CIFS......................................................................................................................................................... 43 About the Blue Coat CIFS Proxy Solution..................................................................................................... 43 Caching Behavior....................................................................................................................................... 44 Authentication............................................................................................................................................ 44 Policy Support ............................................................................................................................................ 45 Access Logging........................................................................................................................................... 45 WCCP Support ........................................................................................................................................... 45 Configuring the SG CIFS Proxy ...................................................................................................................... 45 About Windows Security Signatures...................................................................................................... 45 Configuring CIFS Proxy Services ............................................................................................................ 47 Configuring the CIFS Proxy ..................................................................................................................... 49 Enabling CIFS Access Logging ................................................................................................................ 50 Reviewing CIFS Protocol Statistics.......................................................................................................... 51 Reference: Equivalent CIFS Proxy CLI Commands..................................................................................... 53 Reference: Access Log Fields........................................................................................................................... 54 Reference: CPL Triggers, Properties, and Actions ....................................................................................... 57 Triggers........................................................................................................................................................ 57 Properties and Actions:............................................................................................................................. 57 Chapter 5: Managing the DNS Proxy Creating or Editing a DNS Proxy Service...................................................................................................... 59 Creating a Resolving Name List ..................................................................................................................... 61 Chapter 6: Managing the Endpoint Mapper and MAPI Proxies Section A: The Endpoint Mapper Proxy Service About RPC ......................................................................................................................................................... 64 About the Blue Coat Endpoint Mapper Proxy Solution.............................................................................. 64 Policy Support ............................................................................................................................................ 65 Access Logging........................................................................................................................................... 65 Configuring the SG Appliance Endpoint Mapper Service ......................................................................... 65 Reviewing Endpoint Mapper Proxy Statistics .............................................................................................. 67 Reference: Equivalent Endpoint Mapper Proxy CLI Commands.............................................................. 67 Reference: Access Log Fields........................................................................................................................... 67

iv

Contents

Reference: CPL Triggers, Properties, and Actions ....................................................................................... 68 TCP Tunneling Triggers............................................................................................................................ 69 Properties and Actions.............................................................................................................................. 69 Section B: The MAPI Proxy About MAPI....................................................................................................................................................... 70 About the Blue Coat MAPI Solution .............................................................................................................. 70 Batching....................................................................................................................................................... 71 Keep-Alive .................................................................................................................................................. 71 Supported Servers...................................................................................................................................... 72 Access Logging........................................................................................................................................... 72 More Conceptual Reference ..................................................................................................................... 72 Configuring the SG MAPI Proxy .................................................................................................................... 72 About the MAPI Service ........................................................................................................................... 72 Configuring the MAPI Proxy ................................................................................................................... 72 Reviewing MAPI Statistics .............................................................................................................................. 73 Reference: Equivalent MAPI Proxy CLI Commands................................................................................... 74 Reference: Access Log Fields........................................................................................................................... 74 Chapter 7: Managing the FTP Proxy Understanding FTP........................................................................................................................................... 77 Passive Mode Data Connections ............................................................................................................. 77 Understanding IP Reflection for FTP...................................................................................................... 78 Configuring the SG Appliance for Native FTP Proxy ................................................................................. 79 Creating or Editing the FTP Service........................................................................................................ 79 Configuring the FTP Proxy ...................................................................................................................... 81 Configuring FTP Clients ........................................................................................................................... 82 Configuring FTP Connection Welcome Banners.......................................................................................... 83 Viewing FTP Statistics ...................................................................................................................................... 84 Chapter 8: Managing the HTTP Proxy Section A: Creating an HTTP Proxy Service Section B: Overview: Configuring HTTP Proxy Performance Understanding Default HTTP Proxy Policy .......................................................................................... 91 HTTP Proxy Acceleration Profiles........................................................................................................... 91 Byte-Range Support................................................................................................................................... 91 Refresh Bandwidth .................................................................................................................................... 92 Section C: Configuring the HTTP Proxy Setting Default HTTP Proxy Policy ................................................................................................................ 94 Customizing the HTTP Proxy Profile ............................................................................................................ 96 Using the Normal Profile.......................................................................................................................... 97 Using the Portal Profile............................................................................................................................. 97 Using the Bandwidth Gain Profile .......................................................................................................... 97

v

Volume 2: Proxies and Proxy Services

Understanding HTTP Proxy Profile Configuration Components ............................................................. 97 Configuring the HTTP Proxy Profile .................................................................................................... 100 Configuring HTTP for Bandwidth Gain...................................................................................................... 101 Understanding Byte-Range Support..................................................................................................... 102 Understanding Revalidate Pragma-No-Cache.................................................................................... 103 Configuring Refresh Bandwidth for the HTTP Proxy............................................................................... 103 Understanding Tolerant HTTP Request Parsing........................................................................................ 104 Proxy Edition Behavior ........................................................................................................................... 104 Understanding HTTP Object Types ............................................................................................................. 105 Section D: Viewing HTTP/FTP Statistics HTTP/FTP History Statistics ................................................................................................................. 106 Section E: Using Explicit HTTP Proxy with Internet Explorer Disabling the Proxy-Support Header........................................................................................................... 110 Using Web FTP................................................................................................................................................ 111 Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service Section A: Configuring the HTTPS Reverse Proxy Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server Creating Policy for HTTP and HTTPS Origination ................................................................................... 127 Chapter 10: Managing Shell Proxies Customizing Policy Settings for Shell Proxies ............................................................................................ 129 Conditions................................................................................................................................................. 130 Properties .................................................................................................................................................. 130 Actions....................................................................................................................................................... 130 Boundary Conditions for Shell Proxies ................................................................................................ 130 Understanding Telnet Shell Proxies...................................................................................................... 131 Shell History Statistics .................................................................................................................................... 135 Viewing Shell History Statistics .................................................................................................................... 136 Chapter 11: Managing a SOCKS Proxy Creating or Editing a SOCKS Proxy Service ............................................................................................... 137 Configuring the SOCKS Proxy...................................................................................................................... 139 Using Policy to Control the SOCKS Proxy .................................................................................................. 140 Using the Permeo PA SOCKS Client with the Blue Coat SOCKS Server ............................................... 140 Viewing SOCKS History Statistics ............................................................................................................... 142 Viewing SOCKS Clients.......................................................................................................................... 142 Viewing SOCKS Connections ................................................................................................................ 143 Viewing SOCKS Client and Server Compression Gain Statistics .................................................... 143 Chapter 12: Managing the SSL Proxy Understanding the SSL Proxy ....................................................................................................................... 145 Managing Decrypted Traffic .................................................................................................................. 146 Using the SSL Proxy with ADN Optimization ........................................................................................... 147

vi

Contents

Section A: Intercepting HTTPS Traffic Setting Up the SSL Proxy in Transparent Proxy Mode ............................................................................. 148 Setting Up the SSL Proxy in Explicit Proxy Mode ..................................................................................... 151 Creating an Issuer Keyring for SSL Interception ................................................................................ 151 Using Client Consent Certificates.......................................................................................................... 152 Downloading an Issuer Certificate........................................................................................................ 152 Section B: Configuring SSL Rules through Policy Using the SSL Intercept Layer....................................................................................................................... 156 Using the SSL Access Layer........................................................................................................................... 157 CPL in the SSL Intercept Layer ..................................................................................................................... 159 CPL in the SSL Layer ...................................................................................................................................... 160 Notes ................................................................................................................................................................. 161 Section C: Viewing SSL Statistics SSL History Statistics ...................................................................................................................................... 162 Unintercepted SSL Data.......................................................................................................................... 162 Unintercepted SSL Clients...................................................................................................................... 163 Unintercepted SSL Bytes......................................................................................................................... 163 Section D: Advanced Topics Creating an Intermediate CA using OpenSSL ............................................................................................ 165 Installing OpenSSL .................................................................................................................................. 165 Creating a Root Certificate ..................................................................................................................... 165 Modifying the OpenSSL.cnf File............................................................................................................ 166 Signing the SG CSR.................................................................................................................................. 166 Importing the Certificate into the SG Appliance................................................................................. 167 Creating an Intermediate CA using Microsoft Server 2003 (Active Directory) ..................................... 167 Chapter 13: Managing the TCP Tunneling Proxy TCP-Tunnel Proxy Services Supported ....................................................................................................... 171 Creating or Editing a TCP-Tunnel Proxy Service....................................................................................... 171 Appendix A: Glossary Appendix B: Explicit and Transparent Proxy About the Explicit Proxy................................................................................................................................ 191 About the Transparent Proxy........................................................................................................................ 191 Creating an Explicit Proxy Server................................................................................................................. 192 Using the SG Appliance as an Explicit Proxy ...................................................................................... 192 Configuring Adapter Proxy Settings .................................................................................................... 193

vii

Volume 2: Proxies and Proxy Services

Transparent Proxies ........................................................................................................................................ 193 Configuring Transparent Proxy Hardware ......................................................................................... 193 Configuring a Layer-4 Switch ................................................................................................................ 194 Configuring a WCCP-Capable Router.................................................................................................. 195 Configuring IP Forwarding ........................................................................................................................... 195 Index

viii

Chapter 1: About Proxies and Proxy Services

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 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, as discussed in Volume 4: Securing the Blue Coat SG Appliance. Proxies have two major components: ❐

The proxy service needs to be created or enabled and various attributes set, such as whether you want the proxy to use explicit or transparent mode

❐

The proxy itself needs to be configured to intercept the traffic desired. You can configure it in reverse or forward mode.

Creating or Enabling a Proxy Service Services are created through the Configuration > Services menu. Blue Coat has two types of services: console services, used to communicate with the SG appliance, and proxy services, used to communicate with other systems. Console services are discussed further in Chapter 2: "About Console Services" on page 13. For a list of available proxy services and proxies, see Chapter 3: "About Proxy Services" on page 23. One of the first decisions you make when configuring a proxy is whether the proxy or proxy service will use explicit or transparent attributes. Explicit/Transparent proxy specifies the mode the client requests get to the proxy. ❐

Explicit—The default, requiring software configuration for both browser and service. This service attribute sends requests explicitly to a proxy instead of to the origin content servers.

❐

Transparent—Requires a bridge, such as that available in the SG appliance; a Layer-4 switch, or a WCCP-compliant router. You can also transparently redirect requests through an SG appliance by setting the workstation’s gateway to the appliance IP address. This service attribute sends requests to the proxy without the client or server being aware of it. Some software configuration on the SG appliance is also required to allow the appliance to know what traffic to intercept.

You might configure both proxy types, depending on the services you require. For information on understanding explicit and transparent proxies and the configuration requirements, see Appendix B: "Explicit and Transparent Proxy" on page 191.

9

Volume 2: Proxies and Proxy Services

Configuring Proxies After you have created or enabled the proxy services you need, the next step is to configure the proxy that will use that service. Some proxy services require little configuration; others, such as the SSL proxy, require configuration depending on what you want to do and also require policy to be configured to work effectively.

About This Book This book deals with the following topics: ❐

Chapter 2: "About Console Services" on page 13

❐

Chapter 3: "About Proxy Services" on page 23

❐

Chapter 4: "Managing the CIFS Proxy" on page 43

❐

Chapter 5: "Managing the DNS Proxy" on page 59

❐

Chapter 6: "Managing the Endpoint Mapper and MAPI Proxies" on page 63

❐

Chapter 7: "Managing the FTP Proxy" on page 77

❐

Chapter 8: "Managing the HTTP Proxy" on page 85

❐

Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121

❐

Chapter 10: "Managing Shell Proxies" on page 129

❐

Chapter 11: "Managing a SOCKS Proxy" on page 137

❐

Chapter 12: "Managing the SSL Proxy" on page 145

❐

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

❐

Appendix A: "Glossary" on page 175

❐

Appendix B: "Explicit and Transparent Proxy" on page 191

Document Conventions The following table lists the typographical and Command Line Interface (CLI) syntax conventions used in this manual. Table 1-1. Document 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 Blue Coat 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.

10

Chapter 1: About Proxies and Proxy Services

About Procedures Many of the procedures in this volume begin: ❐

Select Configuration > Services, if you are working in the Management Console, or

❐

From the (config) prompt, if you are working in the command line interface (CLI).

Blue Coat assumes that you already logged into the first page of the Management Console or entered into configuration mode in the CLI.

Illustrations To save space, screen shots illustrating a procedure often have the bottom portion removed, along with the blank space.

Figure 1-1. Configuration > General Pane with Bottom Buttons

Figure 1-2. Configuration > General Pane with Bottom Buttons Removed

11

Volume 2: Proxies and Proxy Services

12

Chapter 2: About Console Services

The SG appliance ships with four consoles designed to manage communication with the system: ❐

HTTP and HTTPS Consoles: These consoles are designed to allow you access to the Management Console. The HTTPS Console is created and enabled by default; the HTTP Console is created by default but not enabled because it is less secure than HTTPS.

❐

SSH Console: This console is created and enabled by default, allowing you access to the CLI using an SSH client.

❐

Telnet Console: This console not created because the passwords are sent unencrypted from the client to the SG appliance. You must create and enable the console before you can access the appliance through a Telnet client (not recommended).

Table 2-1. Console Services Console Service

Default Port

Status

HTTP-Console

8081

Disabled

Configuration Discussed

“Notes on Managing the HTTP Console” on page 15.

HTTPS-Console

8082

Enabled

“Managing the HTTPS Console (Secure Console)” on page 15.

SSH-Console

22

Enabled

“Managing the SSH Console” on page 17.

Telnet-Console

—

Not Created

“Notes on Managing the Telnet Console” on page 21.

About Console Services Console services are used to manage the SG appliance. As such, bypass entries are ignored for connections to console services. The basic procedure for creating or editing a console service is shown below. To edit or create a console service: 1.

Select Configuration > Services > Console Services.

13

Volume 2: Proxies and Proxy Services

2.

To enable or disable a service, select or de-select the Enable checkbox.

3.

To change other settings on a specific console, highlight the service and click Edit.

4.

To create a new console service, click New. 4a

4b

4c

5.

a.

Give the console service a name, using the Name field.

b.

Select the console that is used for this service.

c.

Click New to view the New Listener dialog. A listener defines the fields where the console service will listen for traffic. indicates the service listens on all addresses; IP address indicates that only destination addresses matching the IP address .Fill in the fields appropriate for your environment and the console service you want to create.

Click OK.

14

Chapter 2: About Console Services

Relevant CLI Syntax to Create/Edit a Console Service: ❐

To enter configuration mode for the service: SGOS(config) console-services SGOS(config console-services) create {https-console | http-console | ssh-console | telnet-console} console_name SGOS(config console-services) edit console_name

❐

The following subcommands are available: SGOS (config name) add {all | proxy-ip_address} port_number {enable | disable} SGOS (config console_name) disable {all | proxy-ip_address} port_number SGOS (config console_name) enable {all | proxy-ip_address} port_number SGOS (config console_name) exit SGOS (config console_name) remove {all | proxy-ip_address} port_number SGOS (config console_name) view

Notes on Managing the HTTP Console The default HTTP Console is already configured; you only need to enable it. You can create and use more than one HTTP Console as long as the IP address and the port do not match the existing HTTP Console settings. To create a new HTTP Console service or edit an existing one, see “About Console Services” on page 13.

Managing the HTTPS Console (Secure Console) The HTTPS Console provides secure access to the Management Console through the HTTPS protocol. You can create multiple management HTTPS consoles, allowing you to simultaneously access the Management Console using any IP address belonging to the SG appliance as well as any of the appliance’s virtual IP (VIP) addresses. The default is HTTPS over port 8082. Creating a new HTTPS Console port requires three steps, discussed in the following sections: ❐

Selecting a keyring (a keypair and a certificate that are stored together)

❐

Selecting an IP address and port on the system that the service will use, including virtual IP addresses

❐

Enabling the HTTPS Console Service

Selecting a Keyring The SG appliance ships with a default keyring that can be reused with each console that you create. You can also create your own keyrings. To use the default keyring, accept the default keyring through the Management Console. If using the CLI, the default keyring is automatically used for each new HTTPS Console that is created.To use a different keyring you must edit the console service and select a new keyring using the attribute keyring command.

15

Volume 2: Proxies and Proxy Services

Note: When using certificates for the HTTPS Console or for HTTPS termination services that are issued by Certificate Signing Authorities that are not well-known, see Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121.

If you get “host mismatch” errors or if the security certificate is called out as invalid, create a different certificate and use it for the HTTPS Console. For information on creating a keypair and a certificate to make a keyring, see Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121.

Selecting an IP Address You can use any IP address on the SG appliance for the HTTPS Console service, including virtual IP addresses. To create a virtual IP address, refer to Volume 5: Advanced Networking.

Enabling the HTTPS Console Service The final step in editing or creating an HTTPS Console service is to select a port and enable the service. To create or edit an HTTPS Console port service: 1.

Select Configuration > Services > Console Services.

2.

Do one of the following: •

To create a new HTTPS Console service, see “About Console Services” on page 13.

•

To edit the configuration of an existing HTTPS Console service, highlight the HTTPS Console and click Edit.

16

Chapter 2: About Console Services

3 4

5

3.

In the Keyring drop-down list, which displays a list of already-created keyrings on the system, select the keyring you want to use. The system ships with a default keyring that is reusable for each HTPPS service. Note: Two keyrings: configuration-passwords-key keyring an application-key keyring cannot be used for console services.

4.

(Optional) Select the appropriate checkboxes to determine the SSL version used for this console.

5.

Click New to add a new listener to the HTTPS console; click Edit to change the current settings. The default IP address value is . To limit the service to a specific IP address, select an IP address from the drop-down list that contains all IP addresses assigned to the SG appliance.

6.

Identify the port you want this service to listen on.

7.

Click OK.

Managing the SSH Console By default, the SG appliance uses Secure Shell (SSH) and password authentication so administrators can access the CLI or Management Console securely. SSH is a protocol for secure remote logon over an insecure network. No action is required unless you want to change the existing SSH host key, disable a version of SSH, or import RSA host keys.

17

Volume 2: Proxies and Proxy Services To create a new SSH Console service or edit an existing one, see “About Console Services” on page 13.

Managing the SSH Host You can manage the SSH host connection through either the Management Console or the CLI. To manage the SSH host: Note: By default, SSHv2 is enabled and assigned to port 22. You do not need to create a new host key unless you want to change the existing configuration.

1.

2.

Select Configuration > Authentication > Console Access > SSH Host.

To delete either SSHv1 or SSHv2 support on the SG appliance, click the appropriate Delete button.

The change is made on the appliance without confirmation. The SSH host tab redisplays with the designated host key deleted. 3.

To add SSHv1 or SSHv2 support, select the Create checkbox for the version you want.

4.

The SSH host key displays in the appropriate pane.

Managing SSH Client Keys You can import multiple RSA client keys on the SG appliance to allow for actions such as logging on to the appliance from different hosts. An RSA client key can only be created by an SSH client and then imported onto the SG appliance. Many SSH clients are commercially available for UNIX and Windows. Once you create an RSA client key following the instructions of your SSH client, you can import the key onto the SG appliance using either the Management Console or the CLI. (For information on importing an RSA key, see“To import RSA client keys:” on page 19.)

18

Chapter 2: About Console Services

Understanding OpenSSH.pub Format Blue Coat supports the OpenSSH.pub format. Keys created in other formats will not work. An OpenSSH.pub public key is similar to the following: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwFI78MKyvL8DrFgcVxpNRHMFKJrBMeBn 2PKcv5oAJ2qz+uZ7hiv7Zn43A6hXwY+DekhtNLOk3HCWmgsrDBE/NOOEnDpLQjBC6t/ T3cSQKZjh3NmBbpE4U49rPduiiufvWkuoEiHUb5ylzRGdXRSNJHxxmg5LiGEiKaoELJfsD Mc= 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]” AAAAB3NzaC1yc2EAAAADAQABAAAAgQCw52JeWr6Fv4kLkzbPZePvapCpaTadPYQwqsGnCI Ydf1We7/8336EmzV918G1jbVT1SI1tM1Ku1BTal7uWAi+aUBGKLl YuyhCTo03 IZFMnsQC7QYzY1y3jufUP3H0be52fg7n7p7gNZR11yzWhVei1vIKiyVKpjqiq6hxCbMb2Q == ---- END SSH2 PUBLIC KEY ----

The OpenSSH.pub format appends a space and a user ID to the end of the client key. The user ID used for each key must be unique. Other caveats: ❐

1024 bits is the maximum supported key size.

❐

An ssh-rsa prefix must be present.

❐

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

To import RSA client keys: 1.

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

The above step must be done with your SSH client. The SG appliance cannot create client keys. 2.

Select Configuration > Authentication > Console Access > SSH Client.

3.

Click Import to import a new host key.

19

Volume 2: Proxies and Proxy Services

4.

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

5.

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

6.

Click OK. The SSH Client tab reappears, with the fingerprint (a unique ID) of the imported key displayed.

7.

Click Apply to commit the changes to the SG appliance.

Relevant CLI Syntax to Manage the SSH Host and Client SGOS (config) ssh-console ❐

The following subcommands are available: SGOS (config ssh-console) create host-keypair {sshv1| sshv2 | } SGOS (config ssh-console) delete {client-key username key_id | legacyclient-key key_id | director-client-key key_id | host-keypair {sshv1 | sshv2 | }} SGOS (config ssh-console) inline {client-key | director-clientkey } SGOS (config ssh-console) view {client-key | director-client-key | host-public-key | user-list | versions-enabled}

20

Chapter 2: About Console Services

Notes on Managing the Telnet Console The Telnet console allows you to connect to and manage the SG appliance using the Telnet protocol. Remember that Telnet is an insecure protocol and therefore should be used only in very secure environments. By default, the Telnet Console is not created. 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.

By default a Telnet shell proxy service exists on the default Telnet port (23). Since only one service can use a specific port, you must delete the shell service if you want to create a Telnet console. Be sure to apply any changes before continuing. If you want a Telnet shell proxy service in addition to the Telnet console, you can re-create it later on a different port. For information on the Telnet service, see Chapter 10: "Managing Shell Proxies" on page 129. To create a new Telnet console service or edit an existing one, see “About Console Services” on page 13. Note: To use the Telnet shell proxy (to communicate with off-proxy systems) and retain the Telnet Console, you must either change the Telnet shell proxy to use a transparent Destination IP address, or change the destination port on either the Telnet Console or Telnet shell proxy. Only one service is permitted on a port. For more information on the Telnet shell proxy, see Chapter 10: "Managing Shell Proxies" on page 129.

21

Volume 2: Proxies and Proxy Services

22

Chapter 3: About Proxy Services

Proxy services define the ports and addresses where the SG appliance listens for incoming requests. A variety of attributes for each service can be defined. Each service can be applied to all IP addresses or limited to a specific set of addresses and port combinations. A number of default services are predefined. Additional services can be defined on other ports. After setting up and enabling the proxy service, the next step is to configure the proxy for your environment. If necessary, you can configure bypass lists for transparent proxy environments. Alternatively, you can specify a list of systems that you do want intercepted. This chapter discusses: ❐

Section A: "Proxy Services" on page 24

❐

Section B: "Bypass List" on page 31

❐

Section C: "Using Restricted Intercept" on page 35

❐

Section D: "Configuring General Options for Proxy Services" on page 37

About Proxy Listeners A proxy listener is the location where the SG appliance listens for traffic for a specific service. A proxy listener can be identified by any destination IP/subnet and port range, and multiple listeners can be added for each service. Note: A proxy listener should not be confused with the default proxy listener, a service that intercepts all traffic not otherwise intercepted by other listeners.

Four settings are available (some settings are not available for some proxy listeners): ❐

: All IP addresses are intercepted.

❐

: Only connections to destination addresses that do not belong to the SG appliance are intercepted

❐

: Only destinations addresses that match one of the IP addresses on the SG appliance are intercepted.

❐

Specific IP address or subnet: Only destination addresses matching the IP address and subnet are intercepted.

23

Volume 2: Proxies and Proxy Services Section A: Proxy Services

Section A: Proxy Services Defaults: ❐

Proxy Edition: Table 3-1, “Proxy Name and Listeners,” on page 24 lists the default SG appliance services and their default listeners. If you have an upgraded appliance, all services existing before the upgrade are preserved.

❐

MACH5 Edition: •

A transparent TCP tunnel connection listening on port 23 is created in place of the default Telnet service.

•

Instant messaging, HTTPS reverse proxy, SOCKS, and Telnet services are not created on the MACH5 Edition SG appliance and are not included in trend data.

Note: Console services, used to manage the SG appliance, are not discussed in this chapter. For information about the four console services—HTTP, HTTPS, SSH, and Telnet—see Chapter 2: "About Console Services" on page 13.

Table 3-1. Proxy Name and Listeners Service Name

Proxy

Destination IP Address

Port Range

Configuration Discussed

AOL-IM

AOL-IM

5190

Volume 2: Proxies and Proxy Services

CIFS

CIFS

445, 139

Chapter 4: "Managing the CIFS Proxy" on page 43

Citrix ICA

TCP-Tunnel

1494

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

DNS

DNS

53

Chapter 5: "Managing the DNS Proxy" on page 59

Endpoint Mapper

Endpoint Mapper

135

Chapter 6: "Managing the Endpoint Mapper and MAPI Proxies" on page 63

FTP

FTP

21

Chapter 7: "Managing the FTP Proxy" on page 77

HTTP

HTTP

80

8080

Chapter 8: "Managing the HTTP Proxy" on page 85

HTTPS

SSL

443

Chapter 12: "Managing the SSL Proxy" on page 145

IMAP

TCP-Tunnel

143

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

IMAPS

TCP-Tunnel

993

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

24

Chapter 3: About Proxy Services

Section A: Proxy Services Table 3-1. Proxy Name and Listeners (Continued) Service Name

Proxy

Destination IP Address

Port Range

Configuration Discussed

Kerberos

TCP-Tunnel

88

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

LDAP

TCP-Tunnel

389

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

LPD

TCP-Tunnel

515

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Lotus Notes

TCP-Tunnel

1352

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

MMS

MMS

1755

Volume 3: Web Communication Proxies

MS SQL Server

TCP-Tunnel

1433

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

MS Terminal Services

TCP-Tunnel

3389

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

MSN-IM

MSN-IM

1863, 6891

Volume 3: Web Communication Proxies

MySQL

TCP-Tunnel

3306

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

NFS

TCP-Tunnel

2049

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Novell GroupWise

TCP-Tunnel

1677

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Novell NCP

TCP-Tunnel

524

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Oracle

TCP-Tunnel

1521, 1525

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

POP3

TCP-Tunnel

110

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

POP3S

TCP-Tunnel

995

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

RTSP

RTSP

554

Volume 3: Web Communication Proxies

Shell

TCP-Tunnel

514

Chapter 10: "Managing Shell Proxies" on page 129

SMTP

TCP-Tunnel

25

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

25

Volume 2: Proxies and Proxy Services Section A: Proxy Services Table 3-1. Proxy Name and Listeners (Continued) Service Name

Proxy

SOCKS

Destination IP Address

Port Range

Configuration Discussed

1080

Chapter 11: "Managing a SOCKS Proxy" on page 137

SSH

TCP-Tunnel

22

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Sybase SQL

TCP-Tunnel

1498

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Telnet

Telnet

23

Chapter 10: "Managing Shell Proxies" on page 129

VNC

TCP-Tunnel

5900

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

XWindows

TCP-Tunnel

6000-6002

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

Yahoo-IM

Yahoo-IM

5050, 5101

Volume 3: Web Communication Proxies

Default (Listens on all unattended ports)

TCP-Tunnel

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

The HTTPS Reverse Proxy service is also available but not created by default. When created, it defaults to an destination IP address on port 443. For information about configuring the HTTPS Reverse Proxy, see Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121.

About Multiple Listeners A listener identifies network traffic based on a destination IP address criterion, a destination port or port range and an action to perform on that traffic. Multiple listeners can be defined for a proxy service or console service. Each service has a set of default actions to apply to the traffic identified by the listeners it owns. The destination IP address of a connection can match multiple proxy service listeners. Multiple matches are resolved using the most-specific match algorithm used by routing devices. A listener is more specific if it has a larger Destination IP subnet prefix. For example, the subnet 10.0.0.0/24 is more specific than 10.0.0.0/16, which is more specific than 10.0.0.0/8. When a new connection is established, the SG appliance first finds the most specific listener Destination IP. If a match is found, and the destination Port also matches, the connection is then handled by that listener. If the destination Port of the listener with the most specific Destination IP does not match, the next most-specific Destination IP is found; this process continues until either a complete match is found or no more matching addresses are found. For example, assume the following services were defined:

26

Chapter 3: About Proxy Services

Section A: Proxy Services Table 3-2. Example Configuration for Most Specific Match Algorithm Proxy Service

Listener

Service Name

Proxy

Destination IP Address

Port Range

New York Data Center

HTTP

10.167.10.0/24

80

New York CRM

HTTP

10.167.10.2/32

80

HTTP Service

HTTP

80

An HTTP connection initiated to server 10.167.10.2 could match any of the three listeners in the above table. The most specific match algorithm finds that a listener in the New York CRM service is the most specific and since the destination port of the connection and the listener match, the connection is handled by this service. The advantage of the most specific match algorithm becomes evident when at some later point another server is added in the New York Data Center subnet. If that server needs to be handled by a different service than the New York Data Center service, a new service with a listener specific to the new server would be added. The administrator does not need to be concerned about rule order in order to intercept traffic to this particular server using the new, most specific service listener.

About Service Attributes The service attributes define the default parameters the SG appliance uses for a particular service. The following table describes the attributes for a proxy service; however, depending on the protocol, not all attributes are available for each proxy type. Table 3-3. Service Attributes Attribute

Description

Authenticate-401

All transparent and explicit requests received on the port always use transparent authentication (cookie or IP, depending on the configuration). This is especially useful to force transparent proxy authentication in some proxy-chaining scenarios.

CA-Cert List Detect Protocol

CA Certificate List used for verifying client certificates. Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

Early Intercept

Use ADN

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server. If you enable the Detect Protocol attribute, the Early Intercept attribute is selected automatically. Controls whether ADN is enabled for a specific service. Enabling ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment).

27

Volume 2: Proxies and Proxy Services Section A: Proxy Services Table 3-3. Service Attributes (Continued) Attribute

Description

Forward Client Cert

When used with the verify-client attribute, puts the extracted client certificate information 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.

Optimize Bandwidth

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

Reflect Client IP

Enables the sending of the client's IP address instead of the SG appliance's IP address to the upstream server. If you are using an Application Delivery Network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab. For more information, refer to Volume 5: Advanced Networking.

SSL Versions

Allows you to select which versions of SSL you want to support. The default is to support SSL v2, v3, and TLS. This attribute is available for HTTPS Reverse Proxy.

Verify Client

Requests and validates the SSL client certificate. This attribute is available for HTTPS Reverse Proxy.

About Access Logging with Proxy Services The access log has one field that contains the service name. ❐

x-service-name (ELFF token) service.name (CPL token)

The name of the

service used to intercept this connection. Note: The x-service-name field replaces the s-sitename field. The s-sitename field

can still be used for backward compatibility with squid log formats, but it has no CPL equivalent.

Creating or Editing a Proxy Service The basic procedure for creating or editing a proxy service is shown below. For additional information about managing a specific proxy, including the proxy service and the proxy configuration, see: ❐

Chapter 4: "Managing the CIFS Proxy" on page 43

❐

Chapter 5: "Managing the DNS Proxy" on page 59

❐

Chapter 6: "Managing the Endpoint Mapper and MAPI Proxies" on page 63

❐

Chapter 7: "Managing the FTP Proxy" on page 77

❐

Chapter 8: "Managing the HTTP Proxy" on page 85

❐

Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121

❐

Chapter 10: "Managing Shell Proxies" on page 129

❐

Chapter 11: "Managing a SOCKS Proxy" on page 137

❐

Chapter 12: "Managing the SSL Proxy" on page 145

28

Chapter 3: About Proxy Services

Section A: Proxy Services ❐

Chapter 13: "Managing the TCP Tunneling Proxy" on page 171

To edit or create a proxy service: 1.

Click Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New. Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and Click Intercept from the drop-down list. You do not need to enter New/Edit mode to change this setting.

4 5

6

8

7

9 10

29

Volume 2: Proxies and Proxy Services Section A: Proxy Services 4.

In the Name field, choose a meaningful name for the new proxy service.

5.

In the Proxy Settings field, select the type of proxy service. The settings below the Proxy field change depending on the kind of proxy you select. (This example is using the TCP-Tunnel proxy.)

6.

Enable or clear the check boxes, as appropriate, for the service being set up. (For information about the various attributes, see Table 3-3, “Service Attributes,” on page 27.)

7.

To create a new listener, click New.

8.

Click a Destination IP address from the radio buttons.

9.

In the Port Range field, enter the ports on which the service should listen. The default ports for each service are discussed in the chapter for each proxy.

10. Select the default action for the service: Bypass tells the service to ignore any traffic matching this listener. Intercept configures the service to intercept and proxy the associated traffic. 11. Click OK; click Apply. Relevant CLI Syntax to Create/Edit a Proxy Service: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create service-type service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {authenticate-401 | adn-optimize | ccl | cipher-suite | detect-protocol | early-intercept | forwardclient-cert | keyring | reflect-client-ip | ssl-versions | use-adn | verify-client} SGOS#(config ip_address | SGOS#(config ip_address |

service-name) bypass {transparent | explicit | all | ip_address/subnet-mask} {port | first_port-last_port} service-name) intercept {transparent | explicit | all | ip_address/subnet-mask} {port | first_port-last_port}

SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port}

Viewing Proxy Services The Proxy Services pane in the Configuration > Services tab contains the list of all services created on the appliance. You can sort the list several ways: ❐

Using the Display Filter at the top of the pane. The drop-down list contains the various proxy names and the bypass/intercept actions. You can select the item you want to filter on.

❐

Clicking the appropriate column title at the top of the table to sort on the column you want.

30

Chapter 3: About Proxy Services

Section B: Bypass List

Section B: Bypass List The bypass list contains IP addresses/subnet masks of client and server workstations. Used only in a transparent proxy environment, the bypass list allows the SG appliance to skip processing requests sent from specific clients to specific servers. The list allows traffic between protocol incompliant clients and servers to pass through the SG appliance without a disruption in service. Note: This prevents the appliance from enforcing any policy on these requests and disables any caching of the corresponding responses. Because bypass entries bypass Blue Coat policy, use bypass sparingly and only for specific situations.

Adding Static Bypass Entries You can add entries to prevent the requests from specified systems from being intercepted by the SG appliance. Note: Dynamic bypass cannot be configured through the Management Console. It can

only be configured through policy or the CLI. For more information, see “ Using Policy to Configure Dynamic Bypass” on page 32. 1.

Click Configuration > Services > Proxy Services > Bypass List.

2.

Click New to create a new list entry; click Edit to modify a list entry.

3.

4.

Fill in the fields: a.

Select a source IP address from the drop-down list or choose . Add the subnet mask.

b.

Select a destination IP address from the drop-down list or choose . Add the subnet mask.

Click OK; click Apply.

Relevant CLI Syntax to Manage Static Bypass Entries ❐

To configure the service: SGOS#(config) proxy-services SGOS#(config proxy-services) static-bypass

❐

The following subcommands are available:

31

Volume 2: Proxies and Proxy Services Section B: Bypass List SGOS#(config static-bypass) add {all | client_ip_address | client_ip_address/subnet-mask} {all | server_ip_address | server_ip_address/subnet-mask} SGOS#(config static-bypass) remove {all | client_ip_address | client_ip_address/subnet-mask} {all | server_ip_address | server_ip_address/subnet-mask} SGOS#(config static-bypass) view {filter {* | all | client_ip_address | client_ip_address/subnet-mask} {* | all | server_ip_address | server_ip_address/subnet-mask} | }

Using Policy to Configure Dynamic Bypass Dynamic bypass, available through policy, can automatically compile a list of response URLs that return various kinds of errors. Note: Because bypass entries bypass Blue Coat policy, the feature should be used sparingly and only for specific situations.

Dynamic bypass keeps its own (dynamic) list of which connections to bypass, where connections are identified by both source and destination. Dynamic bypass can be based on any combination of policy triggers. In addition, some global settings can be used to selectively enable dynamic bypass based on specific HTTP response codes. After an entry exists in the dynamic bypass table for a specific source/destination IP pair, all connections from that source IP to that destination IP are bypassed in the same way as connections that match against the static bypass list. For a configured period of time, further requests for the error-causing URLs are sent immediately to the origin content server (OCS), bypassing the SG appliance. The amount of time a dynamic bypass entry stays in the list and the types of errors that cause the SG appliance to add a site to the list, as well as several other settings, are configurable from the CLI. Once the dynamic bypass timeout for a client and server IP address entry has ended, the SG appliance removes the entry from the bypass list. On the next client request for the client and server IP address, the SG appliance attempts to contact the OCS. If the OCS still returns an error, the entry is once again added to the local bypass list for the configured dynamic bypass timeout. If the entry does not return an error, the request is handled in the normal manner.

Notes ❐

Dynamic bypass entries are lost when the SG appliance is restarted.

❐

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

❐

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

32

Chapter 3: About Proxy Services

Section B: Bypass List

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

Set the desired dynamic bypass timeout and threshold parameters.

❐

Use policy (recommended) or the CLI to enable dynamic bypass and set the types of errors that cause dynamic bypass to add an entry to the bypass list.

Adding Dynamic Bypass Parameters to the Local Bypass List The first step in configuring dynamic bypass is to set the server-threshold, max-entries, or timeout values. Note: This step is optional because the SG appliance uses default configurations if you do not specify them. Use the default values unless you have specific reasons for changing them. Contact Blue Coat Technical Support for detailed advice on customizing these settings. ❐

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

❐

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

❐

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

Enabling Dynamic Bypass and Specifying Triggers Enabling dynamic bypass and specifying the types of errors that causes a URL to be added to the local bypass list are done with the CLI. You cannot use the Management Console. Using policy to enable dynamic bypass and specify trigger events is better than using the CLI, because the CLI has only a limited set of responses. For information about available CLI triggers, refer to the Volume 11: Blue Coat SG Appliance Command Line Reference. For information about using policy to configure dynamic bypass, refer to the Volume 10: Blue Coat SG Appliance Content Policy Language Guide. Bypassing Connection and Receiving Errors In addition to setting HTTP code triggers, you can enable connection and receive errors for dynamic bypass. If connect-error is enabled, any connection failure to the origin content server (OCS), including timeouts, inserts the OCS destination IP address into the dynamic bypass list. If receive-error is enabled, when the cache does not receive an HTTP response on a successful TCP connection to the OCS, the OCS destination IP address is inserted into the dynamic bypass list. Server timeouts can also trigger receive-error. The default timeout value is 180 seconds, which can be changed (refer to Volume 1: Getting Started).

33

Volume 2: Proxies and Proxy Services Section B: Bypass List Related CLI Syntax to Enable Dynamic Bypass and Trigger Events ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) dynamic-bypass

❐

The following subcommands are available: SGOS#(config dynamic-bypass) {enable | disable} SGOS#(config dynamic-bypass) max-entries number SGOS#(config dynamic-bypass) server-threshold number SGOS#(config dynamic-bypass) trigger {all | connect-error | non-http | receive-error | 400 | 403 | 405 | 406 | 500 | 502 | 503 | 504} SGOS#(config dynamic-bypass) timeout minutes #(config dynamic-bypass) no trigger {all | connect-error | non-http | receive-error | 400 | 403 | 405 | 406 | 500 | 502 | 503 | 504} SGOS#(config dynamic-bypass) clear SGOS#(config dynamic-bypass) view

34

Chapter 3: About Proxy Services

Section C: Using Restricted Intercept

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

An entry can exist in both the Static Bypass List and the Restricted Intercept List. However, the Static Bypass List overrides the entries in the Restricted Intercept List. To configure a Restricted Intercept List: 1.

Click Configuration > Services > Proxy Services > Restricted Intercept List.

2.

Click Restrict Interception to the servers and clients listed below-- all other connections are bypassed.

3.

Click New to create a new list entry, or click Edit to modify a list entry.

35

Volume 2: Proxies and Proxy Services Section C: Using Restricted Intercept

4.

To select a specific client to be intercepted, click Client host or subnet and enter the IP Address and Subnet Mask. To select all clients using a specific server, click All clients, then enter the server IP Address and Subnet Mask in the Server address section.

5.

Click OK.

6.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Restricted Intercept Lists ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) restricted-intercept

❐

The following subcommands are available: SGOS#(config restricted-intercept) {enable | disable} SGOS#(config restricted-intercept) add {all | client_ip | client_ip/ subnet-mask} | {all| server_ip | server_ip/subnet-mask} SGOS#(config restricted-intercept) remove {all | client_ip | client_ip/subnet-mask} | all| server_ip | server_ip/subnet-mask} SGOS#(config restricted-intercept) view { | filter {all | client_ip | client_ip/subnet-mask} | {all| server_ip | server_ip/ subnet-mask}

36

Chapter 3: About Proxy Services

Section D: Configuring General Options for Proxy Services

Section D: Configuring General Options for Proxy Services Blue Coat provides two general settings for proxy services: ❐

Trusting the Destination IP Address Provided by the Client If, in your environment, a client sometimes provides a destination IP address that the SG appliance cannot determine, you can configure the SG appliance to allow that IP address and not do a DNS lookup. This can improve performance (but potentially cause a security issue).

❐

Managing User Limits If you have more users going through the system than is allowed by the model license, you can configure overflow behavior to be queued or to bypass the SG appliance.

This section includes the following topics ❐

“Trusting the Destination IP Address Provided by the Client” on page 37

❐

“Managing User Limits” on page 38

❐

“Configuring General Options” on page 41

Trusting the Destination IP Address Provided by the Client You can configure the SG appliance to trust a client-provided destination IP address in transparent proxy deployments where: ❐

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

❐

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

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

The SG appliance receives the client requests in an explicit proxy deployment.

❐

The SG appliance has a forwarding rule configured for the request.

❐

The SG appliance has a SOCKS gateway rule configured for the request.

❐

The SG appliance has ICP enabled for the request.

❐

The SG appliance has policy that rewrites the server URL.

Enabling the SG Appliance to Trust the Client-Provided Destination IP Address Defaults: ❐

Proxy Edition: the SG appliance does not trust a client-provided destination IP address.

❐

MACH5 Edition: The SG appliance trusts client-provided destination IP addresses.

37

Volume 2: Proxies and Proxy Services Section D: Configuring General Options for Proxy Services You can change this default through the Management Console, the CLI, or through policy. If you use policy, be aware that it overrides any other configuration. For information about using the trust_destination_ip(yes|no) property, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide. Note:

If you use the MACH5 edition, the SG appliance allows the client-provided destination IP address by default. For information about enabling the SG appliance to allow the client-provided destination IP address, see “Configuring General Options” on page 41.

Tip If a client gives the destination address of a blocked site but the hostname of a nonblocked site, the SG appliance connects to the destination address. This might allow clients to bypass the configured SG appliance security policy.

Managing User Limits If your SG appliance is in demo or trial mode, an unlimited number of users can have connections processed by the system at the same time. . After a permanent model license has been applied to the system, the license controls the number of active users who can have connections processed by the system at the same time The number of users depends on whether ADN is enabled and on the hardware model. Only unique IP addresses of connections intercepted by proxy services are counted toward the user limit. The number of permitted users is illustrated in the table below. Table 3-4. Hardware Models and Licensed Users Hardware Model

Number of Users (Without ADN Enabled)

Number of Users (With ADN Enabled)

210-5

30

10

210-10

150

50

210-25

Not License Limited

Not License Limited

510-5

200

50

510-10

500

125

510-20

1200

300

510-25

Not License Limited

Not License Limited

810-5

2500

500

810-10

3500

700

810-20

5000

1000

810-25

Not License Limited

Not License Limited

8100-5

Not License Limited

Not License Limited

38

Volume 2: Proxies and Proxy Services Section D: Configuring General Options for Proxy Services Table 3-4. Hardware Models and Licensed Users (Continued) Hardware Model

Number of Users (Without ADN Enabled)

Number of Users (With ADN Enabled)

8100-10

Not License Limited

Not License Limited

8100-20, 8100-20-DC

Not License Limited

Not License Limited

Determining Behavior if User Limits are Exceeded If you have more user connections going through the system simultaneously than is allowed by the model license, you can configure overflow behavior in the following ways: ❐

Bypassing the system: All connections exceeding the maximum are passed through the system without processing.

❐

Queuing connections: All connections exceeding the maximum are queued, waiting for another connection to drop off.

❐

Not enforcing the licensed-user limit: This is the default value for SGOS 5.2.2 and higher. Note:

SGOS 5.2.1 has two options only: Queue and Bypass. Queue is the default.

To set the preferred behavior, see “Configuring General Options” on page 41.

Setting User Limits Notifications You can set and monitor user limits of the model license through the Maintenance > Health Monitoring > Licensing tab, including setting thresholds (in percentages) to be notified if the user limits are nearing the upper user limits. Note: You can use the Statistics > Health Monitoring > Licensing tab to view licensing metrics, but you cannot make changes to the threshold values from that tab. To change the thresholds, use the Maintenance > Health Monitoring > Licensing tab.

To view licensing metrics and set user limits notifications: 1.

Click Maintenance > Health Monitoring > Licensing.

39

Volume 2: Proxies and Proxy Services Section D: Configuring General Options for Proxy Services

2.

Select the license to edit.

3.

Click Edit.

4.

Modify the threshold values. Note that the thresholds represent the percentage of license utilization. a.

To change the critical threshold, enter a new value in the Critical Threshold field.

b.

To change the critical interval, enter a new value in the Critical Interval field.

c.

To change the warning threshold, enter a new value in the Warning Threshold field.

d. To change the warning interval, enter a new value in the Warning Interval field. 5.

Select the notification settings. •

Log adds an entry to the Event log.

•

Trap sends an SNMP trap to all configured management stations.

•

Email sends an e-mail to the addresses listed in the Event log properties.

6.

Click OK.

7.

Click Apply to commit the changes to the SG appliance. Note:

For information about licensing metrics, refer to Volume 9: Managing the Blue Coat SG Appliance. Related CLI Syntax to Manage User Limits SGOS#(config) alert notification license-utilization users {email | log | trap | none} SGOS#(config) alert threshold license-utilization users warn-threshold warn-interval crit-threshold crit-interval

40

Volume 2: Proxies and Proxy Services Section D: Configuring General Options for Proxy Services

Viewing Concurrent Users View a snapshot of intercepted, concurrent users by selecting the Statistics > System > Resources > Concurrent Users tab. The tab shows user connections going through the SG appliance for the last 60 minutes, day, week, month, and year. Only unique IP addresses of connections intercepted by proxy services are counted toward the user limit.

Configuring General Options You can configure both the trusted destination IP address and the behavior if user limits are exceeded on the Configuration > Proxy Settings > General tab. (For detailed information on these options, see Section D: "Configuring General Options for Proxy Services" on page 37 To configure General options: 1.

Click Configuration > Proxy Settings > General.

41

Volume 2: Proxies and Proxy Services Section D: Configuring General Options for Proxy Services

2.

Select or clear the Trust client-provided destination IP when connecting to servers check box.

3.

Click the radio button for the User Overflow Action you prefer when the licensed-user limits are exceeded. By default, for SGOS 5.2.2 and later, none is the default. Note:

If you set the User Overflow Action to none and exceed the licensed-user limits, the SG appliance health changes to CRITICAL. 4.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Manage User Limit Notifications SGOS#(config) general SGOS#(config general) trust-destination-ip {enable | disable} SGOS#(config general) user-overflow-action {bypass | none | queue}

42

Chapter 4: Managing the CIFS Proxy

This chapter discusses the Common Internet File System (CIFS) protocol and describes how to configure the services and proxy on the SG appliance. Note: The CIFS protocol is based on the Server Message Block (SMB) protocol used for

file sharing, printers, serial ports, and other communications. It is a client-server, request-response protocol.

About CIFS CIFS allows computers to share files and printers, supports authentication, and is popular in enterprises because it supports all Microsoft operating systems, clients, and servers. File servers make file systems and other resources (printers, mailslots, named pipes, APIs) available to clients on the network. Clients have their own hard disks, but they can also access shared file systems and printers on the servers. Clients connect to servers using TCP/IP. After establishing a connection, clients can send commands (SMBs) to the server that allows them to access shares, open files, read and write files— the same tasks as with any file system, but over the network. CIFS is beneficial because it is generic and compatible with the way applications already share data on local disks and file servers. More than one client can access and update the same file, while not compromising file-sharing and locking schemes. However, the challenge for an enterprise is that CIFS communications are inefficient over low bandwidth lines or lines with high latency, such as in enterprise branch offices. This is because CIFS transmissions are broken into blocks of data (typically close to 64 KB). The client must stop and wait for each block to arrive before requesting the next block. Each stop represents time lost instead of data sent. Therefore, users attempting to access, move, or modify documents experience substantial, workprohibiting delays.

About the Blue Coat CIFS Proxy Solution The CIFS proxy on the SG appliance combines the benefits of the CIFS protocol with the abilities of the SG appliance to improve performance, reduce bandwidth, and apply basic policy checks. This solution is designed for branch office deployments because network administrators can consolidate their Windows file servers (at the core office) instead of spreading them across the network.

43

Volume 2: Proxies and Proxy Services

Figure 4-1. CIFS Proxy Traffic and Flow Diagram

Caching Behavior The CIFS proxy caches the regions of files that are read or written by the client (partial caching) and applies to both read and write file activities. Also, the caching process respects file locking. Note: Caching behavior can also be controlled with policy.

Authentication The CIFS proxy supports both server and proxy authentication in the following contexts.

44

Chapter 4: Managing the CIFS Proxy

Server Authentication Permissions set by the origin content server (OCS) are always honored. Requests to open a file are forwarded to the OCS; if the OCS rejects the client access request, no content is served from the cache. Note: NTLM/IWA authentication requires that the client knows what origin server it

is connecting to so it can obtain the proper credentials from the domain controller.

Proxy Authentication The SG appliance cannot issue a challenge to the user over CIFS, but it is able to make use of credentials acquired by other protocols if IP surrogates are enabled.

Policy Support The CIFS proxy supports the proxy, cache, and exception policy layers. However, the SMB protocol can only return error numbers. Exception definitions in the forms of strings cannot be seen by an end user. See “Reference: CPL Triggers, Properties, and Actions” on page 57 for supported CPL triggers and actions.

Access Logging By default, the SG appliance uses a Blue Coat-derived CIFS access log format. date time c-ip r-ip r-port x-cifs-method x-cifs-server x-cifs-share x-cifs-path x-cifs-orig-path x-cifs-client-bytes-read x-cifs-server-bytes-read x-cifs-bytes-written x-cifs-file-type s-action cs-username cs-auth-group s-ip

For a reference list and descriptions of used log fields, see “Reference: Access Log Fields” on page 54.

WCCP Support If WCCP is deployed for transparency, you must configure WCCP to intercept TCP ports 139 and 445.

Configuring the SG CIFS Proxy This section contains the following sub-sections: ❐

“About Windows Security Signatures” on page 45

❐

“Configuring CIFS Proxy Services” on page 47

❐

“Configuring the CIFS Proxy” on page 49

❐

“Reviewing CIFS Protocol Statistics” on page 51

About Windows Security Signatures Security signatures prevent the CIFS proxy from providing its full acceleration capabilities. Additionally, security signatures require a considerable amount of processing on both clients and servers. As their benefits are often superseded by link-layer security measures, such as VPNs and restricted network topology, the benefits are minimal and the drawbacks are high. The CIFS proxy requires that security signatures are disabled.

45

Volume 2: Proxies and Proxy Services

If you know this setting is disabled on your clients or servers, you can proceed to “Configuring CIFS Proxy Services” on page 47. To verify the state of security signatures in Windows; disable if necessary: Note: This procedure follows the Control Panel Classic View format. The screen shots represent Microsoft Windows XP.

1.

In Windows, select Start > Control Panel > Administrative Tools > Local Security Policy. The Local Security Settings dialog appears.

2

3

2.

Select Local Policies > Security Options.

3.

Perform one of the following: •

Windows XP/2003: Right-click Microsoft network client: Digitally sign communications (always) and select Properties. A configuration dialog appears.

•

Windows 2000: Right-click Digitally sign client communications (always). A configuration dialog appears.

46

Chapter 4: Managing the CIFS Proxy

4.

Select Disabled. Click Apply and OK.

5.

Repeat for the server options: •

Windows XP/2003: Right-click Microsoft network server: Digitally sign communications (always).

• 6.

Windows 2000: Right-click Digitally sign server communications (always).

Close all Control Panel dialogs. Important:

If the server is an ADS/Domain controller, you must set the same security settings for both Administrative Tools > Domain Controller Security Policy and Administrative Tools- > Domain Security Policy. Otherwise, you cannot open file shares and Group Policy snap-ins on your server. 7.

You must reboot the client or server to apply this configuration change.

Configuring CIFS Proxy Services By default (upon upgrade and on new systems), the SG appliance has CIFS services configured for transparent connections on ports 139 and 445. Blue Coat creates listener services on both ports because different Windows operating systems (older versus newer) attempt to connect using 139 or 445. For example, Windows NT and earlier only used 139, but Windows 2000 and later try both 139 and 445. Therefore only configuring one port can potentially cause only a portion of Windows 2000 and newer CIFS traffic to go through the proxy. A transparent connection is the only supported method; the CIFS protocol does not support explicit connections. Also, by default these services are configured to accept all IP addresses in Bypass mode. The following procedure describes how to change them to Intercept mode, and explains other attributes within the service. To configure the CIFS proxy service attributes: 1.

From the Management Console, select Configuration > Services > Proxy Services.

47

Volume 2: Proxies and Proxy Services

2

3

2.

Scroll the list of services to display the default CIFS service line. Notice the Action is Bypass. You can select Intercept from the drop-down list, but for the purposes of this procedures, select the service line to highlight it.

3.

Click Edit. The Edit Service dialog appears, with some default settings, is displayed.

4a

4b

4c

4d

48

Chapter 4: Managing the CIFS Proxy

4.

Understand the service attributes: a.

(Optional) The default service name is CIFS, which identifies the service type.

b.

The TCP/IP Settings options allow you to manage the data connections:

c.

•

Reflect Client IP: If this is enabled, the connection to the CIFS server appears to come from the client, not the SG appliance.

•

Early Intercept: You cannot enable Early Intercept for the CIFS proxy.

Enabling the ADN Optimization option is recommended by Blue Coat. This feature improves performance by compressing request and response data, which still needs to be forwarded across the WAN. For more information about ADN optimization, refer to Volume 5: Advanced Networking.

d. In the Listeners field, select Intercept from the drop-down list; the SG appliance must intercept the CIFS connection. Perform this step for both ports. Note: You can also change the mode from Bypass to Intercept from the main services page.

e.

Click OK; click Apply.

Result: The CIFS service is configured and appears in Management Console.

Now that the CIFS listeners are configured, you can configure the CIFS proxy.

Configuring the CIFS Proxy The CIFS proxy options configure folder management and file reading and writing. These options are enabled by default because they maximize the benefits of a CIFS proxy deployment. This section describes these options and why they might require changing based on your branch deployment. To view/change the CIFS proxy configuration options: 1.

In the Management Console, select Configuration > Proxy Settings > CIFS Proxy.

49

Volume 2: Proxies and Proxy Services

2a 2b 2c 2d

2.

Configure the CIFS proxy options: a.

Read ahead: Enabled by default, which reduces the latency of the connection.

The SG appliance might partially cache a requested object (the part directly requested and viewed by the client). When Read ahead is enabled, the appliance attempts to anticipate what block of data (up to 64K) might be requested next, fetches it, and caches it. If applications are performing a large amount of non-sequential file access, disabling Read Ahead reduces the amount of unnecessary data being fetched into the cache. b.

Write back: Enabled by default. This option applies to when clients attempt to

write to a file on the core server. Without the CIFS proxy, a client would experience substantial latency as it sends data chunks and waits for the acknowledgement from the server to write the next data chunks. With this option enabled the branch SG appliance is viewed by the client as the file server; the appliance constantly sends approval to the client and allows the client to write data while on the back end takes advantage of the compressed TCP connection and sends the data to the core server. A reason for disabling this option is the risk of data loss if the link from the branch to the core fails. There is no way to recover queued data if such a link failure occurs. c.

Never Serve Directories After Expiration: Disabled by default. When this option is enabled and Directory Cache Time has a value of 0, directories are refreshed synchronously instead of in the background. This is needed when the set of visible objects in a directory returned by a server can vary between users.

d. Directory Cache Time: This option determines how long directory information is kept in cache. Changes made to a directory by clients not using the SG appliance are not visible to SG clients if they occur within this time interval. The default cache time is 30 seconds. Blue Coat recommends keeping this value low to ensure clients have access to the most current directory information; however, you can set it longer if your applications use CIFS to access files. For example, the cache responds faster if it knows directory X does not contain the file and so moves on to directory Y, which reduces the number of round trips to the file server. 3.

If you changed any options, click Apply.

Enabling CIFS Access Logging By default, the SG appliance is configured to use the Blue Coat CIFS access log format. Access Logging is enabled on the Configuration > Access Logging > General page. For information about access log customization, refer to Volume 8: Access Logging.

50

Chapter 4: Managing the CIFS Proxy

Reviewing CIFS Protocol Statistics After CIFS traffic begins to flow through the SG appliance, you can review the statistics page and monitor results in various CIFS categories. The presented statistics are representative of the client perspective. To review CIFS statistics: 1.

From the Management Console, select Statistics > CIFS History.

2.

View statistics:

2a

2b

3

a.

b.

3.

Select a statistic category tab: •

CIFS Objects: The total number of CIFS-related objects processed by the SG appliance (read and written).

•

CIFS Bytes Read: The total number of bytes read by CIFS clients.

•

CIFS Bytes Written: The total number of bytes written by CIFS clients (such as updating existing files on servers).

•

CIFS Clients: The total number of connected CIFS clients.

•

CIFS Bandwidth Gain: The total bandwidth usage for clients (yellow) and servers (blue), plus the percentage gain.

The graphs display three time metrics: the previous 60 minutes, the previous 24 hours, and the previous 60 days. Roll the mouse over any colored bar to view the exact metric.

(Optional) You can change the scale of the graph to display the percentage of bar peaks to display.

51

Volume 2: Proxies and Proxy Services

Statistic URL Pages Additional CIFS statistics pages are viewable from Management Console URLs. Statistics This page displays various, more granular connection and byte statistics. https://SG_IP_address:8082/CIFS/statistics

If CIFS traffic interception is occurring (the above screenshot does not represent active traffic), the byte counters increment when a user opens a file or browses around. Note: The bytes to/from servers counters on the CIFS statistics page do not include the effects of compression and byte caching over the WAN link.

Connections This page displays specific client-to-server connection and file information and statistics. https://SG_IP_address:8082/CIFS/connection

52

Chapter 4: Managing the CIFS Proxy

Click connection ID link to drill down to more details.

Reference: Equivalent CIFS Proxy CLI Commands The Management Console procedures in this chapter have the following equivalent CLI command roots: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create cifs service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {adn-optimize {enable | disable}| reflect-client-ip {enable | disable}} SGOS#(config service-name) bypass {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port}} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port}} SGOS#(config service-name) remove {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

53

Volume 2: Proxies and Proxy Services

❐

To set other configuration parameters: SGOS#(config service-name) exit SGOS#(config) cifs SGOS#(config cifs)

❐

The following subcommands are available: SGOS#(config SGOS#(config SGOS#(config SGOS#(config SGOS#(config SGOS#(config

cifs) cifs) cifs) cifs) cifs) cifs)

directory-cache-time seconds exit read-ahead {disable | enable} strict-directory-expiration {disable | enable} view {configuration | statistics} write-back (full | none}

Reference: Access Log Fields The default Blue Coat CIFS Access Log fields are: ❐

c-ip: IP address of the CIFS client.

❐

c-port: The CIFS client port TCP connection.

❐

cs-auth-group: One group that an authenticated user belongs to. If a user belongs to

multiple groups, the group logged is determined by the Group Log Order configuration specified in VPM. If the Group Log Order is not specified, an arbitrary group is logged. Note that only groups referenced by policy are considered. ❐

cs-username: Relative username of a client authenticated to the proxy (for example: not fully distinguished).

❐

r-ip: IP address from the outbound server URL.

❐

r-port: Port from the outbound server URL, typically 139 or 445.

❐

s-action: The logging action (or flow) being one of the following:

•

ALLOWED: CIFS operation passed the policy checkpoint and was also successful.

•

DENIED: CIFS operation failed the policy checkpoint.

•

ERROR: CIFS operation resulted in an error on the server; typically associated with NT (x-cifs-nt-error-code) or DOS error (x-cifs-dos-error-code, x-cifsdos-error-class).

•

FAILED: CIFS operation was successful on the server but failed on the proxy for some internal reason.

•

SUCCESS: CIFS operation was successful on the server (did not go through policy checkpoint).

❐

s-ip: IP address of the appliance on which the client established its connection.

❐

x-cifs-client-bytes-read: Total number of bytes read by a CIFS client from the associated resource. For OPEN/CLOSE, it is the total for that specific file. For MOUNT/ UNMOUNT, the total for all files accessed in that share. For LOGON/LOGOFF, the total for all files accessed in that session. For CONNECT/DISCONNECT, the total for all files accessed during that connection.

❐

x-cifs-client-write-operations: Total number of client write operations for this particular resource. The scope is the same as x-cifs-client-read-operations.

54

Chapter 4: Managing the CIFS Proxy

❐

x-cifs-client-other-operations: Total number of client operations that are not reads or writes for this particular resource. The scope is the same as x-cifs-clientread-operations. MOUNT/UNMOUNT might also include operations not tied to a specific open file.

❐

x-cifs-bytes-written: Total number of bytes written to the associated resource.

❐

x-cifs-dos-error-class: DOS error class generated by server, in hexadecimal.

❐

x-cifs-dos-error-code: DOS error code generated by server, in hexadecimal.

❐

x-cifs-error-cod: CIFS error code generated by server. If the error code is in NT format, it is a single hexadecimal number of the form 0xNNNNNNNN. If the error code is in DOS format, it is two hexadecimal numbers of the form 0xNN/0xNNNN. The first number is the DOS error class, and the second is the DOS error code. This field is a combination of the x-cifs-nt-error-code, x-cifs-dos-error-class, and x-cifsdos-error-code.

❐

x-cifs-fid: Numeric ID representing a CIFS resource.

❐

x-cifs-file-size: Size in bytes of CIFS resource.

❐

x-cifs-file-type: The type of file that was opened or closed. Values are file, directory, pipe, or other. It is only valid if x-cifs-method is OPEN, CLOSE, CLOSE_ON_UNMAP, CLOSE_ON_LOGOFF, CLOSE_ON_DISCONNECT, or CLOSE_ON_PASSTHRU.

❐

x-cifs-method: The method associated with the CIFS request. The list of CIFS

methods are: •

CONNECT: For TCP-level connect from client to CIFS server.

•

DISCONNECT: For TCP-level connection shutdown.

•

LOGON: For SESSION_SETUP_ANDX SMB command.

•

LOGOFF: For LOGOFF_ANDX SMB command.

•

LOGOFF_ON_PASSTHRU: For removal of cached session from proxy upon PASSTHRU.

•

LOGOFF_ON_DISCONNECT: For removal of cached session from proxy upon

DISCONNECT. •

MAP: For TREE_CONNECT SMB command.

•

UNMAP: For TREE_DISCONNECT SMB command.

•

UNMAP_ON_LOGOFF: For removal of cached share from proxy upon LOGOFF.

•

UNMAP_ON_PASSTHRU: For removal of cached share from proxy upon PASSTHRU.

•

UNMAP_ON_DISCONNECT: For removal of cached share from proxy upon DISCONNECT.

•

DELETE: For path-based DELETE and DELETE_DIRECTORY SMB commands.

•

DELETE_ON_CLOSE: For delete-on-close action done on a CIFS resource.

•

LIST: For enumerating contents of a directory.

•

OPEN: For opening a CIFS resource.

•

RENAME: For renaming a CIFS resource.

•

CLOSE: For closing a CIFS resource.

•

CLOSE_ON_UNMAP: For removal of cached file from proxy upon UNMAP.

55

Volume 2: Proxies and Proxy Services

•

CLOSE_ON_LOGOFF: For removal of cached file from proxy upon LOGOFF.

•

CLOSE_ON_PASSTHRU: For removal of cached file from proxy upon PASSTHRU.

•

CLOSE_ON_DISCONNECT: For removal of cached file from proxy upon DISCONNECT.

•

PASSTHRU: For connections which Blue Coat is unable to handle:

•

•

Client or server does not support NTLM 0.12 dialect.

•

Security signatures are enabled.

•

Client or server does not support Unicode characters.

•

The SESSION_SETUP_ANDX SMB request is malformed (with unknown word count).

•

Header portion of some SMB command is malformed.

•

NETBIOS header is malformed.

OPEN_STATS: Log the same fields as CLOSE for gathering time-based activity

information on open files. This occurs on a 5 minute interval if there was activity on the file within that interval. ❐

x-cifs-nt-error-code: CIFS error code generated by server, in hexadecimal.

❐

x-cifs-orig-path: Original path name of resource to be renamed.

❐

x-cifs-orig-unc-path: UNC path of original path name of resource to be renamed.

❐

x-cifs-path: CIFS resource name as specified in the UNC path.

❐

x-cifs-server: CIFS server as specified in the UNC path.

❐

x-cifs-server-bytes-read: Total number of bytes read from CIFS server from the

associated resource. ❐

x-cifs-server-operations: Total number of server operations for this particular resource. The scope is the same as x-cifs-client-read-operations.

❐

x-cifs-share: CIFS share name as specified in the UNC path.

❐

x-cifs-tid: ID representing instance of an authenticated connection to server

resource. ❐

x-cifs-uid: ID representing an authenticated user instance.

❐

x-cifs-unc-path: CIFS path of form \\server\share\path where path might be

empty. ❐

x-client-connection-bytes: Number of bytes sent to and received from the client.

❐

x-server-connection-bytes: Number of bytes sent to and received from the server.

If ADN is used for the server connection, this is the number of bytes before ADN compression is applied. ❐

x-server-adn-connection-bytes: Number of bytes sent to and received from the server-side ADN peer if ADN is used for the server connection. If ADN is not used, this is displayed as "-".

56

Chapter 4: Managing the CIFS Proxy

Reference: CPL Triggers, Properties, and Actions The following CPL applies to CIFS policy:

Triggers ❐

attribute.=, has_attribute.=

❐

client.address=, client.host=, client.host.has_name=

❐

client.protocol=smb

❐

content_management=no

❐

condition=

❐

date[.utc]=, day=, hour=, minute=, month=, weekday=, year=, time=

❐

has_client=

❐

proxy.address=, proxy.port=, proxy.card=

❐

raw_url=

❐

release.*=

❐

server_url=

❐

socks.accelerated=smb

❐

tunneled=

❐

url=smb://:/

❐

user.*=, group=, realm=, authenticated=

Properties and Actions: ❐

action()

❐

access_log.*(), log.*(), log_message(), notify_email(), notify_snmp()

❐

authenticate.*()

❐

allow, deny, deny.*(), exception.*(), force_deny.*(), force_exception.*()

❐

bypass_cache()

❐

detect_protocol(smb), force_protocol(smb)

❐

forward(), forward.fail_open(), socks_gateway(), socks_gateway.fail_open()

❐

limit_bandwidth(smb)

❐

reflect_ip()

❐

rewrite(url), rewrite(url.host), set(url.port)

❐

trace.*()

57

Volume 2: Proxies and Proxy Services

58

Chapter 5: Managing the DNS Proxy

When a DNS proxy service is enabled, it listens on port 53 for both explicit and transparent DNS domain query requests. By default, the service is created but not enabled. The DNS does a lookup of the DNS cache to determine if requests can be answered. If yes, the SG appliance responds. If not, the DNS forwards the request to the DNS server list configured on the SG appliance. (To configure the DNS server list, see Configuration > Network > DNS.) Note: The SG appliance is not a DNS server. It does not do zone transfers, and recursive queries are forwarded to other name servers.

For information on managing DNS name servers, refer to Volume 1: Getting Started. Through policy, you can configure the list of resolved domain names (the resolving name list) the DNS uses. The domain name in each query received by the SG appliance is compared against the resolving name list. Upon a match, the appliance checks the resolving list. If a domain name match is found but no IP address was configured for the domain, the appliance sends a DNS query response containing its own IP address. If a domain name match is found with a corresponding IP address, that IP address is returned in a DNS query response. All unmatched queries are sent to the name servers configured on the SG appliance. This chapter discusses: ❐

“Creating or Editing a DNS Proxy Service”

❐

“ Creating a Resolving Name List” on page 61

Creating or Editing a DNS Proxy Service To create or edit a DNS proxy service: 1.

Select Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New.

Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

59

Volume 2: Proxies and Proxy Services

4 5

6

7b 7a

7c 7d

4.

In the Name field, choose a meaningful name for the new proxy service.

5.

From the Proxy drop-down list, select DN Proxy.

6.

Select or de-select the checkboxes, as appropriate, for the environment a.

Reflect Client IP: Enables or disables sending of client's IP address instead of

the SG appliance's IP address. b. 7.

Early intercept: This option cannot be changed when creating or editing a DNS proxy service.

Create a new listener: a.

Click New.

b.

Define the Destination IP information.

c.

In the Port Range field, enter the ports on which the service should listen. The default port is 53.

d. Select the default action for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e. 8.

Click OK.

Click Apply.

60

Chapter 5: Managing the DNS Proxy

Relevant CLI Syntax to Create/Edit a DNS Proxy Service ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create dns service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute reflect-client-ip {enable | disable} SGOS#(config service-name) bypass {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

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 Volume 10: Blue Coat SG Appliance Content Policy Language Guide.) Each name resolving list entry contains a domain-name matching pattern. The matching rules are: ❐

test.com matches only test.com and nothing else.

❐

.test.com matches test.com, www.test.com and so on.

❐

“.” matches all domain names.

An optional IP address can be added, which allows the DNS proxy to return any IP address if the DNS request's name matches the domain name suffix string (domain.name). To create a resolving name list, create a policy, using the layer, that contains text similar to the following: dns.request.name=www.example.com dns.respond.a(vip) -or dns.request.name=.example.com dns.respond.a(vip) -or dns.request.name=www.example.com dns.respond.a(10.1.2.3) Note: You can also create a resolving name list using VPM. For more information on using the DNS-Proxy layer in VPM, refer to Volume 1: Getting Started.

61

Volume 2: Proxies and Proxy Services

62

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

This chapter discusses the Endpoint Mapper and MAPI proxy solutions, and describes how to configure the services and proxy configuration. The Endpoint Mapper and MAPI proxies are similar in that they accelerate Microsoft applications across a WAN; however, there are key differences. This chapter contains the following sections: ❐

Section A: "The Endpoint Mapper Proxy Service" on page 64.

❐

Section B: "The MAPI Proxy" on page 70.

63

Volume 2: Proxies and Proxy Services Section A: The Endpoint Mapper Proxy Service

Section A: The Endpoint Mapper Proxy Service This section discusses the Microsoft Remote Procedure Call (RPC) protocol and describes how to configure the Endpoint Mapper proxy service on the SG appliance.

About RPC The Microsoft RPC protocol functions across a client/server model where one application requests a service from another application. The requesting program is the client; the providing service is the server. RPC allows an application on one host (the client) to request and thereby cause an application on another host (the server) to execute an action without the requirement of explicit code. For example: MAPI traffic. Typically, RPC communications occur when the client contacts the Endpoint Mapper service on that client host to determine how to contact the server. The client provides the RPC service identifier and the Endpoint Mapper service returns the IP and port the client uses to contact the server. Then, the client makes a new TCP connection to that IP and port and sends its RPC request. The challenges occur when these communications occur between branch offices and servers located in core locations. The user experience is poor because of low available bandwidth or high latency lines.

About the Blue Coat Endpoint Mapper Proxy Solution The Endpoint Mapper proxy intercepts an RPC client request for a particular RPC service. The Endpoint Mapper proxy looks up the request in its local database, and if there is a match it replies to the client the port number the RPC service is listening on. If it is not in the database, it forwards the request up to the server. The server responds with the port number the service is listening on, and the Endpoint Mapper proxy populates its internal database. It then creates a secondary listener on that RPC port and server IP address, and responds to the RPC client with the port number. When the RPC client connects to the service, the Endpoint Mapper proxy secondary service intercepts the request and tunnels it. Substantial performance increase occurs because: ❐

The SG appliance caches server information, negating the requirement to connect to an upstream server for repeated requests.

❐

The SG appliance at the branch compresses RPC traffic and sends it over the TCP connection to the core SG appliance, which decompresses the data before sending it to the RPC server.

The Endpoint Mapper proxy can be deployed in both transparent and explicit modes. Intercepting RPC traffic is part of the complete solution that includes the MAPI proxy ("Section B: The MAPI Proxy" on page 70). Note: Only Microsoft RPC version 5.0 is supported. Unsupported Microsoft RPC version traffic is passed through the SG appliance without processing.

64

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section A: The Endpoint Mapper Proxy Service

Policy Support The Endpoint Mapper proxy supports any policy that applies to TCP tunnel connections. See “Reference: CPL Triggers, Properties, and Actions” on page 68 for supported CPL triggers and actions.

Access Logging Each TCP connection results in an access log entry. Both the Endpoint Mapper proxy and secondary tunnel traffic activities are logged. The SG appliance main access log format is used by default. Note: If the access log for the primary connection changes to a new log, the secondary

connections are also moved to the new log. For a reference list and descriptions of used log fields, see “Reference: Access Log Fields” on page 67.

Configuring the SG Appliance Endpoint Mapper Service By default (upon upgrade and on new systems), the SG appliance has an Endpoint Mapper service configured on port 135. The service is also configured to listen to all IP addresses, but is set in Bypass mode. The following procedure describes how to change the service to Intercept mode, and explains other attributes within the service. To configure the Endpoint Mapper service attributes: 1.

From the Management Console, select Configuration > Services > Proxy Services.

2

3

2.

Scroll the list of services to display the default Endpoint Mapper service line. Notice the Action is Bypass. You can select Intercept from the drop-down list, but for the purposes of this procedures, select the service line to highlight it.

3.

Click Edit. The Edit Service dialog appears, with some default settings, is displayed.

65

Volume 2: Proxies and Proxy Services Section A: The Endpoint Mapper Proxy Service

4a

4b

4c

4d

4.

Configure the service attributes: a.

(Optional) The default service name is Endpoint Mapper, which identifies the service type.

b.

The TCP/IP Settings options allow you to manage the data connections:

c.

•

Reflect Client IP: If this is enabled, the connection to the RPC server appears to come from the client, not the SG appliance.

•

Early Intercept: Not available for this feature.

Enabling the ADN Optimize option is recommended by Blue Coat. This feature improves performances by compressing request and response data, which still needs to be forwarded across the WAN. For more information about ADN optimization, refer to Volume 5: Advanced Networking.

d. In the Listeners field, select Intercept from the drop-down list; the SG must intercept the RPC connection. Note: You can also change the mode from Bypass to Intercept from the main

services page. e. 5.

Click OK.

Click Apply.

66

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section A: The Endpoint Mapper Proxy Service Result: The Endpoint Mapper service is configured and appears in Management Console. RPC traffic is intercepted.

Reviewing Endpoint Mapper Proxy Statistics After RPC traffic begins to flow through the SG appliance, you can review the statistics page and monitor results in various categories. The presented statistics are representative of the client perspective.

Statistic URL Pages Endpoint Mapper proxy statistics pages are viewable from Management Console URLs. Statistics This page displays various, more granular connection and byte statistics. https://SG_IP_address:8082/epmapper/statistics

Detailed Statistics This page displays specific client-to-server connection and file information and statistics. https://SG_IP_address:8082/epmapper/detailed-statistics

Reference: Equivalent Endpoint Mapper Proxy CLI Commands The Management Console procedures in this section have the following equivalent CLI command roots: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create endpoint-mapper service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {all | ip_address | ip_address/subnetmask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {adn-optimize {enable | disable}| reflect-client-ip {enable | disable}} SGOS#(config service-name) bypass {all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port}} SGOS#(config service-name) exit SGOS#(config service-name) intercept {all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port}} SGOS#(config service-name) remove {all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

Reference: Access Log Fields The default SG appliance Endpoint Mapper Access Log fields are: ❐

date: GMT Date in YYYY-MM-DD format.

❐

time: GMT time in HH:MM:SS format.

67

Volume 2: Proxies and Proxy Services Section A: The Endpoint Mapper Proxy Service ❐

cs-bytes, sr-bytes, rs-bytes, sc-bytes: Standard ELFF format. The total RPC

byte counts in the specified direction (client-server). ❐

cs-method: Request method used from client to appliance.

❐

time-taken: Time taken (in milliseconds) to process the request.

❐

c-ip: IP address of the RPC client.

❐

s-action: The logging action (or flow) being one of the following:

•

ALLOWED: Endpoint operation passed the policy checkpoint and was also successful.

•

DENIED: Endpoint operation failed the policy checkpoint.

•

FAILED: Endpoint operation was successful on the server but failed on the proxy for some internal reason.

•

TUNNELED: Traffic was tunneled.

❐

cs-uri-scheme: Scheme from the log URL.

❐

cs-host: Hostname from the client's request URL. If URL rewrite policies are used,

this field's value is derived from the log URL. ❐

cs-port: Port used from the client to the appliance.

❐

cs-username: Relative username of a client authenticated to the proxy (for example: not fully distinguished).

❐

s-supplier-ip: IP address of the upstream host (not available for a cache hit).

❐

s-supplier-name: Hostname of the upstream host (not available for a cache hit).

❐

s-supplier port: Port number of the upstream host (not available for a cache hit).

❐

r-supplier-ip: IP address used to contact the upstream host (not available for a

cache hit). ❐

r-supplier-name: Hostname used to contact the upstream host (not available for a

cache hit). ❐

r-supplier port: Port used to contact the upstream host (not available for a cache

hit). ❐

sc-filter-result: Content filtering result: Denied, Proxied, or Observed.

❐

sc-filter-category: Content filtering category.

❐

s-ip: IP address of the appliance on which the client established its connection.

❐

s-sitename: Service used to process the transaction.

Reference: CPL Triggers, Properties, and Actions The following SG appliance CPL is supported in the Endpoint Mapper proxy service: ❐

allow/deny

68

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section A: The Endpoint Mapper Proxy Service

TCP Tunneling Triggers ❐

Client: client.address, client.host, client.host.has_name, client protocol (recognizes epmapper token).

❐

Date/Time: date[.utc], day, hour, minute, month, weekday, year, time

❐

Proxy: proxy.address, proxy.port, proxy.card

❐

has_client

❐

url

Properties and Actions ❐

allow/deny

❐

trace

❐

log_message

❐

notify_email, notify_snmp

❐

reflect_ip

❐

access_log

❐

forward

❐

socks_gateway

69

Volume 2: Proxies and Proxy Services Section B: The MAPI Proxy

Section B: The MAPI Proxy This section discusses the Messaging Application Programing Interface (MAPI) protocol and describes how to configure the services and proxy on the SG appliance.

About MAPI MAPI is the protocol used by Microsoft Outlook (client) to communicate with Microsoft Exchange (server), most commonly for e-mail applications. MAPI itself is based on the Microsoft Remote Procedure Call (RPC). Because MAPI is based on RPC, it suffers from the same performance inherent with RPC communications. Microsoft Outlook is the most common enterprise e-mail application. As enterprises continue to trend toward consolidating servers, which requires more WAN deployments (branch and remote locations), e-mail application users experience debilitating response times for not only sending and receiving mail, but accessing message folders or changing calendar elements. This is because MAPI RPC transmissions are broken into blocks of data (no more than 32 KB). The client must stop and wait for each block to arrive before requesting the next block. Each stop represents time lost instead of data sent.

About the Blue Coat MAPI Solution The MAPI proxy is similar to and actually works in conjunction with the Endpoint Mapper proxy in that it intercepts and accelerates RPCs; however, MAPI is always deployed transparently and does not listen on a specific port or port range. Instead, when configured to do so, the Endpoint Mapper proxy hands off Outlook/Exchange traffic to the MAPI proxy (but the Endpoint Mapper proxy functionality is still required to make an RPC connection). The MAPI proxy itself is a split proxy, which is only viable in a deployment that consists of a branch proxy and core proxy. A split proxy employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. In the case of the MAPI Proxy, cooperation exists between the branch SG appliance and the core SG appliance to reduce the number of RPCs sent across the WAN. The TCP connection between the branch and core proxies makes use of byte caching for acceleration (compression).

70

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section B: The MAPI Proxy

Figure 6-1. MAPI Proxy Deployment and Flow Diagram

Batching The MAPI proxy Batching feature reduces the number of RPC messages traversing the WAN. The branch and core appliances work together to batch multiple RPC messages in a larger chunk, rather than sending the smaller chunks. Also, the proxy predicts, or reads ahead, what will be requested next. When the branch proxy receives data chunks, it begins sending the acknowledgments to the MAPI client to satisfy that requirement of the communication process.

Keep-Alive The MAPI proxy Keep-Alive feature allows the SG appliance to maintain the connection to the Exchange server after the user has logged off from Outlook. Determined by the configurable interval, the MAPI proxy checks the Exchange server for new mail. ADN Optimization allows the connection to remain warm so that when the user logs on again to Outlook, the number of retrieved bytes is lower, allowing for better performance. The MAPI proxy remembers each user that is logged on or off. If the duration exceeds the specified limit, or when the user logs back into the mail application, the Keep-Alive connection is dropped. For more information about ADN optimization, refer to Volume 5: Advanced Networking.

71

Volume 2: Proxies and Proxy Services Section B: The MAPI Proxy

Supported Servers The MAPI proxy supports: ❐

MAPI 2000 (Outlook/Exchange 2000).

❐

MAPI 2003

Access Logging The MAPI proxy uses a default access log format. Data includes user actions, data lengths (bytes), and RPC data. date, time, c-ip, c-port, r-ip, r-port, x-mapi-user, x-mapi-method, cs-bytes, sr-bytes, rs-bytes, sc-bytes, x-mapi-sc-rpc-count, x-mapisr-rpc-count, x-mapi-rs-rpc-count, x-mapi-sc-rpc-count, s-action, csusername, cs-auth-group, s-ip

For MAPI-specific descriptions, see “Reference: Access Log Fields”.

More Conceptual Reference ❐

“About RPC” on page 64.

❐

Volume 5: Advanced Networking.

Configuring the SG MAPI Proxy This section contains the following sub-sections: ❐

“Configuring the SG Appliance Endpoint Mapper Service” on page 65.

❐

“Reviewing Endpoint Mapper Proxy Statistics” on page 67.

About the MAPI Service By default (upon upgrade and on new systems), the SG appliance has an Endpoint Mapper proxy service configured on port 135. The service is also configured to listen to all IP addresses, but is set in Bypass mode. As the MAPI proxy processes RPC communication as well, it uses the Endpoint Mapper proxy service. See "Section A: The Endpoint Mapper Proxy Service" on page 64.

Configuring the MAPI Proxy The MAPI Proxy options concern Batching, Handoff, and Keep-Alive features. This section describes these options and why they might require changing based on your branch deployment. To view/change the MAPI Proxy configuration options: 1.

In the Management Console, select Configuration > Proxy Settings > MAPI Proxy.

72

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section B: The MAPI Proxy

2b 2a 2c

2.

Configure the MAPI Proxy configuration options: a.

Enable Endpoint Mapper to MAPI Handoff: The Endpoint Mapper proxy sends

Microsoft Outlook and Exchange RPC communications to the MAPI proxy, which is used to manage the data. The routing connections from the branch to the core remains under the control of the Endpoint Mapper service. Note: A secondary TCP connection is created to handle all non-MAPI traffic. No changes to the Endpoint Mapper service or proxy are required.

b.

Batching: If enabled, MAPI traffic across the WAN is accelerated because data

is chunked and sent as one connection, rather than multiple smaller connections. c.

Keep-Alive: After a user logs out of Outlook, the MAPI RPC connection remains and the SG appliance continues to receive incoming messages to this account. If disabled (the default), no attempts to contact the server occur until the next time the user logs into his/her Outlook account. This might create a noticeable decrease in performance, as the queue of unreceived mail is processed.

•

Interval: If Keep-Alive is enabled, how often the MAPI proxy contacts the Exchange server to check for new messages.

•

Duration: If Keep-Alive is enabled, how long the MAPI proxy maintains the

connection to the Exchange server. The connection is dropped if the duration exceeds this value or once a user logs back in to the mail application. •

3.

Maximum Sessions: Limits the number of occurring active keep-alive sessions. If a new keep-alive session starts, and the specified limit is already exceeded, the oldest keep-alive session is dropped.

Click OK; click Apply

Reviewing MAPI Statistics After MAPI traffic begins to flow through the SG appliance, you can review the statistics page and monitor results in various MAPI categories. The presented statistics are representative of the client perspective. To review MAPI statistics: 1.

From the Management Console, select Statistics > MAPI History.

73

Volume 2: Proxies and Proxy Services Section B: The MAPI Proxy 2.

View statistics: a.

b.

3.

Select a statistic category tab: •

MAPI Clients Bytes Read: The total number of bytes read by MAPI clients.

•

MAPI Clients Bytes Written: The total number of bytes written by MAPI clients.

•

MAPI Clients: The total number of connected MAPI clients.

The graphs display three time metrics: the previous 60 minutes, the previous 24 hours, and the previous 60 days. Roll the mouse over any colored bar to view the exact metric.

(Optional) You can change the scale of the graph to display the percentage of bar peaks to display.

Reference: Equivalent MAPI Proxy CLI Commands The Management Console procedures in this chapter have the following equivalent CLI command roots: SGOS#(config) mapi ❐

The following subcommands are available: SGOS#(config mapi) handoff (enable | disable} SGOS#(config mapi) batching {enable | disable} SGOS#(config mapi) keep-alive {enable | disable} SGOS#(config mapi) keep-alive interval [minutes 1-60] SGOS#(config mapi) keep-alive duration [hours 1-72] SGOS#(config mapi) {view | exit}

Reference: Access Log Fields The default MAPI Access Log fields are: "date time c-ip c-port r-ip r-port x-mapi-user "\ "x-mapi-method cs-bytes sr-bytes rs-bytes sc-bytes "\ "x-mapi-cs-rpc-count x-mapi-sr-rpc-count "\ "x-mapi-rs-rpc-count x-mapi-sc-rpc-count "\ "s-action cs-username cs-auth-group s-ip" ❐

cs-bytes, sr-bytes, rs-bytes, sc-bytes: Standard ELFF format. The total RPC

byte counts in the specified direction (client-server). ❐

x-mapi-method: The end-user operation, one of:

•

STARTUP: The start of a MAPI session. A single user can have more than one active MAPI sessions for a single instance of Outlook.

•

SHUTDOWN: The end of a MAPI session.

•

SEND: Outlook is sending an e-mail (with or without attachments) to Exchange and the SG appliance is batching the contents.

•

FETCH: Outlook is fetching an e-mail (with or without attachments) to Exchange and the SG appliance is batching the contents.

•

KEEP_ALIVE_STARTUP: A keep-alive session started.

•

KEEP_ALIVE_SHUTDOWN: A keep-alive session ended.

74

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section B: The MAPI Proxy

❐

•

KEEP_ALIVE_NEGOTIATE: Messages were sent to query the state of the Inbox during a keep-alive session.

•

KEEP_ALIVE_FETCH: An e-mail (with or without attachments) was fetched during a keep-alive session.

x-mapi-user-dn: The full user domain name gathered from the MAPI negotiation of

user credentials between Outlook and Exchange. ❐

x-mapi-user: A shortened form of the user domain name.

❐

s-action:

•

ALLOWED: The traffic was permitted through.

•

SUCCESS: The traffic was successfully proxied, but was not subject to policy.

•

DENIED: The traffic was denied by policy.

•

SERVER_ERROR: The traffic was dropped because of an error communicating with

the server. •

FAILED: The traffic was dropped because of an error when handling the messages sent by the client. Or an internal problem with the MAPI proxy.

•

BATCHED: The traffic was batched.

•

TUNNELED: The traffic was tunneled to the Exchange server for one of two reasons:

•

The MAPI traffic is encrypted; therefore, the SG appliance cannot batch messages or attachments and thus cannot provide WAN optimization benefits.

•

The MAPI proxy could not connect upstream through an Application Delivery Network (ADN) tunnel.

❐

x-cs-mapi-rpc-count: The number of RPCs sent from the client to the proxy.

❐

x-sr-mapi-rpc-count: The number of RPCs sent from the proxy to the server.

❐

x-rs-mapi-rpc-count: The number of RPCs sent from the server to the proxy.

❐

x-sc-mapi-rpc-count: The number of RPCs sent from the proxy to the client.

75

Volume 2: Proxies and Proxy ServicesMA

76

Chapter 7: Managing the FTP Proxy

Blue Coat supports accessing FTP origin content servers over HTTP (Web FTP) as well as supporting native FTP proxy. Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the

origin content server (OCS) (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client. Native FTP involves the client connecting (either explicitly or transparently) using FTP; the SG appliance then connects upstream through FTP (if necessary).

Understanding FTP With Blue Coat’s implementation of FTP, you can control how the SG appliance responds to FTP client requests. You can also control which IP addresses are used. This section discusses: ❐

“Passive Mode Data Connections” on page 77

❐

“Understanding IP Reflection for FTP” on page 78

Passive Mode Data Connections Data connections initiated by an FTP server to an FTP client at the port and IP address requested by the FTP client are known as PORT or active connections. This connection method is used when the FTP server can connect directly to the FTP client. Data connections initiated by an FTP client to an FTP server at the port and IP address requested by the 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. Using passive mode data connections (which can set through the Management Console or the CLI) allows administrators to select how the SG appliance responds to a request from an FTP client for a passive mode data connection (PASV 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 PASV on the SG appliance servicing requests from this type of FTP client might provide a more acceptable response to the end user. When PASV is disabled, some FTP clients try a PORT command automatically, which allows requests to be received when the client doesn't allow PASV connections to a different IP address. Note: some clients might display an error when PASV is disabled on the SG appliance, requiring you to manually request PORT mode.

77

Volume 2: Proxies and Proxy Services

The FTP client software controls any messages displayed to the end user as a result of this response from the SG appliance.

Understanding IP Reflection for FTP IP reflection determines how the client IP address is presented to the origin server for all requests. The FTP service uses a Reflect Client IP attribute that enables or disables sending of client's IP address instead of sending the SG appliance's IP address by default when connecting to the OCS. IP reflection in policy and the corresponding attribute in services can be used for FTP control connections to the OCS; certain deployments are subject to limitations. The client and server-side policies are: ❐

ftp.match_client_data_ip(yes)—The SG appliance always reflects the IP address that the client originally attempts to connect to on the client-side control connection. The ftp.match_client_data_ip(yes) property allows you to also use that same client IP address when making an active data connection back to the client. This is independent of whether reflect_ip() or ftp.match_server_data_ip() is in use on the server side.

❐

reflect_ip( )—Controls whether to do IP reflection for server-side control

connections. This can also be enabled using the Reflect Client IP attribute. ❐

ftp.match_server_data_ip(yes)—Matches the source IP address of the PASV data connection with the source IP address of the SG appliance control connection (server side). Note that the reflect_ip( ) policy must be set for ftp.match_server_data_ip(yes) to be meaningful.

The following points describe the various data flow scenarios: ❐

Outbound client data connection (SG appliance to client)—When the client issues a PORT command, the appliance opens a data connection to the FTP client with the source IP address of whatever destination IP address the client used when opening the control connection.

❐

Inbound client data connection (client to SG appliance)—When the client issues a PASV command, the appliance returns the IP address and port to which client makes a data connection. •

Explicit—The SG appliance returns the destination IP address of the control connection; this can be a physical or virtual IP address.

•

Transparent—The SG appliance returns the IP address of the physical adapter on which the control connection arrived.

Note: For information on using transparent or explicit proxies, see Appendix B: "Explicit and Transparent Proxy" on page 191. ❐

Outbound server data connection (SG appliance to FTP server)—When the SG appliance issues a PASV command upstream, the server returns an IP address and port to connect to. The appliance 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.

78

Chapter 7: Managing the FTP Proxy

❐

Inbound server data connection (FTP server to SG appliance)—When the SG appliance issues a PORT command, the appliance provides the IP address and port number to which the server makes a data connection. •

The SG appliance sends the control connection’s source IP address if that IP is a local appliance (virtual or physical) IP address; or

•

The SG appliance sends the IP address of the physical adapter that was used to make the outgoing control connection.

FTP Server Notes ❐

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.

Notes ❐

Internet Explorer does not support proxy authentication for native FTP.

❐

The SG appliance FTP proxy does not support customized exception text; that is, you can use policy to deny requests, but you can't control the text sent in the error message.

Configuring the SG Appliance for Native FTP Proxy This section discusses: ❐

“Creating or Editing the FTP Service”

❐

“Configuring the FTP Proxy” on page 81

❐

“Configuring FTP Clients” on page 82

Creating or Editing the FTP Service An FTP service is created by default, but it is in bypass mode. The service is not functioning until it is in intercept mode. Note: Web FTP requires an HTTP service, not an FTP service. For information on configuring an HTTP proxy service, see “Chapter 8: Managing the HTTP Proxy” on page 85.

To create or edit an FTP proxy service: 1.

From the Management Console, select Configuration > Services > Proxy Services.

2.

To edit an existing FTP proxy service, highlight the service and click Edit. To create a new proxy service, click New. Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

79

Volume 2: Proxies and Proxy Services

3 4

5

6

8

7

9 10

3.

If you are creating a new FTP proxy service, enter a meaningful name in the Name field.

4.

Select FTP from the drop-down list under Proxy settings.

5.

Configure TCP/IP options:

6.

a.

The Early Intercept checkbox cannot be changed for the FTP proxy service.

b.

The Reflect Client IP checkbox enables or disables sending of client's IP address instead of the SG appliance's IP address when connecting to the origin content server. Note that this setting can be overruled by policy.

Configure ADN options:

80

Chapter 7: Managing the FTP Proxy

a.

The Enable ADN controls whether ADN is enabled for a specific service. Enabling ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment). Note: ADN supports passive FTP (the data connection is initiated by an FTP client to an FTP server at the port and IP address requested by the FTP server. Active FTP, where data connections are initiated by an FTP server to an FTP client at the port and IP address requested by the FTP client, is not supported.

b.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN optimization during initial configuration. De-select the checkbox if you are not configuring ADN optimization.

7.

To create a new listener, click New; if you edit an existing listener, click Edit.

8.

Select a Destination IP option.

9.

In the Port Range field, enter the ports on which the service should listen. The default port for FTP is 21.

10. Select the default behavior for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. 11. Click OK; click Apply. Related CLI Syntax to Create/Edit an FTP Proxy Service ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create ftp service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {all | ip_address | ip_address/subnetmask} {port | first-port_last-port} [intercept | bypass]} SGOS#(config service-name) attribute adn-optimize {enable | disable}| reflect-client-ip {enable | disable} | use-adn {enable | disable} SGOS#(config service-name) bypass {all | ip_address | ip_address/ subnet-mask} {port | first-port_last-port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {all | ip_address | ip_address/ subnet-mask {port | first-port_last-port} SGOS#(config service-name) remove {all | ip_address | ip_address/ subnet-mask {port | first-port_last-port} SGOS#(config service-name) view

Configuring the FTP Proxy To configure the FTP proxy: 1.

Select Configuration > Proxy Settings > FTP Proxy.

81

Volume 2: Proxies and Proxy Services

2.

Select Allow caching of FTP objects. The default is enabled.

3.

Determine the amount of time in percentage of how long since the object was last modified. The default is 10%.

4.

Enter an amount, in hours, that the object remains in the cache before becoming eligible for deletion. The default is 24 hours.

5.

Select Allow use of PASV mode to clients. The default is enabled, allowing data connections to be initiated by an FTP client to an FTP server at the port and IP address requested by the FTP server.

Related CLI Syntax to Configure the FTP Proxy SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config)

ftp ftp ftp ftp

login-syntax (raptor | checkpoint} passive-mode {enable | disable} no welcome-banner welcome banner

SGOS#(config) caching SGOS#(config caching) max-cache-size number8 SGOS#(config caching) ftp SGOS#(config caching ftp) enable SGOS#(config caching ftp) type-m-percent number SGOS#(config caching ftp) type-n-initial number Note: Neither proxy authentication for transparent FTP nor proxy chaining are supported with the Checkpoint syntax.

Configuring FTP Clients if you want to configure an FTP client to explicitly proxy to the SG appliance, complete the following steps. Note: The steps below are for a WSFtp client. Other clients vary. ❐

Enable firewall.

❐

Select USER with no logon unless you are doing proxy authentication. In that case, select USER remoteID@remoteHost fireID and specify a proxy username and password.

82

Chapter 7: Managing the FTP Proxy

Example The illustration demonstrates a WSFtp client configuration.

Configuring FTP Connection Welcome Banners You can customize banners that usually describe the policies and content of the FTP server displayed to FTP clients. Without modification, the SG appliance sends a default banner to newly-connected FTP clients: Welcome to Blue Coat FTP. However, you might not want users to know that a SG appliance exists on the network. A default banner can be defined in the Management Console or the CLI, but other banners defined for specific groups can be created in policy layers. Note: Configurable banners are only displayable when FTP is explicitly proxied through the SG appliance. In transparent deployments, the banner is sent to the client when proxy authentication is required; otherwise, the banner is forwarded from the FTP server.

To define the default FTP banner: 1.

Select Configuration > Services > FTP Proxy.

2.

In the Welcome Banner field, enter a line of text that is displayed on FTP clients upon connection. If the message length spans multiple lines, the SG appliance automatically formats the string for multiline capability.

Note that the welcome banner text is overridden by the policy property ftp.welcome_banner(). This is required for explicit proxy requests, when doing

proxy authentication, and also when the policy property ftp.server_connection(deferred|immediate) is set to defer the connection. 3.

Click Apply.

Related CLI Syntax to Define the Default FTP Banner #SGOS#(config) ftp welcome-banner "message"

83

Volume 2: Proxies and Proxy Services

Related CPL Syntax to Create Policy that Overrides the Default Banner ftp.welcome_banner("message")

If entering text that spans more than one line, use $(crlf) for line breaks.

Viewing FTP Statistics See Chapter 8: "Managing the HTTP Proxy" on page 85 for information about viewing the FTP statistics.

84

Chapter 8: Managing the 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 “Creating or Editing a Proxy Service” on page 28. The HTTP proxy is the first line of defense for the SG appliance, controlling all traffic that arrives on port 80. To control that traffic and improve performance, you can: ❐

Set default caching policies to configure the length of time an object or negative response is cached, whether objects are always revalidated before being served, whether server certificates are verified by default, and how headers are parsed. For more information, see “Understanding Tolerant HTTP Request Parsing” on page 104.

❐

Configure the HTTP proxy as a server accelerator. For more information, see “Customizing the HTTP Proxy Profile” on page 96.

❐

Set a limit to the maximum bandwidth the SG appliance is allowed to use for refreshing objects in the background. For more information, see “Setting Default HTTP Proxy Policy” on page 94.

The HTTP proxy is designed to control Web traffic, providing: ❐

Security

❐

Authentication

❐

Virus Scanning and Patience Pages

❐

Performance •

Default HTTP Proxy Policy

•

HTTP Proxy Caching Profiles

•

Byte-Range Support

85

Volume 2: Proxies and Proxy Services

This chapter discusses: ❐

“Creating an HTTP Proxy Service” on page 87

❐

“Overview: Configuring HTTP Proxy Performance” on page 91

❐

“Configuring the HTTP Proxy” on page 94

❐

“Viewing HTTP/FTP Statistics” on page 106

❐

“Using Explicit HTTP Proxy with Internet Explorer” on page 110

86

Chapter 8: Managing the HTTP Proxy

Section A: Creating an HTTP Proxy Service

Section A: Creating an HTTP Proxy Service Two HTTP services exist by default and are enabled, one with explicit and transparent attributes on port 80 and one with explicit attributes on port 8080. You can change the attributes or create other HTTP ports if needed. For example, if you configure SSL proxy functionality, you must create a separate HTTP service to allow the browser to issue HTTP CONNECT requests to the SG appliance for HTTPS content. The SG appliance detects the presence of the SSL protocol and enables SSL Proxy functionality for such connections. For more information on SSL proxy functionality, see “Managing the SSL Proxy” on page 145. To create or edit an HTTP proxy service: 1.

From the Management Console, select Configuration > Services > Proxy Services.

2.

To edit an existing HTTP proxy service, highlight the service and click Edit. To create a new proxy service, click New. Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

87

Volume 2: Proxies and Proxy Services Section A: Creating an HTTP Proxy Service

3 4

5

6

7b

7a

7c 7d

1.

If you are creating a new HTTP proxy service, enter a meaningful name in the Name field.

2.

Configure the Proxy Settings options:

88

Chapter 8: Managing the HTTP Proxy

Section A: Creating an HTTP Proxy Service a.

Verify HTTP is selected in the drop-down box under Proxy settings.

b.

Select the Authenticate 401 checkbox if you want all transparent and explicit requests received on the port to 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.

c.

3.

Select the Detect Protocol checkbox to automatically detect the protocol being used. Note that this breaks connections that do not have the client send information first, but expect the server to respond on connection. It also can add significant delay if the client does not send specific information, and only after timing out does it treat the traffic as unknown.

Configure TCP/IP options: a.

Reflect Client IP: Enables or disables sending of client's IP address instead of

b.

Early intercept: This option cannot be changed when creating or editing an

the SG appliance's IP address. HTTP proxy service. 4.

Configure ADN options: a.

Enable ADN: Controls whether ADN is enabled for a specific service. Enabling

ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment). b.

5.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN optimization during initial configuration. You should de-select the checkbox if you are not configuring ADN optimization.

To add a new listener: a.

Click New; (or click Edit.

b.

Select a Destination IP address option.

c.

In the Port Range field, enter the ports on which the service should listen. The default ports for HTTP are 80 and 8080.

d. Select the default behavior for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e. 6.

Click OK.

Click Apply.

Relevant CLI Syntax to Create/Edit an HTTP Proxy Service: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create http service-name SGOS#(config proxy-services) edit service-name

89

Volume 2: Proxies and Proxy Services Section A: Creating an HTTP Proxy Service ❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {authenticate-401 {enable | disable} | adn-optimize {enable | disable} | detect-protocol {enable | disable} | reflect-client-ip {enable | disable} | use-adn {enable | disable} SGOS#(config service-name) bypass {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

90

Chapter 8: Managing the HTTP Proxy

Section B: Overview: Configuring HTTP Proxy Performance

Section B: Overview: Configuring HTTP Proxy Performance You can configure HTTP proxy performance through setting: ❐

Default HTTP Proxy Policy

❐

HTTP Proxy Acceleration Profiles

❐

Byte Range

❐

Refresh Bandwidth

Each of these topics is discussed below.

Understanding Default HTTP Proxy Policy You can configure global defaults that determine HTTP proxy caching policy, such as the maximum size of cacheable objects, the length of time that negative responses remain in the cache, whether SGOS revalidates each object before serving it, whether the server certificate is verified by default, and how headers are parsed. For information about setting default policy for HTTP proxy caching, see “Understanding Tolerant HTTP Request Parsing” on page 104.

HTTP Proxy Acceleration Profiles You have a choice of three profiles to use for the SG appliance: ❐

Normal (the default setting) acts as a client accelerator, and is used for enterprise deployments

❐

Portal acts as a server accelerator, and is used for Web hosting

❐

Bandwidth Gain is used for ISP deployments

For information on HTTP profiles, see “Customizing the HTTP Proxy Profile” on page 96.

Byte-Range Support If a client makes a request using the Range: HTTP header, SGOS serves the requested portions of the file from the cache if byte-range support is enabled (the default). If byte range support is disabled, all such requests are forwarded to the origin content server and the response is not cached. For information on using byte-range support to determine how SGOS handles byte-range requests, see “Configuring HTTP for Bandwidth Gain” on page 101.

91

Volume 2: Proxies and Proxy Services Section B: Overview: Configuring HTTP Proxy Performance

Refresh Bandwidth Refresh bandwidth refers to server-side bandwidth used for all forms of asynchronous refresh activity. The default configuration is to allow the SG appliance to manage refresh bandwidth. The SG appliance manages the bandwidth in order to preserve the maximum freshness of accessed objects. However, sometimes the automatic refresh bandwidth amount is too high. It is not unusual for refresh bandwidth to spike up occasionally, depending on access patterns at the time. If necessary, you can impose a limit on refresh bandwidth. To limit the refresh bandwidth to a specified amount, you must disable automatic management of the bandwidth and explicitly set a bandwidth limit. Setting the refresh bandwidth amount too low can lower the estimated freshness of objects in the cache. If you set the refresh bandwidth amount to zero, the SG appliance does not do active refresh at all. For information about configuring refresh bandwidth, see “Configuring Refresh Bandwidth for the HTTP Proxy” on page 103. Related CLI Syntax to Configure HTTP: SGOS#(config) http ❐

The following subcommands are available: SGOS#(config) http [no] add-header client-ip SGOS#(config) http [no] add-header front-end-https SGOS#(config) http [no] add-header via SGOS#(config) http [no] add-header x-forwarded-for SGOS#(config) http [no] byte-ranges SGOS#(config) http [no] cache authenticated-data SGOS#(config) http [no] cache expired SGOS#(config) http [no] cache personal-pages SGOS#(config) http [no] force-ntlm SGOS#(config) http ftp-proxy-url root-dir SGOS#(config) http ftp-proxy-url user-dir SGOS#(config) http [no] parse meta-tag {cache-control | expires | pragma-no-cache} SGOS#(config) http [no] persistent client SGOS#(config) http [no] persistent server SGOS#(config) http [no] persistent-timeout client num_seconds SGOS#(config) http [no] persistent-timeout server num_seconds SGOS#(config) http [no] pipeline client {requests | redirects} SGOS#(config) http [no] pipeline prefetch {requests | redirects} SGOS#(config) http [no] proprietary-headers bluecoat SGOS#(config) http receive-timeout client num_seconds SGOS#(config) http receive-timeout refresh num_seconds SGOS#(config) http receive-timeout server num_seconds SGOS#(config) http [no] revalidate-pragma-no-cache SGOS#(config) http [no] strict-expiration refresh SGOS#(config) http [no] strict-expiration serve SGOS#(config) http [no] strip-from-header SGOS#(config) http [no] substitute conditional SGOS#(config) http [no] substitute ie-reload

92

Chapter 8: Managing the HTTP Proxy

Section B: Overview: Configuring HTTP Proxy Performance SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config) SGOS#(config)

http http http http http http http http

[no] substitute if-modified-since [no] substitute pragma-no-cache [no] tolerant-request-parsing upload-with-pasv disable upload-with-pasv enable version {1.0 | 1.1} [no] www-redirect [no] xp-rewrite-redirect

93

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy

Section C: Configuring the HTTP Proxy Configuring the HTTP proxy, after the HTTP proxy services are set up, allows you to improve performance. Discussed in this section are: ❐

“Setting Default HTTP Proxy Policy” on page 94

❐

“Customizing the HTTP Proxy Profile” on page 96

❐

“Understanding HTTP Proxy Profile Configuration Components” on page 97

❐

“Configuring HTTP for Bandwidth Gain” on page 101

❐

“Configuring Refresh Bandwidth for the HTTP Proxy” on page 103

❐

“Understanding Tolerant HTTP Request Parsing” on page 104

❐

“Understanding HTTP Object Types” on page 105

❐

“Viewing HTTP/FTP Statistics” on page 106

Setting Default HTTP Proxy Policy You can configure global defaults that determine HTTP proxy policy, such as the maximum size of cacheable objects, the length of time that negative responses remain in the cache, whether SGOS revalidates each object before serving it, whether the server certificate is verified by default, and how headers are parsed. Other policy can be controlled only by using Blue Coat Content Policy Language (CPL). To set HTTP default proxy policy: 1.

From the Management Console, select Configuration > Proxy Settings > HTTP Proxy > Policies.

2.

In the Do not cache objects larger than field, enter the maximum object size to cache. The default is 1024 MB. This configuration determines the maximum object size to store in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

94

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy 3.

In the Cache negative responses for field, enter the number of minutes SGOS stores negative responses. The default is 0, meaning that the SG appliance does not cache negative responses and always attempts to retrieve the object. The OCS might send a client error code (4xx HTTP response) or a server error code (5xx HTTP response) as a response to some requests. If the SG appliance 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 SG appliance attempts to retrieve the page or image every time it is requested. If you enter a number of minutes into this field, then the response times improve, but you could receive negative responses to requests that might otherwise have been served for that period of time.

4.

To always verify that each object is fresh upon access, select the Always check with source before serving object checkbox. Enabling this setting has a significant impact on performance because HTTP proxy revalidates requested cached objects with the OCS before serving them to the client, resulting in a negative impact on response times and bandwidth gain. Therefore, do not enable this configuration unless absolutely required.

5.

If you communicate with an origin content server (OCS) through HTTPS and want the OCS certificate to be verified, be sure that Verify server certificate for secure connections is selected.

6.

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

7.

•

Parse “expires” meta tag

•

Parse “pragma-no-cache” meta tag

Click OK; click Apply.

Tips on Parsing Meta Tags ❐

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

❐

Relevant HTTP meta tags must appear within the first 256 bytes of HTTP object body. If the meta tag does not appear within the first 256 bytes, it is ignored.

Tips on Using Meta Tags With Policy ❐

The following CPL properties can be used in the layer to control meta tag processing for HTTP proxy, HTTP refresh, and HTTP pipeline transactions: http.response.parse_meta_tag.Pragma.no-cache(yes|no) http.response.parse_meta_tag.Cache-Control(yes|no) http.response.parse_meta_tag.Expires(yes|no)

❐

VPM support for this feature is not available.

95

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy Related CLI Syntax to Set HTTP Proxy Default Policy ❐

To enter configuration mode: SGOS#(config) caching SGOS#(config caching)

❐

The following subcommands are available: SGOS#(config caching) always-verify-source SGOS#(config caching) max-cache-size megabytes SGOS#(config caching) refresh automatic SGOS#(config caching) refresh bandwidth kbps SGOS#(config) http parse meta-tag {cache-control | expires | pragmano-cache}

Customizing the HTTP Proxy Profile You can select from among three profiles for the HTTP proxy, depending on your needs, and you can also create a customized profile from the three available. The three profiles are: ❐

Normal, which acts as a client-accelerator and is used for enterprise deployments

❐

Portal, which acts as a server accelerator and is used for Web-hosting

❐

Bandwidth, which is used for ISP deployments

The table below shows the configuration for each profile. Table 8-1. Normal, Portal, and Bandwidth Gain Profiles Configuration

Normal Profile

Portal Profile

Bandwidth Gain

Pipeline embedded objects in client requests

Enabled

Disabled

Disabled

Pipeline embedded objects in prefetch requests

Enabled

Disabled

Disabled

Pipeline redirects for client requests

Enabled

Disabled

Disabled

Pipeline redirects for prefetch requests

Enabled

Disabled

Disabled

Cache expired objects

Enabled

Disabled

Enabled

Bandwidth Gain Mode

Disabled

Disabled

Enabled

Substitute GET for IMS (if modified since)

Disabled

Enabled

Enabled

Substitute GET for PNC (Pragma no cache)

Disabled

Enabled

Does not change

Substitute GET for HTTP 1.1 conditionals

Disabled

Enabled

Enabled

Substitute GET for IE (Internet Explorer) reload

Disabled

Enabled

Does not change

Never refresh before expiration

Disabled

Enabled

Enabled

Never serve after expiration

Disabled

Enabled

Does not change

96

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy When an SG appliance is first manufactured, it is set to a Normal profile. Depending on your needs, you can use the Bandwidth Gain profile or the Portal profile. You can also combine needed elements of all three profiles.

Using the Normal Profile Normal is the default profile and can be used wherever the SG appliance is used as a normal forward proxy. This profile is typically used in enterprise environments, where the freshness of objects is more important than controlling the use of server-side bandwidth. The Normal profile is the profile that most follows the HTTP standards concerning object revalidation and staleness. Additionally, prefetching (pipelining) of embedded objects and redirects is enabled, which reduces response time for clients.

Using the Portal Profile When configured as a server accelerator, the SG appliance improves object response time to client requests, scalability of the origin content server (OCS) site, and overall Web performance at the OCS. A server accelerator services requests meant for an OCS as if it is the OCS itself. Because an OCS can actually consist of many servers—a single Web server or an entire server farm—OCSs are identified by domain name or IP address. To the SG appliance, the domain name or IP address is treated as the OCS, regardless of how many back-end Web servers might be installed.

Using the Bandwidth Gain Profile The Bandwidth-Gain profile is useful wherever server-side bandwidth is an important resource. This profile is typically used in Internet Service Provider (ISP) deployments. In such deployments, the freshness of the object is not as important as controlling the use of server-side bandwidth. The Bandwidth-Gain profile enables various HTTP configurations that can increase page response times and the likelihood that stale objects are served, but that reduces the amount of server-side bandwidth required.

Understanding HTTP Proxy Profile Configuration Components The table below gives a definition of the customizable HTTP proxy profile settings. Both the Management Console field and CLI (config) command text is included. Table 8-2. Description of Profile Configuration Components Management Console Checkbox Field

CLI (config) Command

Definition

Pipeline embedded objects in client request

http [no] pipeline client requests

This configuration item applies only to HTML responses. When this setting is enabled, and the object associated with an embedded object reference in the HTML is not already cached, HTTP proxy acquires the object’s content before the client requests the object. This improves response time dramatically. If this setting is disabled, HTTP proxy does not acquire embedded objects until the client requests them.

97

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy Table 8-2. Description of Profile Configuration Components (Continued) Management Console Checkbox Field

CLI (config) Command

Definition

Pipeline redirects for client request

http [no] pipeline client redirects

When this setting is enabled, and the response of a client request is one of the redirection responses (such as 301, 302, or 307 HTTP response code), then HTTP proxy pipelines the object specified by the Location header of that response, provided that the redirection location is an HTML object. This feature improves response time for redirected URLs. If this setting is disabled, HTTP proxy does not pipeline redirect responses resulting from client requests.

Pipeline embedded objects in prefetch request

http [no] pipeline prefetch requests

This configuration item applies only to HTML responses resulting from pipelined objects. When this setting is enabled, and a pipelined object’s content is also an HTML object, and that HTML object has embedded objects, then HTTP proxy also pipelines those embedded objects. This nested pipelining behavior can occur three levels deep at most. If this setting is disabled, HTTP proxy does not engage in nested pipelining behavior.

Pipeline redirects for prefetch request

http [no] pipeline prefetch redirects

When this setting is enabled, HTTP proxy pipelines the object specified by a redirect location returned by a pipelined response. If this setting is disabled, HTTP proxy does not try to pipeline redirect locations resulting from a pipelined response.

Substitute Get for IMS

http [no] substitute ifmodified-since

If the time specified by the If-Modified-Since: header in the client’s conditional request is greater than the last modified time of the object in the cache, it is a strong indication that the copy in the cache is stale. If so, HTTP proxy does a conditional GET to the OCS, based on the last modified time of the cached object. To control this aspect of the SGOS treatment of the If-Modified-Since: header, disable the Substitute Get for IMS setting. When this setting is disabled, a client time condition greater than the last modified time of the object in the cache does not trigger revalidation of the object. However, not all objects necessarily have a lastmodified time specified by the OCS.

98

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy Table 8-2. Description of Profile Configuration Components (Continued) Management Console Checkbox Field

CLI (config) Command

Definition

Substitute Get for HTTP 1.1 conditionals

http [no] substitute conditional

HTTP 1.1 provides additional controls to the client over the behavior of caches concerning the staleness of the object. Depending on various CacheControl: headers, the SG appliance can be forced to consult the OCS before serving the object from the cache. For more information about the behavior of various Cache-Control: header values, refer to RFC 2616. If the Substitute Get for HTTP 1.1 Conditionals setting is enabled, HTTP proxy ignores the following CacheControl: conditions from the client request: • "max-stale" [ "=" delta-seconds ] • "max-age" "=" delta-seconds • "min-fresh" "=" delta-seconds • "must-revalidate" • "proxy-revalidate"

Substitute Get for PNC

http [no] substitute pragmano-cache

Typically, if a client sends an HTTP GET request with a Pragma: no-cache or Cache-Control: nocache header (for convenience, both are hereby referred to as PNC), a cache must consult the OCS before serving the content. This means that HTTP proxy always re-fetches the entire object from the OCS, even if the cached copy of the object is fresh. Because of this, PNC requests can degrade proxy performance and increase server-side bandwidth utilization. However, if the Substitute Get for PNC setting is enabled, then the PNC header from the client request is ignored (HTTP proxy treats the request as if the PNC header is not present at all).

Substitute Get for IE reload

http [no] substitute iereload

Some versions of Internet Explorer issue the Accept: */* header instead of the Pragma: nocache header when you click Refresh. When an Accept header has only the */* value, HTTP proxy treats it as a PNC header if it is a type-N object. You can control this behavior of HTTP proxy with the Substitute GET for IE Reload setting. When this setting is enabled, the HTTP proxy ignores the PNC interpretation of the Accept: */* header.

Never refresh before expiration

http [no] strictexpiration refresh

Applies only to cached type-T objects. When this setting is enabled, SGOS does not asynchronously revalidate such objects before their specified expiration time. When this setting is disabled, such objects, if they have sufficient relative popularity, can be asynchronously revalidated and can, after a sufficient number of observations of changes, have their estimates of expiration time adjusted accordingly.

99

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy Table 8-2. Description of Profile Configuration Components (Continued) Management Console Checkbox Field

CLI (config) Command

Definition

Never serve after expiration

http [no] strictexpiration serve

Applies only to cached type-T objects. If this setting is enabled, an object is synchronously revalidated before being served to a client, if the client accesses the object after its expiration time. If this setting is disabled, the object is served to the client and, depending on its relative popularity, may be asynchronously revalidated before it is accessed again.

Cache expired objects

http [no] cache expired

Applies only to type-T objects. When this setting is enabled, type-T objects that are already expired at the time of acquisition is cached (if all other conditions make the object cacheable). When this setting is disabled, already expired type-T objects become noncacheable at the time of acquisition.

Enable Bandwidth Gain Mode

bandwidth-gain {disable | enable}

This setting controls both HTTP-object acquisition after client-side abandonment and AAR (asynchronous adaptive refresh) revalidation frequency. • HTTP-Object Acquisition When Bandwidth Gain mode is enabled, if a client requesting a given object abandons its request, then HTTP proxy immediately abandons the acquisition of the object from the OCS, if such an acquisition is still in progress. When bandwidth gain mode is disabled, the HTTP proxy continues to acquire the object from the OCS for possible future requests for that object. • AAR Revalidation Frequency Under enabled bandwidth gain mode, objects that are asynchronously refreshable are revalidated at most twice during their estimated time of freshness. With bandwidth gain mode disabled, they are revalidated at most three times. Not all asynchronously refreshable objects are guaranteed to be revalidated.

Configuring the HTTP Proxy Profile You can configure the profile using any of the components discussed above. To configure the HTTP proxy profile: 1.

From the Management Console, select Configuration > Proxy Settings > HTTP Proxy > Acceleration Profile.

The Acceleration Profile tab displays (Normal is the default profile). Text appears at the bottom of this tab indicating which profile is selected. If you have a customized profile, this text does not appear.

100

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy

3

2

Important: If you have a customized profile and you click one of the Use Profile buttons, no record of your customized settings remains. However, once the SG appliance is set to a specific profile, the profile is maintained in the event the SG appliance is upgraded.

2.

To select a profile, click one of the three profile buttons (Use Normal Profile, Use Bandwidth Gain Profile, or Use Portal Profile).

The text at the bottom of the Acceleration Profile tab changes to reflect the new profile. Note: You can customize the settings, no matter which profile button you select.

3.

(Optional) To customize the profile settings, select or deselect any of the checkboxes (see Table 8-2 for information about each setting).

4.

Click OK; click Apply.

Related CLI Syntax to Configure the HTTP Proxy Profile SGOS#(config) profile {normal | portal | bwgain} SGOS#(config) bandwidth-gain {disable | enable}

Configuring HTTP for Bandwidth Gain In addition to the configuration items related to top-level profiles, other configurable items affect bandwidth gain. You can set the top-level profile and adjust various related configuration items to fine tune the SG appliance for the environment (see “Configuring the HTTP Proxy Profile” on page 100), and you can provide additional fine-tuning with the following configuration items: ❐

Byte-range support

❐

Revalidate pragma-no-cache

Byte-range requests can be made with a PNC header. To serve these requests from the cache, enable the revalidate PNC setting (see "“Understanding Revalidate Pragma-NoCache” on page 103).

101

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy

Understanding Byte-Range Support If a client requests a byte range using the Range: HTTP header, the SG appliance serves the requested portions of the file from the cache if byte-range support is enabled (the default). If byte range support is disabled, all such requests are forwarded in a noncacheable way to the origin content server (OCS). Byte-range configuration can significantly affect bandwidth gain where heavy use of range requests is expected. Download managers (such as NetAnts®) typically use byterange requests heavily. With byte-range support enabled, if the object is already cached and does not need to be reloaded from the OCS, the SG appliance serves the byte-range request from the cache only. But if the object is not in the cache, or if a reload of the object is required, SGOS might treat the byte-range request as if byte-range support is disabled and serve the object from the cache. It is important to note that HTTP proxy never caches partial objects, even if byte-range support is enabled. If byte-range support is disabled, HTTP treats all byte-range requests as non-cacheable. Such requests are never served from the cache, even if the object exists in the cache. The client’s request is sent unaltered to the OCS and the response is not cached. Thus a byterange request has no effect on the cache if byte-range support is disabled. HTTP proxy categorizes the range requests in following three categories when byte-range support is enabled: ❐

Type-1: 0-N: Range request for first N bytes of the object

❐

Type-2: N-M: Range request from N bytes to M bytes of the object

❐

Type-3: -N: Range request for last N bytes of the object

If the object does not exist in the cache, and a byte-range request is received with the first range being type-1 or type-2, and the start byte of the first requested range is within 14336 bytes (hard coded threshold), then the entire object is retrieved from the OCS and cached in the SG appliance. Even though HTTP proxy retrieves the entire object from the OCS, it sends an appropriate byte-range response to the client. If the object does not exist in the cache, and if the first range in the request is not of type-1 or type-2, or if the start byte of the first requested range is beyond 14336 bytes, then the client’s request is sent unaltered to the OCS and the response is not cached. If the object exists in the cache, and if a range request with an effective PNC (the PNC header is not substituted or revalidated—see "Understanding Revalidate Pragma-NoCache" below) is made, and the first range in the request is either type-3 or type-1 or 2 with a start byte offset greater than 14336 bytes, then, even if the object exists in the cache, the transaction is made non-cacheable (the request is sent to the OCS without any modification and the response is not cached). If an object exists in the cache and a byterange request is made without the PNC header, then the byte-range response is satisfied from the cache. Most download managers make byte-range requests with a PNC header. To serve such requests from the cache, the revalidate pragma-no-cache option should be configured along with byte-range support (see “Understanding Revalidate Pragma-No-Cache” below). To configure byte-range support: Note: Enabling or disabling byte-range support can only be configured through the CLI.

102

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy To enable or disable byte-range support, enter one of the following commands at the (config) command prompt: SGOS#(config) http byte-ranges -orSGOS#(config) http no byte-ranges

Understanding Revalidate Pragma-No-Cache The pragma-no-cache (PNC) header in a client’s request can affect the efficiency of the proxy from a bandwidth gain perspective (this behavior is described in Table 8-2 in the Substitute Get for PNC configuration description). If you do not want to completely ignore PNC in client requests (which you can do by using the Substitute Get for PNC configuration), you can lower the impact of the PNC by enabling the revalidatepragma-no-cache setting. When the revalidate-pragma-no-cache setting is enabled, a client’s non-conditional PNC-GET request results in a conditional GET request sent to the OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not Modified response, thus consuming less server-side bandwidth, because it has not been forced to return full content even though the contents have not actually changed. By default, the revalidate PNC configuration is disabled and is not affected by changes in the top-level profile. When the Substitute Get for PNC configuration is enabled (see “Configuring the HTTP Proxy Profile” on page 100 for configuration information), the revalidate PNC configuration has no effect. To configure the revalidate PNC setting: Note: The revalidate pragma-no-cache setting can only be configured through the CLI.

To enable or disable the revalidate PNC setting, enter one of the following commands at the (config) command prompt: SGOS#(config) http revalidate-pragma-no-cache -orSGOS#(config) http no revalidate-pragma-no-cache

Configuring Refresh Bandwidth for the HTTP Proxy The SG appliance 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 SG appliance is using too much bandwidth (by reviewing the logged statistics and examining current bandwidth used shown in the Refresh bandwidth field), you can specify a limit to the amount of bandwidth the SG appliance uses to try to achieve the desired freshness. Be aware, however, that if you limit the amount of bandwidth the SG appliance can use, you might prohibit the appliance from achieving the desired freshness. If the refresh bandwidth configuration remains at the recommended default—Let the SG Appliance manage refresh bandwidth (recommended) in the Management Console or SGOS#(config caching) refresh automatic in the CLI—then the appliance uses whatever bandwidth is available in its efforts to maintain 99.9% estimated freshness of the next access.

103

Volume 2: Proxies and Proxy Services Section C: Configuring the HTTP Proxy To set refresh bandwidth: 1.

From the Management Console, select Configuration > Proxy Settings > HTTP Proxy > Freshness.

The Refresh bandwidth field displays the refresh bandwidth options. The default setting is to allow the SG appliance to manage refresh bandwidth automatically. Important:

Blue Coat strongly recommends that you not change the setting from the

default. 2.

3.

Do one of the following: •

To turn off automatic bandwidth refresh, select Limit refresh bandwidth to (not recommended). Enter a new value into the kilobits/sec field, if necessary.

•

To return the appliance to automatic bandwidth refresh, select Let the SG Appliance manage refresh bandwidth (recommended).

Click OK; click Apply.

Relevant CLI Syntax to Set Refresh Bandwidth SGOS#(config) caching ❐

The following subcommands are available: SGOS#(config caching) refresh automatic SGOS#(config caching) refresh bandwidth kbps

Understanding Tolerant HTTP Request Parsing Defaults: ❐

Proxy Edition: The SG appliance blocks malformed HTTP requests, returning a 400 Invalid Request error.

❐

MACH5 Edition: Malformed HTTP requests are not blocked.

Proxy Edition Behavior The SG appliance blocks malformed HTTP requests, returning a 400 Invalid Request error. The tolerant HTTP request parsing flag causes certain types of malformed requests to be processed instead of being rejected.

104

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy By default, a header line not beginning with a or space character must consist of a header name (which contains no or space characters), followed by a colon, followed by an optional value, or an error is reported. With tolerant request parsing enabled, a request header name is allowed to contain or space characters, and if the request header line does not contain a colon, then the entire line is taken as the header name. A header containing one or more or space characters, and nothing else, is considered ambiguous. Blue Coat does not know if this is a blank continuation line or if it is the blank line that signals the end of the header section. By default, an ambiguous blank line is illegal, and an error is reported. With tolerant request parsing enabled, an ambiguous blank line is treated as the blank line that ends the header section. To enable the HTTP tolerant request parsing flag: Note: This feature is only available through the CLI.

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: SGOS#(config) http no tolerant-request-parsing

Understanding HTTP Object Types HTTP proxy categorizes HTTP objects into three types: ❐

Type-T: The OCS specifies explicit expiration time.

❐

Type-M: Expiration time is not specified; however, the last modified time is specified by the OCS.

❐

Type-N: Neither expiration nor last modified time has been specified.

The SGOS asynchronous adaptive refresh (AAR) algorithm is normally applied to all three types of HTTP objects. To maximize the freshness of the next access to objects in the cache, asynchronous revalidations are performed on those objects in accordance with their relative popularity and the amount of time remaining before their estimated time of expiration. Estimated expiration times vary as object content changes are observed during such asynchronous revalidations. This happens even for type-T objects because the expiration times of type-T objects are not always perfectly managed by Webmasters of content servers. However, for situations where such management can be trusted, certain configuration items exist to reduce speculative revalidation of type-T objects. In the following section, the terms revalidation and refresh mean the same thing—to assess the freshness of an object by sending a conditional GET request to the object’s OCS.

105

Volume 2: Proxies and Proxy Services Section D: Viewing HTTP/FTP Statistics

Section D: Viewing HTTP/FTP Statistics HTTP/FTP History Statistics The HTTP/FTP History tabs (HTTP/HTTPS/FTP Objects, HTTP/HTTPS/FTP Bytes, HTTP/HTTPS /FTP Clients, Client Comp. Gain, and Server Comp. Gain) display bar graphs that illustrate the last 60 minutes, 24 hours, and 30 days for t.he number of HTTP/ HTTPS/FTP objects served, the number of HTTP/HTTPS/FTP bytes served, the maximum number of active HTTP/HTTPS/FTP clients processed, and the HTTP/FTP client and server compression-gain statistics. Overall client and server compression-gain statistics are displayed under System Usage. Note: You can view current HTTP statistics through the CLI using the show httpstats command.

Viewing the Number of HTTP/FTP Objects Served The HTTP/HTTPS/FTP Objects tab illustrates the device activity over the last 60 minutes, 24 hours, and 30 days. These charts illustrate the total number of objects served from either the cache or from the Web. To review the number of cached objects versus noncached objects, view the Efficiency tabs Note: The maximum number of objects that can be stored in a SG appliance is affected by

a number of factors, including the SGOS version it is running and the hardware platform series To view the number of HTTP/HTTPS/FTP objects served: 1.

From the Management Console, select Statistics > Protocol Details > HTTP/FTP History > HTTP/HTTPS/FTP Objects.

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

106

Chapter 8: Managing the HTTP Proxy

Section D: Viewing HTTP/FTP Statistics

Viewing the Number of HTTP/HTTPS/FTP Bytes Served The Bytes tab shows the sum total of the number of bytes served from the device over the last 60 minutes, 24 hours, and 30 days. The chart shows the total number of bytes for objects served by the device, including both cache hits and cache misses. To view the number of HTTP/HTTPS/FTP bytes served: 1.

From the Management Console, select Statistics > Protocol Details > HTTP/FTP History > HTTP/HTTPS/FTP Bytes.

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Viewing Active Client Connections The HTTP/HTTPS/FTP Clients tab shows the maximum number of clients with requests processed over the last 60 minutes, 24 hours, and 30 days. This does not include idle client connections (connections that are open but that have not made a request). These charts allow you to monitor the maximum number of active clients accessing the SG appliance at any one time. In conjunction with the HTTP/HTTPS/FTP Objects and HTTP/HTTPS/ FTP Bytes tabs, you can determine the number of clients supported based on load, or load requirements for your site based on a specific number of clients. To view the number of active clients: 1.

From the Management Console select Statistics > Protocol Details > HTTP/FTP History > HTTP/HTTPS/FTP Clients.

107

Volume 2: Proxies and Proxy Services Section D: Viewing HTTP/FTP Statistics

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Viewing HTTP/FTP Client and Server Compression Gain Statistics Under HTTP/FTP History, you can view HTTP/FTP client and server compression-gain statistics for the SG appliance over the last 60 minutes, 24 hours, and 30 days in the Client Comp. Gain and the Server Comp. Gain tabs. Overall client and server compression-gain statistics are displayed under System Usage. These statistics are not available through the CLI. The green display on the bar graph represents uncompressed data; the blue display represents compressed data. Hover your cursor over the graph to see the compressed gain data. To view HTTP/FTP client compressed gain statistics: 1.

From the Management Console, select Statistics > Protocol Details > HTTP/FTP History > Client Comp. Gain.

108

Chapter 8: Managing the HTTP Proxy

Section D: Viewing HTTP/FTP Statistics

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

To view HTTP/FTP server compressed gain statistics: 1.

From the Management Console, select Statistics > Protocol Details > HTTP/FTP History > Server Comp. Gain.

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

109

Volume 2: Proxies and Proxy Services Section E: Using Explicit HTTP Proxy with Internet Explorer

Section E: Using Explicit HTTP Proxy with Internet Explorer Internet Explorer does not allow OCS NTLM authentication through a SG appliance when explicitly proxied. To correct this, Blue Coat added a Proxy-Support: Session-basedauthentication header that is sent by default when the SG appliance receives a 401 authentication challenge from upstream when the client connection is an explicit proxy connection. For older browsers or if both the SG appliance 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 SG appliance also converts the resulting Proxy-Authentication headers in client requests to standard server authorization headers, which allows an OCS NTLM authentication challenge to pass through when Internet Explorer is explicitly proxied through the appliance.

Disabling the Proxy-Support Header You can control the header using header modification policy. Suppression or modification of the Proxy-Support custom header keeps the SG appliance from sending this default header. Use either the Visual Policy Manager (VPM) or CPL to disable the header through policy. For complete information on using VPM, refer to Volume 6: VPM and Advanced Policy. Note: To suppress the Proxy-Support header globally, use the http force-ntlm

command to change the option. To suppress the header only in certain situations, continue with the procedures below. To suppress the proxy-support header through VPM: To suppress the header using VPM, create a new Web Access Layer. Then: 1.

Right click in the Action field to see the drop-down list; select Set.

2.

Click New to see the drop-down list; select Control Response Header.

3a 3b 3c 3d

110

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer 3.

Fill in the fields as follows: a.

Name: Enter a meaningful name.

b.

Show: Select Custom from the drop-down list.

c.

Header Name: Enter Proxy-Support.

d. Make sure the Suppress radio button is selected. 4.

Click OK; click Apply.

To suppress the proxy-support header through CPL: Use CPL to define the Proxy-Support custom header object and to specify what action to take. The example below uses Proxy-Support as the action name, but you can choose any name meaningful to you. The result of this action is to suppress the Proxy-Support header action.Proxy-Support(yes) define action Proxy-Support delete(response.x_header.Proxy-Support) end action Proxy-Support

Using Web FTP If HTTP is configured to be explicit, Internet Explorer version 6.0 users accessing FTP sites over HTTP must disable the browser setting Enable folder view for FTP sites. To access this attribute in Internet Explorer, select Tools > Internet Options, click the Advanced tab, deselect Enable folder view for FTP sites, and click OK. For information on using FTP, see “Managing the FTP Proxy” on page 77.

111

Volume 2: Proxies and Proxy Services Section E: Using Explicit HTTP Proxy with Internet Explorer

112

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer

113

Volume 2: Proxies and Proxy Services Section E: Using Explicit HTTP Proxy with Internet Explorer

114

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer

115

Volume 2: Proxies and Proxy Services Section E: Using Explicit HTTP Proxy with Internet Explorer

116

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer

117

Volume 2: Proxies and Proxy Services Section E: Using Explicit HTTP Proxy with Internet Explorer

118

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer

119

Volume 2: Proxies and Proxy Services

120

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

The Blue Coat HTTPS Reverse Proxy implementation: ❐

Combines hardware-based SSL acceleration with full caching functionality.

❐

Establishes and services incoming SSL sessions.

❐

Provides SSL v2.0, SSL v3.0, and TLSv1 protocol support.

Creating an HTTPS reverse proxy is unlike other proxies in that a number of preliminary steps are required before you can use the proxy. Preliminary steps include: ❐

Creating or importing a keyring. (Refer to Volume 4: Securing the Blue Coat SG Appliance for information on creating or importing a keyring.)

❐

(If necessary) Creating Certificate Signing Requests (CSRs) that can be sent to Certificate Signing Authorities (CAs).

❐

Importing server certificates issued by CA authorities for external use and associate them with the keyring. (Refer to Volume 4: Securing the Blue Coat SG Appliance.) -or-

❐

Creating certificates for internal use and associate them with the keyring.

❐

(Optional, if using server certificates from CAs) Importing Certificate Revocation Lists (CRLs) so the SG appliance can verify that certificates are still valid.

When these steps are complete, you can configure the HTTPS Reverse Proxy service. A common scenario in using HTTPS Reverse Proxy, which connects the client to the SG appliance, is in conjunction with HTTPS origination, which is used to connect the appliance to the origin content server (OCS). For more information on this option, see Section B: "Configuring HTTP or HTTPS Origination to the Origin Content Server" on page 125. This chapter discusses: ❐

Section A: "Configuring the HTTPS Reverse Proxy"

❐

Section B: "Configuring HTTP or HTTPS Origination to the Origin Content Server" on page 125

121

Volume 2: Proxies and Proxy Services Section A: Configuring the HTTPS Reverse Proxy

Section A: Configuring the HTTPS Reverse Proxy To configure the HTTPS reverse proxy: 1.

Select Configuration > Services > Proxy Services.

2.

Do one of the following: •

To create a new HTTPS Reverse Proxy service, see Step 3.

•

To edit the listeners on an existing HTTPS Reverse Proxy service, highlight the HTTPS Reverse Proxy service to change and click Edit.

3 4

5

6

7b

7a

7c 7d

3.

Make sure the proxy has a meaningful name.

122

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

Section A: Configuring the HTTPS Reverse Proxy 4.

Configure Proxy Settings: a.

Verify that HTTPS Reverse Proxy is selected in the Proxy settings drop-down list.

b.

In the Keyring drop-down list, select any already created keyring that is on the system. The system ships with a default keyring that is reusable for each HTPPS service. Note: The configuration-passwords-key keyring that shipped with the SG appliance does not contain a certificate.

The appliance-key keyring does contain a certificate if you have Internet connectivity, but it cannot be used for purposes other than appliance authentication. For information about appliance authentication, see Chapter 2 of Volume 5: Advanced Networking. c.

CA Cert List: Use the drop-down list to select any already created list that is

on the system. d. SSL Versions: Use the drop-down list to select the version to use for this service. The default is SSL v2/v3 and TLS v1. e.

Verify Client (Used with the Forward Client Certificate option.). Selecting this checkbox enables the Forward Client Certificate and puts the extracted client

certificate information into the Client-Cert header that is included in the request when it is forwarded to the origin content server. The header contains the certificate serial number, subject, validity dates, and issuer (all as name=value pairs). The actual certificate itself is not forwarded. f.

5.

Forward Client Cert: (Should be used with the Verify Client option.) Selecting this checkbox puts the extracted client certificate information into a header that is included in the request when it is forwarded to the OCS.

Configure TCP/IP options: a.

Reflect-client-iP: Determines how the client IP address is presented to the

origin server for explicitly proxied requests b. 6.

Early intercept: This option cannot be changed when creating or editing an HTTPS Reverse Proxy service.

Configure ADN options: a.

Enable ADN: Controls whether ADN is enabled for a specific service. Enabling ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment)

b.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN optimization during initial configuration. You should de-select the checkbox if you are not configuring ADN optimization.

123

Volume 2: Proxies and Proxy Services Section A: Configuring the HTTPS Reverse Proxy 7.

Add a new listener: a.

Click New to add a new listener to the HTTPS Reverse Proxy; click Edit to change the current settings.

b.

Select a Destination IP address from the drop-down list.

c.

Identify the port where you want this service to listen.

d. Select the default behavior for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e. 8.

Click OK.

Click Apply.

Relevant CLI Syntax to Create/Edit an HTTPS-Reverse-Proxy Service ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create https-reverse-proxy service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {ccl list_name | cipher-suite cipher-suite | forward-client-cert {enable | disable}| keyring keyring_id | reflect-client-ip {enable | disable}| ssl-versions {sslv2 | sslv3 | tlsv1 | sslv2v3 | sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1} | use-adn {enable | disable}| verify-client {enable | disable}} SGOS#(config service-name) bypass {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

124

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server

Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server In previous procedures, you configured HTTPS Reverse Proxy to the SG appliance. In two common termination scenarios, you must also configure HTTPS origination to the Origin Content Server (OCS). The first two scenarios are used to provide a secure connection between the proxy and server, if, for example, the proxy is in a branch office and is not co-located with the server. Figure 9-1. Scenario 1: HTTPS Reverse Proxy with HTTPS Origination HTTPS Reverse Proxy Client

HTTPS

HTTPS Origination

SG

SG

HTTPS

Origin Content Server

Steps

Steps

• Configure a keyring.

• (Optional) Add a forwarding host.

• Configure the SSL client.

• (Optional) Set an HTTPS port.

• Configure the HTTPS service.

• (Optional) Enable server certificate verification.

Figure 9-2. Scenario 2: HTTP Termination with HTTPS Origination HTTP Termination Client

HTTP

HTTPS Origination SG

SG

HTTPS

Steps:

Steps

• Client is explicitly proxied.

• Server URL rewrite.

Origin Content Server

-or• Add a forwarding host • Set an HTTPS port. • (Optional) Enable server certificate verification.

Using server URL rewrite is the preferred method. For information on rewriting the server URL, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide. To configure HTTPS origination: At the (config) command prompt, enter the following commands: SGOS#(config forwarding) create host_alias hostname https[=port_number] server ssl-verify-server=yes

where: Table 9-1. HTTPS Origination Commands Option

Parameters

Description

host_alias

alias_name

Specifies the alias name of the OCS.

host_name https

Specifies the hostname or IP address of the OCS, such as www.bluecoat.com. [=port_number]

Specifies the port number on which the OCS is listening.

125

Volume 2: Proxies and Proxy Services Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server Table 9-1. HTTPS Origination Commands (Continued) Option

Parameters

Description

server

Specifies to use the relative path for URLs in the HTTP header because the next hop is a Web server, not a proxy server. Proxy is the default.

ssl-verifyserver=

yes | no

Specifies whether the upstream server certificate should be verified. You can only enable this command if the upstream host is a server, not a proxy.

The next scenario is useful when the SG appliance is deployed as a reverse proxy. This scenario is used when it’s not necessary for a secure connection between the proxy and server. For information on using the SG appliance as a reverse proxy, see “Customizing the HTTP Proxy Profile” on page 96. Figure 9-3. Scenario 3: HTTPS Reverse Proxy with HTTP Origination HTTPS Reverse Proxy Client

HTTPS

SG

HTTP Origination SG

HTTP

Origin Content Server

Steps

Steps

• Configure a keyring

• Server URL rewrite

• Configure the SSL client

-or-

• Configure the HTTPS service

• Add a forwarding host (only for SGOS 3.1 or higher) • Set an HTTP port

Using server URL rewrite is the preferred method. For information on rewriting the server URL, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide. You can only configure HTTP origination through the CLI. You cannot use the Management Console. To configure HTTP origination: At the (config) command prompt, enter the following commands: SGOS#(config forwarding) create host_alias host_name http[=port_number] server

where: Table 9-2. HTTP Origination Commands host_alias

alias_name

Specifies the hostname or IP address of the OCS, such as www.bluecoat.com.

host_name

http

server

Specifies the alias name of the OCS.

[=port_number]

Specifies the port number on the OCS in which HTTP is listening. server specifies to use the relative path for URLs in the HTTP header because the next hop is a Web server, not a proxy server. Proxy is the default.

126

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server

Creating Policy for HTTP and HTTPS Origination Forwarding hosts must be already created on the SG appliance before forwarding policy can be created. To create a policy using CPL: url.host=host_name forward(host_alias)

To create a policy using VPM: 1.

In the VPM module, create a Forwarding layer.

2.

Set the Destination to be the URL of the OCS. Set the Action to forward to the forwarding host and configure parameters to control forwarding behavior.

127

Volume 2: Proxies and Proxy Services

128

Chapter 10: Managing Shell Proxies

Shell proxies are those that provide a shell allowing a client to connect to the SG appliance. In this version, only a Telnet shell proxy is supported. Using a shell proxy, you can: ❐

terminate a Telnet protocol connection either transparently or explicitly.

❐

authenticate users either transparently or explicitly.

❐

view the access log.

❐

enforce policies specified by CPL.

❐

communicate though an upstream SOCKS gateway and HTTP proxy using the CONNECT method.

Within the shell, you can configure the prompt and various banners using CPL $substitutions. You can also use hard-coded text instead of CPL substitutions

(available substitutions are listed in the table below). The syntax for a CPL substitution is: $(CPL_property) Table 10-1. CPL Substitutions for Shell Proxies Substitution

Description

proxy.name or appliance.name

Configured name of the SG appliance.

proxy.address

IP address of the appliance on which this connection is accepted.

proxy.card

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

client.protocol

This is "telnet".

client.address

IP address of the client.

proxy.primary_address or appliance.primary_address

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

release.id

SGOS version.

Customizing Policy Settings for Shell Proxies To manage a shell proxy through policy, you can use the conditions, properties, and actions listed below. For information on using CPL to manage shell proxies, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

129

Volume 2: Proxies and Proxy Services

Conditions • All time and date related triggers

• proxy.address=

• All exception related triggers

• proxy.card=

• All server_url triggers

• proxy.port=

• All url triggers

• client.protocol=

• All authentication related triggers

• user-defined conditions

• category=

• client.protocol=telnet

• client.address=

• url.scheme=telnet

Properties • allow, deny, force_deny

• force_exception(exception_id[, details])

• action.action_name{yes|no)

• forward(alias_list | no)

• All trace() properties

• forward.fail_open(yes | no)

• All access_log() properties

• reflect_ip(auto|no|client|vip|ip-address)

• All log.xxx() properties

• socks_gateway(alias_list | no)

• access_server(yes|no)

• socks_gateway.fail_open(yes | no)

• authenticate.force(yes|no)

• telnet.prompt(no | string)

• authenticate(realm)

• telnet.realm_banner(no | string)

• exception(exception_id[, details])

• telnet.welcome_banner(no | string)

The banner strings support $-sign substitutions.

Actions :

• rewrite(url.host, host_regex_pattern, replacement_pattern)

• log_message()

• rewrite(url, url_regex_pattern, replacement_pattern)

• notify_email(subject, body)

• set(url_port, port_number)

• notify_snmp(message)

Boundary Conditions for Shell Proxies ❐

A hardcoded timeout of five minutes is enforced from the acceptance of a new connection until destination information is provided using the Telnet command.

❐

If proxy authentication is enabled, users have three chances to provide correct credentials.

❐

Users are not authenticated until destination information is provided.

130

Chapter 10: Managing Shell Proxies

❐

Users can only enter up to an accumulated 2048 characters while providing the destination information. (Previous attempts count against the total number of characters.)

❐

Connection to an upstream HTTP proxy is not encouraged.

❐

If connections from untrustworthy IP address or subnet are not desired, then a client IP/subnet-based deny policy must be written.

Understanding Telnet Shell Proxies The Telnet shell proxy allows you to manage a Telnet protocol connection to the SG appliance. Using the Telnet shell proxy, you can do: ❐

Explicit termination without proxy authentication, where you explicitly connect, through Telnet, to the SG hostname or IP address. In this case, the SG appliance provides a shell.

❐

Explicit termination with proxy authentication, where after obtaining the destination host and port information from user, the SG appliance challenges for proxy credentials. Once the correct proxy credentials are provided and authenticated, the appliance makes an upstream connection and goes into tunnel mode. In this case, the appliance provides a shell.

❐

Transparent termination without proxy authentication, where the SG appliance intercepts Telnet traffic through an L4 switch, software bridge, or any other transparent redirection mechanism. From the destination address of TCP socket, the SG appliance obtains OCS contact information and makes the appropriate upstream connection, either directly or through any configured proxy. For more information on configuring a transparent proxy, see Appendix B: "Explicit and Transparent Proxy" on page 191.

❐

Transparent termination with proxy authentication, where, after intercepting the transparent connection, the SG appliance challenges for proxy credentials. Once the correct proxy credentials are provided and authenticated, the SG appliance makes an upstream connection and goes into tunnel mode.

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 ❐

Defaults •

Proxy Edition: On a new system, Telnet proxy service is configured but disabled on port 23.

•

Proxy Edition: On an upgrade, a Telnet proxy service is not created.

•

On MACH5 Edition, a transparent TCP tunnel connection listening on port 23 is created in place of the default Telnet proxy service.

131

Volume 2: Proxies and Proxy Services

Note: To use Telnet to manage the SG appliance, create a Telnet-Console rather than a Telnet service. The Telnet service allows you to use Telnet for outbound connections, and the appliance functions as Shell proxy in that situation. For more information on the Telnet-Console, see “ Notes on Managing the Telnet Console” on page 21.

To edit or create a Telnet proxy service: 1.

Select Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New. Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

4 5

6

7b

7a

7c 7d

4.

In the Name field, choose a meaning name for the new proxy service.

5.

In the Proxy settings field, select Telnet.

132

Chapter 10: Managing Shell Proxies

6.

Configure TCP/IP options: a.

Reflect Client IP: Enables or disables sending of client's IP address instead of

the SG appliance's IP address. b. 7.

Early intercept: This option cannot be changed when creating or editing an Telnet proxy service.

Create a new listener: a.

Click New.

b.

Select a Destination IP address from the radio buttons.

c.

In the Port Range field, enter the ports on which the service should listen. The default port is 23.

d. Select the default action for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e.

Click OK.

Relevant CLI Syntax to Create/Edit a Telnet Proxy Service: ❐

To enter configuration mode: SGOS#(config) proxy-services SGOS#(config proxy-services) create telnet service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute reflect-client-ip {enable | disable} SGOS#(config service-name) bypass {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

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

Select Configuration > Proxy Settings > Shell Proxies > Telnet Proxy Settings.

133

Volume 2: Proxies and Proxy Services

2.

To set the maximum concurrent connections, select Limit Max Connections. Enter the number of maximum concurrent connections allowed for this service. Allowed values are between 1 and 65535.

3.

Set the banner settings:

4. 5.

a.

To set the Welcome banner message (users see this when they enter the shell), click View/Edit next to the Welcome Banner. The Edit Welcome Banner dialog displays. (If you do not want this banner displayed, remove the text.)

b.

Change the banner as necessary. The $(client.protocol) text is a CPL variable indicating that Telnet is the protocol. You do not have to use a variable. When finished, click OK.

Click Apply to commit the changes to the SG appliance. To set the realms banner message (users see this help message just before they see the Username prompt for proxy authentication), click View/Edit next to the Realms Banner.

The Edit Realms Banner dialog displays. (If you do not want this banner displayed, remove the text.)

134

Chapter 10: Managing Shell Proxies

Change the banner as necessary. The $(realm) text is a CPL variable indicating the name of the realm. You do not have to use a variable. When finished, click OK. 6.

Click Apply to commit the changes to the SG appliance.

7.

To set the prompt, click View/Edit next to the Prompt line.

Change the banner as necessary. The default is $(client-protocol)>, where $(client-protocol) is Telnet. You do not have to use a variable. (For a list of available substitutions, see “Table 10-1. CPL Substitutions for Shell Proxies” on page 129.) When finished, click OK. 8.

Click Apply to commit the changes to the SG appliance.

Related CPL Syntax to Customize Telnet Shell Proxy Settings You can use CPL substitutions when creating welcome and realm banners and Telnet prompts. For a list of available CPL substitutions, see “Table 10-1. CPL Substitutions for Shell Proxies” on page 129. Related CLI Syntax to Configure a Telnet Shell Proxy SGOS#(config) shell {max-connections number_of_connections | prompt prompt | realm-banner realm_banner | welcome-banner welcome_banner}

Notes for Telnet Shell Proxies ❐

Telnet credential exchange is in plaintext.

❐

A Telnet proxy cannot be used to communicate with non-Telnet servers (such as Webservers on port 80) because Telnet proxies negotiate Telnet options with the client before a server connection can be established.

Shell History Statistics The Shell History tab displays client connections over the last 60-minute, 24-hour, and 30day period. Note: The Shell history statistics are available only through the Management Console.

To view Shell history statistics: 1.

Select Statistics > Protocol Details > Shell History.

135

Volume 2: Proxies and Proxy Services

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Viewing Shell History Statistics The Shell History tab displays client connections over the last 60-minute, 24-hour, and 30day period. Note: The Shell history statistics are available only through the Management Console.

To view Shell history statistics: 1.

2.

Select Statistics > Protocol Details > Shell History.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

136

Chapter 11: Managing 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/IP or UDP protocols. The SG supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5. Note: For Blue Coat compatibility with SOCKS clients, check with customer support. For information on the Permeo Premium Agent (Permeo PA), see “Using the Permeo PA SOCKS Client with the Blue Coat SOCKS Server” on page 140

In a typical deployment, the SOCKS proxy works with the Endpoint Mapper proxy and MAPI handoff. In this deployment, you will: ❐

Create an Endpoint Mapper proxy at the remote office (the downstream proxy) that intercepts Microsoft RPC traffic and creates dynamic TCP tunnels. Traffic to port 135 is transparently redirected to this service using bridging or L4 switch or WCCP. For information on creating and enabling an Endpoint Mapper proxy service, see “Chapter 6: Managing the Endpoint Mapper and MAPI Proxies” on page 63.

❐

Create any other TCP tunnel proxies you need at the remote office: SMTP, DNS, and the like. For information on configuring TCP tunnels, see “Chapter 13: Managing the TCP Tunneling Proxy” on page 171.

❐

Create a SOCKS gateway at the remote office and enable compression for that gateway. This SOCKS gateway points to a SOCKS proxy located at the main office location (the upstream proxy, the core of the network). For information on creating a SOCKS gateway and enabling SOCKS compression, see the SOCKS Gateway Configuration chapter in Volume 5: Advanced Networking.

❐

Set policy to forward TCP traffic through that SOCKS gateway. You can do this through the layer using either the VPM or CPL. For more information, see “Using Policy to Control the SOCKS Proxy” on page 140.

Creating or Editing a SOCKS Proxy Service To create or edit a SOCKS proxy service: 1.

Select Configuration > Services > Proxy Services.

2.

To edit an existing SOCKS proxy service, highlight the service and click Edit. To create a new proxy service, click New.

Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

137

Volume 2: Proxies and Proxy Services

3 4

5

6

7b

7a 7c 7d

3. 4.

5.

If you are creating a new SOCKS proxy service, enter a meaningful name in the Name field. Configure Proxy Settings options: a.

In the Proxy settings field, select SOCKS from the drop-down menu.

b.

Select the Detect Protocol checkbox to automatically detect the protocol being used. Note that this breaks connections that do not have the client send information first, but expect the server to respond on connection. It also can add significant delay if the client does not send specific information, and only after timing out does it treat the traffic as unknown.

Configure TCP/IP options: a.

Reflect Client IP: This option cannot be changed when creating or editing an

SOCKS proxy service. b. 6.

Early intercept: This option cannot be changed when creating or editing an SOCKS proxy service.

The ADN Optimization checkbox is selected by default if you enabled WAN optimization during initial configuration. You should de-select the checkbox if you are not configuring a WAN optimization network.

138

Chapter 11: Managing a SOCKS Proxy

7.

Create a new listener: a.

Click New; if you edit an existing listener, click Edit.

b.

Define the IP address option: explicit or the specified address.

c.

In the Port Range field, enter the ports on which the service listens. The default port for the SOCKS proxy is 1080.

d. Select the default behavior for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e.

Click OK.

Relevant CLI Syntax to Create/Edit a Proxy Service: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create socks service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {explicit | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {adn-optimize {enable | disable}| detect-protocol {enable | disable}} SGOS#(config service-name) bypass {explicit | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) intercept {explicit | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {explicit | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

Configuring the SOCKS Proxy Complete the following steps to create a SOCKS proxy and to configure SOCKS-proxy connection and timeout values. To create a SOCKS proxy server: 1.

Select Configuration > Services > SOCKS Proxy.

2.

Fill in the option fields (described below) as needed. The defaults are displayed and should be sufficient for most purposes.

139

Volume 2: Proxies and Proxy Services

Table 11-1. SOCKS Proxy Options Option

Suboption

Description

Max-Connections

connections

Set maximum allowed SOCKS client connections. The default of 0 indicates an infinite number of connections are allowed.

Connection timeout

seconds

Set maximum time to wait on an outbound CONNECT.

Bind timeout on accept

seconds

Set maximum time to wait on an inbound BIND.

Minimum idle timeout

seconds

Specifies the minimum timeout after which SOCKS can consider the connection for termination when the max connections are reached.

Maximum idle timeout

seconds

Specifies the max idle timeout value after which SOCKS should terminate the connection.

Related CLI Syntax to Configure the SOCKS Proxy SGOS#(config) socks-proxy accept-timeout seconds SGOS#(config) socks-proxy connect-timeout seconds SGOS#(config) socks-proxy max-connections num_connections SGOS#(config) socks-proxy max-idle-timeout seconds SGOS#(config) socks-proxy min-idle-timeout seconds

Using Policy to Control the SOCKS Proxy Once the basic configuration for the SOCKS proxy has been set, you can use policy to control the SOCKS proxy. ❐

To use SOCKS version 5, which allows you to use a SOCKS username/password, you must set the version through policy. •

If using VPM, go to the Forwarding layer, select Source > Set Source Object > New > SOCKS Version.

•

If using CPL. enter the following: client.protocol=socks ALLOW socks.version=5 DENY

Using the Permeo PA SOCKS Client with the Blue Coat SOCKS Server The SG appliance can be used as a SOCKS gateway by the Permeo Premium Agent (PA), with full licensing support and Dynamic Port Management (DPM) functionality. The SG appliance supports the Windows Permeo PA SOCKS client version 5.12a, including those clients that require the special probe license protocol and corresponding customer ID. Note that each SG appliance can only support PA clients with the same customer ID. Licensing the PA SOCKS client on the SG appliance is a two step process: ❐

Get the customer ID from the PA client.

❐

Tell the SG appliance the PA customer ID.

140

Chapter 11: Managing a SOCKS Proxy

Note:

The default license setting for the Permeo PA client on the SG appliance is off. This setting should only be enabled when you are using the PA client. To obtain the PA Customer ID: 1.

From the PA client, launch the Permeo Agent User Properties (Start Menu > All Programs > Permeo Premium Agent).

1.

2.

Click the About tab.

Make a note of the Customer ID number, which is in hex. In the example above the Customer ID is 1111.

To validate the Permeo PA license on the SG appliance: Note:

You cannot validate the license through the Management Console.

141

Volume 2: Proxies and Proxy Services

1.

From the SG appliance, launch the CLI: SGOS> enable Enable Password: SGOS# configure terminal Enter configuration commands, one per line. End with CTRL-Z.

2.

From the (config) prompt: SGOS#(config) socks-proxy pa-customer-id customer_id

where customer_id is the Customer ID number you took from the About tab on the PA client. To disable the Permeo PA license: From the (config) prompt: SGOS#(config) socks-proxy pa-customer-id 0

Limitations ❐

Protocol Detection interferes with SOCKS and must be disabled on the SG appliance. The CPL policy should include the line detect_protocol(no).

❐

SOCKS compression should be disabled when using the PA SOCKS client. The CPL policy should include the line socks.accelerate(no).

❐

The SG appliance only supports username and password authentication between the SG appliance and the SOCKS Permeo PA client.

❐

The ping and trace route functions from Permeo PA administrator tool are not compatible with this release (5.1).

❐

Proxy chaining is not supported between the SG appliance and the Permeo Application Gateway (ASG).

❐

The policy update feature on the PA is not supported when using the SG appliance. Note that PA can get policy from the HTTP source as well as the ASG so it can still do automatic updates from a external Web server.

❐

Only the UPWD authentication method is supported.

Viewing SOCKS History Statistics The SOCKS History tabs (SOCKS Clients, SOCKS Connections, and SOCKS client and server compression) display client data, Connect, Bind, and UPD Associate requests, client and server UDP, TCP and compression requests. Note: The SOCKS history statistics are available only through the Management Console.

Viewing SOCKS Clients The SOCKS Clients tab displays SOCKS Client data. To view SOCKS client data: Select Statistics > SOCKS History > SOCKS Clients.

142

Chapter 11: Managing a SOCKS Proxy

Viewing SOCKS Connections The SOCKS Connections tab displays SOCKS Connection data. To view SOCKS connection data: Select Statistics > SOCKS History > SOCKS Connections.

Viewing SOCKS Client and Server Compression Gain Statistics Under SOCKS History, you can view SOCKS client and server compression-gain statistics for the SG over the last 60 minutes, 24 hours, and 30 days in the Client Comp. Gain and the Server Comp. Gain tabs. These statistics are not available through the CLI. The green display on the bar graph represents uncompressed data; the blue display represents compressed data. Hover your cursor over the graph to see the compressed gain data.

143

Volume 2: Proxies and Proxy Services To view SOCKS client compressed gain statistics: 1.

2.

Select Statistics > SOCKS History > Client Comp. Gain.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

To view SOCKS Server compressed gain statistics: 1.

2.

Select Statistics > SOCKS History > Server Comp. Gain.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

144

Chapter 12: Managing the SSL Proxy

HTTPS traffic poses a major security risk to enterprises. Because the SSL content is encrypted, it can’t be monitored by normal means, allowing users to bring in viruses, access forbidden sites, or leak business confidential information over the HTTPS connection on port 443. The SSL proxy allows you to intercept HTTPS traffic (in explicit and transparent modes) so that security measures such as authentication, virus scanning and URL filtering, and performance enhancements such as HTTP caching can be applied to HTTPS content. Additionally, the SSL proxy allows you to validate server certificates presented by various HTTPS sites at the gateway and offers information about the HTTPS traffic in the access log.

Understanding the SSL Proxy The SSL Proxy can be used to tunnel or intercept HTTPS traffic. The SSL Proxy tunnels all HTTPS traffic by default unless there is an exception, such as a certificate error or a policy denial. In such cases the SSL Proxy intercepts the SSL connection and sends an error page to the user. The SSL Proxy allows interception of HTTPS traffic for monitoring reasons as well. Note:

Some HTTPS traffic, such as financial information, should not be intercepted. The SSL proxy can do the following operations while tunneling HTTPS traffic. ❐

Validate server certificates, including revocation checks using Certificate Revocation Lists (CRLs).

❐

Check various SSL parameters such as cipher and version.

❐

Log useful information about the HTTPS connection.

When the SSL Proxy is used to intercept HTTPS traffic, it can also: ❐

Cache HTTPS content.

❐

Apply HTTP-based authentication mechanism.

❐

Do virus scanning and URL filtering.

❐

Apply granular policy (such as validating mime type and filename extension).

Validating the Server Certificate The SSL Proxy can do the following checks on server certificates: ❐

Verification of issuer signature.

❐

Verification of certificate dates.

❐

Comparison of hostname in the URL and certificate (intercepted connections only).

145

Volume 2: Proxies and Proxy Services

Hostnames in server certificates are important because the SSL Proxy can identify a Web site just by looking at the server certificate if the hostname is in the certificate. Most content-filtering HTTPS sites follow the guideline of putting the name of the site as the common name in the server's certificate. ❐

Verification of revocation status. To mimic the overrides supported by browsers, the SSL Proxy can be configured to ignore failures for the verification of issuer signatures and certificate dates and comparision of the hostname in the URL and the certificate.

The SG appliance trusts all root CA certificates that are trusted by Internet Explorer and Firefox. This list is updated to be in sync with the latest versions of IE and Firefox.

Checking CRLs An additional check on the server certificate is done through Certificate Revocations Lists (CRLs). CRLs are lists that show which certificates are no longer valid; the CRLs are created and maintained by Certificate Signing Authorities that issued the original certificates. Only CRLs that are issued by a trusted issuer can be used by the SG Appliance. The CRL issuer certificate must exist as CA certificate on the SG Appliance before the CRL can be imported. The SG Appliance allows: ❐

One local CRL per certificate issuing authority.

❐

An import of a CRL that is expired; a warning is displayed in the log.

❐

An import of a CRL that is effective in the future; a warning is displayed in the log.

Determining What HTTPS Traffic to Intercept The SSL proxy tunnels HTTPS traffic by default; it does not intercept HTTPS traffic. Many existing policy conditions, such as destination IP address and port number can be used to decide which HTTPS connections to intercept. Additionally, the SSL proxy allows the hostname in the server certificate to be used to make the decision to intercept or tunnel the traffic. The server certificate hostname can be used as is to make intercept decisions for individual sites, or it can be categorized using any of the various URL databases supported by Blue Coat. Categorization of server certificate hostnames can help place the intercept decision for various sites into a single policy rule. Recommendations for intercepting traffic include: ❐

Intercept Intranet traffic

❐

Intercept suspicious Internet sites, particularly those that are categorized as none in the server certificate.

Managing Decrypted Traffic After the HTTPS connection is intercepted, you can do: ❐

Anti-virus scanning over ICAP.

146

Chapter 12: Managing the SSL Proxy

❐

URL filtering (on box and off-box). Blue Coat recommends on box URL/Content filtering if you use transparent proxy. When the URL is sent off-box for filtering, only the hostname or IP address of the URL (not the full path) is sent for security reasons.

❐

Filtering based on the server certificate hostname.

❐

Caching.

HTTPS applications that require browsers to present client certificates to secure Web servers do not work if you are intercepting traffic. Such applications should not be intercepted by creating a policy rule. If you intercept HTTPS traffic, be aware that local privacy laws might require you to notify the user about interception or obtain consent prior to interception. You can use the HTML Notify User object to notify users after interception. You can use consent certificates to obtain consent prior to interception. The HTML Notify User is easier; however, note that the SG Appliance has to decrypt the first request from the user before it can issue an HTML notification page.

Using the SSL Proxy with ADN Optimization The SSL proxy itself can be used as a split proxy, which requires two SSL proxies, one at the branch and one at the core, working together. A split proxy can implement functionality that is not possible in a standalone proxy. In this configuration, the SSL proxy supports ADN optimization on WAN networks, and SSL traffic performance can be increased through the byte caching capability offered. The branch proxy is configured with both ADN optimization and SSL proxy functionality. The concentrator proxy does not require any configuration related to SSL Proxy. It only requires the necessary ADN configuration for applying byte caching capabilities to intercepted SSL content. No special configuration is done to the SSL proxy. Securing the tunnels and authenticating the devices is done from the Configuration > App. Delivery Network panes.

147

Volume 2: Proxies and Proxy Services Section A: Intercepting HTTPS Traffic

Section A: Intercepting HTTPS Traffic Intercepting HTTPS traffic (by decrypting SSL connections at the SG appliance) allows you to apply security measures like virus scanning and URL filtering. Configuration to intercept HTTPS traffic requires the following steps: ❐

Determine whether you are using transparent or explicit mode. For information on explicit versus transparent proxies, see “Explicit and Transparent Proxy” on page 191.

❐

Create an SSL service or HTTP/SOCKS services with protocol detection enabled, depending on whether you are using transparent or explicit mode. For more information on creating an SSL service, skip to “Setting Up the SSL Proxy in Transparent Proxy Mode” on page 148.

❐

Create or import an issuer keyring, which is used to sign emulated server certificates to clients on the fly, allowing the SSL proxy to examine SSL content. For more information on creating an issuer keyring, see “Creating an Issuer Keyring for SSL Interception” on page 151.

❐

(Optional) Use the Notify User object or client consent certificates to notify users that their requests are being intercepted and monitored. Whether this is required depends on local privacy laws. Note that the SG appliance has to decrypt the first request from the user to issue an HTML notification page. If this is not desirable, use client consent certificates instead. For more information on configuring the Notify User object, refer to Volume 6: VPM and Advanced Policy. For information on managing client consent certificates, see “Using Client Consent Certificates” on page 152.

❐

Download CA certificates to desktops to avoid a security warning from the client browsers when the SG appliance is intercepting HTTPS traffic. For information, see “Downloading an Issuer Certificate” on page 152.

❐

Using policy (VPM or CPL), create rules to intercept SSL traffic and to control validation of server certificates. By default, such traffic is tunneled and not intercepted. You must create suitable policy before intercepting SSL traffic. For more information on using policy to intercept SSL traffic, see “Configuring SSL Rules through Policy” on page 156.

❐

Configure the Blue Coat AV or other third-party ICAP vendor, if you have not already done this. For more information on ICAP-based virus scanning, refer to Volume 7: Managing Content.

❐

Configure the Blue Coat Web Filter (BCWF) or a third-party URL-filtering vendor, if you have not already done this. For more information on configuring BCWF, refer to Volume 7: Managing Content.

❐

Configure Access Logging. For more information on configuring access logging, refer to Volume 8: Access Logging.

❐

To customize exception pages (in case of server certificate verification failure), refer to Volume 6: VPM and Advanced Policy.

Setting Up the SSL Proxy in Transparent Proxy Mode Proxy services are configured from the Management Console or the CLI. If using SSL proxy in transparent mode, continue with this section.

148

Chapter 12: Managing the SSL Proxy

Section A: Intercepting HTTPS Traffic If using SSL proxy in explicit mode, you might need an HTTP proxy or a SOCKS proxy. For information on configuring an SSL Proxy in explicit mode, see “Setting Up the SSL Proxy in Explicit Proxy Mode” on page 151. You can use a TCP Tunnel service in transparent mode to get the same functionality. A TCP tunnel service is useful when you have a combination of SSL and non-SSL traffic going over port 443 and you do not want to break the non-SSL traffic. The SSL service requires that all requests to its port be SSL. To configure an SSL service in transparent proxy mode: 1.

From the Management Console, select Configuration > Services > Proxy Services.

2.

Click New.

3 4

5a, 5b

5c 5d

7

6

8 9

3.

Give the SSL proxy a meaningful name.

4.

Select SSL from the Proxy settings drop-down list.

5.

Configure TCP/IP Settings options:

149

Volume 2: Proxies and Proxy Services Section A: Intercepting HTTPS Traffic a.

The Early Intercept checkbox cannot be changed for the SSL proxy service.

b.

The Reflect Client IP checkbox enables or disables sending of client's IP

address instead of the SG appliance's IP address. Note that this setting is overruled by policy. 6.

7.

Configure ADN options: a.

Enable ADN. Select this checkbox if you want this service to use ADN. Enabling ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment).

b.

The Optimize Bandwidth checkbox is selected by default if you enabled WAN optimization during initial configuration. You should de-select the checkbox if you are not configuring a WAN optimization network.

Create a new listener: a.

Click New; if you edit an existing listener, click Edit.

b.

Define the IP address option: explicit or the specified address.

c.

In the Port Range field, enter the ports on which the service should listen. The default port for SSL is 443.

d. Select the default behavior for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. e.

Click OK.

Continue with “Creating an Issuer Keyring for SSL Interception” on page 151. Relevant CLI Syntax to Create/Edit an SSL Proxy Service: ❐

To enter configuration mode for the service: SGOS#(config) proxy-services SGOS#(config proxy-services) create service-type service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {adn-optimize {enable | disable} | reflect-client-ip {enable | disable} | use-adn {enable | disable}} SGOS#(config service-name) bypass {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

150

Chapter 12: Managing the SSL Proxy

Section A: Intercepting HTTPS Traffic

Setting Up the SSL Proxy in Explicit Proxy Mode The SSL Proxy can be used in explicit mode in conjunction with the HTTP Proxy or SOCKS Proxy. You must create an HTTP Proxy service or a SOCKS Proxy service and use it as the explicit proxy from desktop browsers. You must also ensure that the detectprotocol attribute is enabled for these services. When requests for HTTPS content are sent to either a SOCKS proxy or an HTTP proxy, the proxies can detect the use of the SSL protocol on such connections and enable SSL Proxy functionality. For information on configuring a new explicit HTTP or SOCKS proxy service, see “Creating an Explicit Proxy Server” on page 192. Continue with "Creating an Issuer Keyring for SSL Interception" on page 151.

Creating an Issuer Keyring for SSL Interception The SSL proxy can emulate server certificates; that is, present a certificate that appears to come from the origin content server. In actuality, Blue Coat has emulated the certificate and signed it using the issuer keyring. By default only the subjectName and expiration from the server certificate is copied to the new certificate sent to the client. Note that only keyrings with both a certificate and a keypair can be used as issuer keyrings. To specify the keyring: If you prefer, you can specify the issuer keyring through VPM or CPL instead of creating it here. Note: You can create a new keyring, import a keyring, or select among existing keyrings. For information on creating a keyring, refer to Volume 4: Securing the Blue Coat SG Appliance.

1.

From the Management Console, select Configuration > Proxy Settings > SSL Proxy.

2.

From the drop-down menu, select the keyring you want to use as the issuer keyring.

3.

Click Apply.

To configure policy, see “Configuring SSL Rules through Policy” on page 156. Related CLI Syntax to Specify the Keyring SGOS#(config ssl) proxy issuer-keyring keyring_name

To configure policy, see “Configuring SSL Rules through Policy” on page 156.

151

Volume 2: Proxies and Proxy Services Section A: Intercepting HTTPS Traffic

Using Client Consent Certificates The SSL Proxy, in forward proxy deployments, can specify whether a client (typically a browser) certificate is required. These certificates are used for user consent, not for user authentication. Whether they are needed depends upon local privacy laws. With client consent certificates, each user is issued a pair of certificates with the corresponding private keys. Both certificates have a meaningful user-readable string in the common name field. One certificate has a string that indicates grant of consent something like: “Yes, I agree to SSL interception”. The other certificate has a common name indicating denial of consent, something like: “No, I do not agree to SSL interception”. Policy is installed on the SG appliance to look for these common names and to allow or deny actions. For example, when the string “Yes, I agree to SSL interception” is seen in the client certificate common name, the connection is allowed; otherwise, it is denied. To configure client consent certificates: 1.

Install the issuer of the client consent certificates as a CA certificate.

2.

In VPM, configure the Require Client Certificate object in the Action column of the SSL Layer.

3.

Configure the Client Certificate object in the Source column to match common names.

Downloading an Issuer Certificate When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the enduser because the browser does not trust the issuer used by the SG appliance. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store. The SG appliance makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates. To download the certificate through Internet Explorer, see "To download a certificate through Internet Explorer:" on page 152. To download a certificate through Firefox, see “To download a certificate through Firefox:” on page 154. To download a certificate through Internet Explorer: Note: You can e-mail the console URL corresponding to the issuer certificate to end users so that the end-user can install the issuer certificate as a trusted CA.

1.

Go to Statistics > Advanced.

2.

Select SSL.

152

Chapter 12: Managing the SSL Proxy

Section A: Intercepting HTTPS Traffic 3.

Click Download a Certificate as a CA Certificate; the list of certificates on the system

display. 4.

Click a certificate (it need not be associated with a keyring); the File Download Security Warning displays asking what you want to do with the file.

5.

Click Save. When the Save As dialog box displays, click Save; the file downloads.

6.

Click Open to view the Certificate properties; the Certificate window displays.

153

Volume 2: Proxies and Proxy Services Section A: Intercepting HTTPS Traffic

7.

Click the Install Certificate button to launch the Certificate Import Wizard.

8.

Make sure the Automatically select the certificate store based on the type of certificate radio button is enabled before completing the wizard; the wizard announces when the certificate is imported.

9.

(Optional) To view the installed certificate, go to Internet Explorer, Select Tools > Internet Options > Contents > Certificates, and open either the Intermediate Certification Authorities tab or the Trusted Root Certification Authorities tab, depending on the certificate you downloaded.

To download a certificate through Firefox: Note: You can e-mail the console URL corresponding to the issuer certificate to end users so that the end-user can install the issuer certificate as a trusted CA.

1.

Go to Statistics > Advanced.

2.

Select SSL.

3.

Click Download a SG Certificate as a CA Certificate; the list of certificates on the system display.

4.

Click a certificate (it need not be associated with a keyring); the Download Certificate dialog displays.

154

Chapter 12: Managing the SSL Proxy

Section A: Intercepting HTTPS Traffic

5.

Enable the checkboxes needed. Note that you should view the certificate before trusting it for any purpose.

6.

Click OK; close the Advanced Statistics window.

155

Volume 2: Proxies and Proxy Services Section B: Configuring SSL Rules through Policy

Section B: Configuring SSL Rules through Policy SSL interception and access rules, including server certificate validation, are configured through policy—either VPM or CPL. Note that VPM is much easier to use than CPL. Use the SSL Intercept Layer to configure SSL interception; use the SSL Access Layer to control other aspects of SSL communication such as server certificate validation and SSL versions. To configure SSL rules using CPL, skip to “CPL in the SSL Intercept Layer” on page 159. This section covers the following topics: ❐

“Using the SSL Intercept Layer” on page 156.

❐

“Using the SSL Access Layer” on page 157

❐

"Using Client Consent Certificates" on page 152

Using the SSL Intercept Layer The SSL intercept layer allows you to set intercept options: ❐

"To intercept HTTPS content through VPM:" on page 156

❐

"To customize server certificate validation through VPM:" on page 158

For a list of policy conditions, properties, and actions, see “CPL in the SSL Intercept Layer” on page 159. Note: For detailed instructions on using VPM, refer to Volume 6: VPM and Advanced

Policy. To intercept HTTPS content through VPM: 1.

Go to Configuration > Policy > Visual Policy Manager and launch VPM.

2.

From the Policy drop-down menu, select Add SSL Intercept Layer.

3.

Right-click Set in the Action column; the Set Action object displays.

4.

Click New and select Enable HTTPS Intercept object or the Enable HTTPS Intercept on Exception object. The checkboxes for Issuer Keyring, Hostname, Splash Text, and Splash URL all control various aspects for certificate emulation. Fill in the fields as follows: a.

b.

Issuer Keyring: If you selected an issuer keyring previously, that keyring displays. If you did not select an issuer keyring previously, the default keyring displays. To change the keyring that is used as the issuer keyring, choose a different keyring from the drop-down menu. Hostname: The hostname you put here is the hostname in the emulated

certificate. c.

Splash Text: You are limited to a maximum of 200 characters. The splash text

is added to the emulated certificate as a certificate extension. d. Splash URL: The splash URL is added to the emulated certificate as a certificate extension. 5.

Click OK to save the changes.

You can use the Disable SSL Intercept object to disable HTTPS Intercept.

156

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy To categorize hostnames in server certificates through VPM: 1.

While still in the Destination column of the SSL Intercept layer, right-click Set; the Set Destination Object displays.

2.

Click New and highlight Server Certificate Category object. The Server Certificate Category Object displays. You can change the name in the top field if needed.

3.

Highlight the categories and click Add. The categories you selected display in the left-hand column.

4.

Click OK.

Using the SSL Access Layer The SSL Access layer allows you to set accessibility options: ❐

"To intercept HTTPS requests to specific sites through VPM:" on page 157

❐

"To customize server certificate validation through VPM:" on page 158

For a list of the conditions, properties, and actions that can be used in the SSL Access layer, see “CPL in the SSL Layer” on page 160. Note: For detailed instructions on using VPM, refer to Volume 6: VPM and Advanced

Policy. To intercept HTTPS requests to specific sites through VPM: 1.

Go to Configuration > Policy > Visual Policy Manager and launch VPM.

2.

From the Policy drop-down menu, select Add SSL Access Layer.

3.

In the Action column, right-click Set; the Set Action object displays.

157

Volume 2: Proxies and Proxy Services Section B: Configuring SSL Rules through Policy 4.

Click New and select Server Certificate.

5a 5b

5.

Fill in the fields as described below. Note that you can only choose one field: a.

Hostname: This is the hostname of the server whose traffic you want to

intercept. After entering the hostname, use the drop-down menu to specify Exact Match, Contains, At Beginning, At End, Domain, or Regex.

b.

Subject: This is the subject field in the server's certificate. After you enter the subject, use the drop-down menu to specify Exact Match, Contains, At Beginning, At End, Domain, or Regex.

To customize server certificate validation through VPM: Note: The policy property server.certificate.validate, if set, overrides the sslverify-server command for either HTTP or for forwarding hosts.

1.

Go to Configuration > Policy > Visual Policy Manager and launch VPM.

2.

From the Policy drop-down menu, select Add SSL Access Layer.

3.

In the Action column, right-click Set; the Set Action object displays.

4.

Click New and select Set Server Certificate Validation object.

5.

By default, server certificate validation is enabled; to disable it, select Disable server certificate validation at the bottom of the dialog.

158

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy If server certificate validation is enabled, you can determine behavior by selecting checkboxes to Ignore a hostname mismatch, Ignore certificate expiration, or Ignore untrusted issuer. These overrides mimic the overrides supported by most browsers. You can add server certificates to the SG appliance to allow proper validation. For more information, refer to Volume 4: Securing the Blue Coat SG Appliance. 6.

If you want to check the CA certificate revocation list (CRL) from a Certificate Authority, verify Also check certification revocation is selected. For information on using CRL, see “Checking CRLs” on page 146.

CPL in the SSL Intercept Layer Note: VPM is much easier to use than CPL. All CPL gestures except the ssl.forward_proxy.server_keyring property, used only for troubleshooting, are

also in VPM. The following CPL gestures can be used in the SSL Intercept layer: Note: No authentication-related triggers are allowed in the SSL Intercept layer.

Allowed Properties (allowed in the SSL Intercept layer only): • ssl.forward_proxy( )

• ssl.forward_proxy.splash_text( )

• ssl.forward_proxy.hostname( )

• trace.destination( )

• ssl.forward_proxy.issuer_keyring( )

• trace.request( )

• ssl.forward_proxy.server_keyring( )

• trace.rules( )

• ssl.forward_proxy.splash_url( )

• ssl.forward_proxy.server_keyring (used for troubleshooting only)

Allowed Actions • log_message( )

• notify_snmp( )

• notify_email( )

Allowed Conditions • category

• proxy.port

• client.address

• server.certificate.hostname

• client.host

• server.certificate.hostname.category

• client.host.has_name

• server.certificate.subject

159

Volume 2: Proxies and Proxy Services Section B: Configuring SSL Rules through Policy • client.protocol

• server_url.*

• proxy.address

• url.*

• proxy.card

An example of using CPL to intercept SSL traffic is: ;create list of servers to intercept define condition server_intercept_list server.certificate.hostname.category=webmail server.certificate.hostname=porn.com server.certificate.hostname.category=gambling server.certificate.hostname.category=none end condition server_intercept_list ; value no means tunnel, value https means intercept as forward proxy condition=server_intercept_list ssl.forward_proxy(https) ssl.forward_proxy(no) Note: For detailed instructions on using CPL, including detailed explanations of the gestures listed here, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide

CPL in the SSL Layer The following CPL gestures can be used in the SSL layer (called SSL Access layer in VPM): Allowed Actions (allowed in the SSL layer only) • server.certificate. validate(yes | no)

• server.certificate.validate. check_revocation (local | no))

• server.certificate. validate.ignore(hostname_ mismatch | expiration | untrusted _issuer)

• client.certificate. validate(yes | no)

• client.certificate.validate. check_revocation (local | no)

• client.certificate. require(yes)

Allowed Conditions and Properties • client.connection. negotiated_ssl_version = (condition)

• client.certificate. common_name.regex =

• client.certificate. subject.dn =

• client.certificate.common_ name[.exact|.substring| .prefix|.suffix] =

• client.certificate.subject [.exact|.substring| .prefix|.suffix|.regex] =

• client.certificate. subject.regex =

• server.certificate. hostname[.exact| .substring|.prefix|.suffix]=

• server.certificate. hostname.regex=

• server.certificate. hostname. category =

160

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy • server.certificate .hostname.category =! (condition)

• server.connection. negotiated_cipher =

• ssl.proxy_mode=

• client.protocol= tunneled=

• server.connection. negotiated_cipher.strength = low | medium | high | export

Note: For detailed instructions on using CPL, including detailed explanations of the

gestures listed here, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

Notes Note: Pipelining configuration for HTTP is ignored for HTTPS requests intercepted by

the SSL Proxy. When the SSL Proxy intercepts an HTTPS request, and the response is an HTML page with embedded images, the embedded images are not pre-fetched by the SG appliance. ❐

If the SG appliance and the origin content server cannot agree on a common cipher suite for intercepted connections, the connection is aborted.

❐

Server-Gated Cryptography and step-up certificates are treated just as regular certificates; special extensions present in these certificates are not be copied into the emulated certificate. Clients relying on SGC/step-up certificates continue using weaker ciphers between the client and the SG appliance when the SSL Proxy intercepts the traffic.

161

Volume 2: Proxies and Proxy Services Section C: Viewing SSL Statistics

Section C: Viewing SSL Statistics SSL History Statistics The SSL History tabs (Unintercepted SSL Data, Unintercepted SSL Clients, Unintercepted SSL Bytes) provide various useful statistics for unintercepted SSL traffic. Note: Some SSL statistics (SSL client connections and total bytes sent and received over a period of time) can only be viewed through the Management Console (see "Unintercepted SSL Data" on page 162 and "Unintercepted SSL Clients" on page 163, below).

Unintercepted SSL Data The Unintercepted SSL Data tab on the Management Console displays SSL statistics. The following table details the statistics provided through the Unintercepted SSL Data tab. Table 12-1. Unintercepted SSL Data Statistics Status

Description

Current Unintercepted SSL Sessions

The current number of unintercepted SSL client connections.

Total Unintercepted SSL Sessions

The cumulative number of unintercepted SSL client connections since the SG appliance was last rebooted.

Total Bytes Sent

The total number of unintercepted bytes sent.

Total Bytes Received

The total number of unintercepted bytes received.

To view unintercepted SSL data statistics: From the Management Console, select Statistics > Protocol Details > SSL History > Unintercepted SSL Data. The default view shows all unintercepted SSL data.

162

Chapter 12: Managing the SSL Proxy

Section C: Viewing SSL Statistics

Unintercepted SSL Clients The Unintercepted SSL Clients tab displays dynamic graphical statistics for connections received in the last 60-minute, 24-hour, or 30-day period. To view SSL client unintercepted statistics: 1.

From the Management Console, select Statistics > Protocol Details > SSL History > Unintercepted SSL Clients.

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Unintercepted SSL Bytes The Unintercepted SSL Bytes tab displays dynamic graphical statistics for bytes received in the last 60-minute, 24-hour, or 30-day period. To view unintercepted SSL byte statistics: 1.

From the Management Console, select Statistics > Protocol Details > SSL History > Unintercepted SSL Bytes.

163

Volume 2: Proxies and Proxy Services Section C: Viewing SSL Statistics

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

164

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics

Section D: Advanced Topics If you use OpenSSL or Active Directory, you can follow the procedures below to manage your certificates. For OpenSSL, see "Creating an Intermediate CA using OpenSSL" on page 165; if using Active Directory, see “Creating an Intermediate CA using Microsoft Server 2003 (Active Directory)” on page 167.

Creating an Intermediate CA using OpenSSL This section describes the certificate management when creating an intermediate CA using OpenSSL. The overall steps are: ❐

"Installing OpenSSL" on page 165

❐

"Creating a Root Certificate" on page 165

❐

"Modifying the OpenSSL.cnf File" on page 166

❐

"Signing the SG CSR" on page 166

❐

"Importing the Certificate into the SG Appliance" on page 167

❐

"Testing the Configuration" on page 167

Various OpenSSL distributions can be found at http://www.openssl.org.

Installing OpenSSL After OpenSSL is installed, you must edit the openssl.cnf file and ensure the pathnames are correct. By default root certificates are located under ./PEM/DemoCA; generated certificates are located under /certs.

Creating a Root Certificate In order to create a root Certificate Authority (CA) certificate, complete the following steps. Note: The key and certificate in this example is located at ./bin/PEM/demoCA/ private/.

1.

Open a MS-DOS window, and enter: openssl req -new -x509 -keyout c:\resources\ssl\openssl\bin\PEM\demoCA\private\ cakey.pem -out c:\resources\ssl\openssl\bin\PEM\demoCA\private\CAcert.pem

where the root directory for openssl is: \resources\ssl\openssl openssl req -new -x509 -keyout c:\resources\ssl\openssl\bin\PEM\demoCA\private\cakey.pem -out c:\resources\ssl\openssl\bin\PEM\demoCA\private\CAcert.pem Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf Loading 'screen' into random state - done Generating a 1024 bit RSA private key

165

Volume 2: Proxies and Proxy Services Section D: Advanced Topics .....................................+++++ ................................................+++++ writing new private key to 'c:\resources\ssl\openssl\bin\PEM\demoCA\private\cakey.pem' Enter PEM pass phrase:

2.

Type any string more than four characters for the PEM pass phrase.

3.

Enter the certificate parameters, such as country name, common name that are required for a Certificate Signing Request (CSR). The private key and root CA are now located under the directory ./PEM/DemoCA/ private

4.

Create a SG keyring. a.

5.

From the Management Console, select Configuration > SSL > Keyrings.

b.

Click Create; fill in the fields as appropriate.

c.

Click OK.

Create a CSR on the SG appliance. a.

From the Management Console, select Configuration > SSL > Keyrings.

b.

Highlight the keyring you just created; click Edit/View.

c.

In the Certificate Signing Request pane, click Create and fill in the fields as appropriate. Note: Detailed instructions on creating a keyring and a CSR are in Volume 4: Securing the Blue Coat SG Appliance. They can also be found in the online help.

6.

Paste the contents of the CSR into a text file called new.pem located in the ./bin directory.

Modifying the OpenSSL.cnf File Modify the openssl.cnf file to import the openSSL root CA into your browser. If you do not do this step, you must import he SG appliance certificate into the browser. 1.

In the openssl.cnf file, look for the string basicConstraints=CA, and set it to TRUE. basicConstraints=CA:TRUE

2.

Save the openSSL.cnf file.

Signing the SG CSR Open a MS-DOS window and enter: openssl ca -policy policy_anything -out newcert.pem -in new.pem

The output is: Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'FR' stateOrProvinceName :PRINTABLE:'Paris'

166

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics localityName :PRINTABLE:'Paris' organizationName :PRINTABLE:'BlueCoat' organizationalUnitName:PRINTABLE:'Security Team' commonName :PRINTABLE:'SG.bluecoat.com' emailAddress :IA5STRING:'[email protected]' Certificate is to be certified until Sep 27 13:29:09 2006 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

This signs the certificate; it can then be imported into the SG appliance.

Importing the Certificate into the SG Appliance 1.

Open the file newcert.pem in a text editor.

2.

Go to the Management Console > Configuration > SSL > SSL Keyrings.

3.

Selecting the keyring used for SSL interception; click Edit/View.

4.

Paste in the contents of the newcert.pem file.

5.

Import the contents of the newcert.pem file into the CA Certificates list. a.

From the Management Console, select Configuration > SSL > CA Certificates.

b.

Click Import; enter the certificate name in the CA Cert Name field.

c.

Paste the certificate, being sure to include the -----BEGIN CERTIFICATE---and the ----END CERTIFICATE----- statements in the ./bin/PEM/demoCA/ private/CAcert file.

d. Click OK. Note: Detailed instructions on importing a CA certificate are in Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121.

Testing the Configuration Import the root CA into your browser and construct an SSL interception policy. 9ta

Note: Detailed instructions on constructing an SSL interception policy are in “Configuring SSL Rules through Policy” on page 156.

You should not be prompted for any certificate warning.

Creating an Intermediate CA using Microsoft Server 2003 (Active Directory) This section describes certificate management when creating an intermediate CA using Active Directory. Before you begin: ❐

Make sure the Windows 2003 system is an Active Directory server.

❐

Make sure IIS is installed.

❐

Install the "Certificate Services" through the control panel

167

Volume 2: Proxies and Proxy Services Section D: Advanced Topics ❐

Select the mode to be Enterprise root CA.

All certificate management is done through the browser using the following URL: http://@ip_server/CertSrv You will complete the following steps: ❐

"To install the root CA onto the browser:" on page 168

❐

"To create a SG keyring and certificate signing request:" on page 168

❐

"To sign the SG CSR:" on page 168

❐

"To import the certificate onto the SG appliance:" on page 168

❐

"To test the configuration:" on page 169

To install the root CA onto the browser: 1.

Connect to HTTP://@ip_server/CertSrv

2.

Click Download a CA Certificate.

3.

Click Install this CA Certificate chain.

This installs the root CA onto the browser. To create a SG keyring and certificate signing request: 1.

From the Management Console, go to SSL > Keyrings.

2.

Create a new keyring. For detailed instructions on creating a new keyring, refer to Volume 4: Securing the Blue Coat SG Appliance.

3.

Create a Certificate Signing Request (CSR). For detailed instructions on creating a CSR, refer to Volume 4: Securing the Blue Coat SG Appliance.

4.

Click OK.

To sign the SG CSR: 1.

Connect to http://@ip_server/CertSrv

2.

Select the option Request a certificate.

3.

Select Submit an advanced certificate request and then Submit a certificate request by using a base 64 encoded …

4.

Paste the contents of the CSR.

5.

Select the Certificate Template Subordinate Certification Authority. If this template does not exist, connect to the certificate manager tool on the Active Directory server and add the template.

6.

Click on Submit.

7.

Download the certificate (not the chain) as Base 64 encoded.

8.

Save this file on the workstation as newcert.pem.

To import the certificate onto the SG appliance: 1.

Open the file newcert.pem in a text editor.

2.

In the Management Console, select Configuration > SSL > SSL Keyrings.

168

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics 3.

Select the keyring that has the CSR created; click Edit/View. Note: Make sure this keyring is used as the issuer keyring for emulated certificates. Use policy or the SSL intercept setting in the Management Console or the CLI.

4.

Paste the contents of the newcert.pem file.

5.

Import the contents of the newcert.pem file into the CA Certificates list. a.

From the Management Console, select Configuration > SSL > CA Certificates.

b.

Click Import; enter the certificate name in the CA Cert Name field.

c.

Paste the certificate, being sure to include the -----BEGIN CERTIFICATE---and the ----END CERTIFICATE----- statements in the ./bin/PEM/demoCA/ private/CAcert file.

d. Click OK. Note: Detailed instructions on importing a CA certificate are in Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 121.

To test the configuration: Import the root CA into your browser and construct a SSL interception policy. Note: Detailed instructions on constructing an SSL interception policy are in “Configuring SSL Rules through Policy” on page 156.

You should not be prompted for any certificate warning.

169

Volume 2: Proxies and Proxy Services Section D: Advanced Topics

170

Chapter 13: Managing the TCP Tunneling Proxy

Tunneling, or port forwarding, is a way to forward TCP traffic. Any application protocol running over TCP can be tunneled using this service. Client-server applications carry out any authentication procedures just as they do when TCP tunneling is not involved. SGOS uses a tcp:// scheme for TCP-tunnel transactions instead of HTTPS because SGOS does not actually know that it is HTTPS that is being tunneled. You can use ADN optimization in conjunction with TCP tunnels to compress and accelerate the tunneled traffic. Both explicit and transparent TCP tunneling are supported. Which one you use depends on your needs. ❐

Explicit TCP tunneling allows connections to one of the SG appliance's IP addresses.

❐

Transparent TCP tunneling allows connections to any IP address other than those belonging to the SG appliance. TCP tunneling in transparent mode supports categorization as well as blocking of destination IP address, port, host, and domain.

Note: The TCP-Tunnel service does not support content filtering with Websense offbox

or ICAP.

TCP-Tunnel Proxy Services Supported A number of proxy services are supported with the TCP-Tunnel proxy. For the most current list, see Table 3-1: "Proxy Name and Listeners" on page 24. In addition, the default proxy service (which listens on all ports not assigned to other services), uses the TCP-Tunnel proxy. The default proxy service has only one listener; its action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed. To keep the SG appliance from interfering with unassigned traffic, set the behavior to bypass. An access log entry is available for every TCP tunnel connection.

Creating or Editing a TCP-Tunnel Proxy Service 1.

Select Configuration > Services > Proxy Services.

2.

To edit a TCP-Tunnel proxy service, highlight the service and click Edit. To create a new proxy service, click New. Note: If you only want to change the proxy’s behavior from bypass (the default) to intercept, go to the Action column of the Proxy Services pane, select the service whose behavior you want to change, and select Intercept from the drop-down list. You do not need to enter New/Edit mode to change this attribute.

171

Volume 2: Proxies and Proxy Services

3 4

5

6

7b

7a

7c 7d

3. 4.

5.

In the Name field, choose a meaning name for the new proxy service. Configure the Proxy Settings options: a.

In the Proxy drop-down list, select TCP-tunnel.

b.

Select Detect Protocol checkbox to automatically detect the protocol being used. Note that this breaks connections that do not have the client send information first, but expect the server to respond on connection. It also can add significant delay if the client does not send specific information.

Configure TCP/IP options: a.

Reflect Client IP: Enables or disables sending of client's IP address instead of

the SG appliance's IP address. b.

Early intercept: Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

172

Chapter 13: Managing the TCP Tunneling Proxy

6.

7.

Configure ADN options: a.

Enable ADN. Select this checkbox if you want this service to use ADN. Note that enabling ADN does not guarantee the connections are accelerated by ADN. The actual enable decision is determined by ADN routing (for explicit deployment) and network setup (for transparent deployment).

b.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN optimization during initial configuration. You should de-select the checkbox if you are not configuring ADN optimization.

Create a new listener, a.

Click New.

b.

Define the IP address option: explicit or the specified address.

c.

In the Port Range field, enter the ports on which the service should listen. The default ports for each service are listed in Table 3-1. "Proxy Name and Listeners " on page 24.

d. Select the default action for the service: Bypass tells the service to ignore any traffic. Intercept configures the service to intercept the traffic that is being proxied. If you selected Optimize all other TCP traffic during initial configuration, all listeners in services that use the TCP-Tunnel proxy intercept traffic. If you did not select Optimize all other TCP traffic, TCP-Tunnel listeners bypass all traffic by default. e. 8.

Click OK.

Click Apply.

Related CLI Syntax to Create/Edit a Tunneling Proxy Service ❐

To enter configuration mode: SGOS#(config) proxy-services SGOS#(config proxy-services) create tcp-tunnel service-name SGOS#(config proxy-services) edit service-name

❐

The following subcommands are available: SGOS#(config service-name) add {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute {adn-optimize {enable | disable}| detect-protocol {enable | disable}| early-intercept {enable | disable}| reflect-client-ip {enable | disable} | use-adn {enable | disable}} SGOS#(config service-name) bypass {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove {transparent | explicit | all | ip_address | ip_address/subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

If you created a transparent TCP-Tunnel service, the procedure is complete. If you created an explicit TCP-Tunnel service, you must configure a forwarding destination port.

173

Volume 2: Proxies and Proxy Services To configure a forwarding destination port: 1.

Create a forwarding destination port, where the SG appliance directs traffic. SGOS#(config proxy-services tcp-tunnel) exit SGOS#(config proxy-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

174

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

AJAX

Acronym for Asynchronous JavaScript and XML, the technology used for live updating of Web pages without having to reload the entire page.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

175

Volume 2: Proxies and Proxy Services

audit

A log that provides a record of who accessed what and how.

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

176

Appendix A: Glossary

cache control

Allows you to configure which content the SG appliance stores.

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

177

Volume 2: Proxies and Proxy Services

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

178

Appendix A: Glossary

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

179

Volume 2: Proxies and Proxy Services

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: ICMP TCP SSL HTTP HTTPS Group Composite and reference to a composite result ICAP Websense DRTR rating service

health check type

The kind of device or service the specific health check tests. The following types are supported: Forwarding host and forwarding group SOCKS gateway and SOCKS gateway group CAP service and ICAP service group Websense off-box service and Websense off-box service group DRTR rating service User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

180

Appendix A: Glossary

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: Creating the list using the SG text editor Placing the list at an accessible URL Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

181

Volume 2: Proxies and Proxy Services

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

182

Appendix A: Glossary

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. Password provided, requests that include a client password. Data in request that include additional client data. Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

183

Volume 2: Proxies and Proxy Services

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: Client outbound: Packets sent to the client in response to a Web request. Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

184

Appendix A: Glossary

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

185

Volume 2: Proxies and Proxy Services

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: Mapi Proxy SSL Proxy

186

Appendix A: Glossary

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

187

Volume 2: Proxies and Proxy Services

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: Server inbound Server outbound Client inbound Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

188

Appendix A: Glossary

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

189

Volume 2: Proxies and Proxy Services

190

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

About the 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 SG appliance). It is also possible to configure the browser to download the proxy settings from a Web server. This is called a Proxy Auto-Configuration (PAC) file. When a user makes a request, the browser connects to the proxy service and sends the request. Because the browser knows it is talking to a proxy, the browser provides the proxy server with the destination server. The proxy service accepts the explicit connection to it, and fetches the request from the browser. The request identifies the desired origin content server (OCS) and the resource on that server. The proxy service uses this information to contact the OCS if necessary. The disadvantage to explicit proxy is that each desktop must be properly configured to use the proxy, which might not be feasible in a large organization. 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, refer to Volume 5: Advanced Networking.

About the Transparent Proxy When transparent proxy is enabled, the client (browser) does not know the traffic is being processed by a machine other than the OCS. The browser believes it is talking to the OCS, so the request is formatted for the OCS and the proxy determines for itself the destination server based on information in the request, such as the destination IP address in the packet, or the Host: header in the request. To enable the SG appliance 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 SG appliance, deploy hardware such as a Layer-4 switch or a WCCP router, or the SG 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 193.

191

Volume 2: Proxies and Proxy Services

For information on creating an explicit proxy server, regardless of proxy type, continue with “ Creating an Explicit Proxy Server” on page 192.

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. Two PAC files ship with the SG appliance: ❐

PAC file.

❐

Accelerated PAC file.

They can be accessed at: ❐

https://SG_IP_Address:8082/accelerated_pac_base.pac

❐

https://SG_IP_Address:8082/proxy_pac_file

They can be edited with any text editor. The SG appliance generates client instructions that describe how to configure Microsoft Internet Explorer, Netscape Communicator, and Firefox based on instructions selected by the SG administrator. You can configure client instructions for each network adapter in the SG appliance with the Configuration > Network > Adapters > Interface > Settings button. After selecting client instructions, the SG administrator directs clients to go to the SG home page and follow the instructions in the Browser Configuration section. The SG appliance detects the browser installed on the client and displays the appropriate instructions.

Using the SG Appliance as an Explicit Proxy To use the SG appliance 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 SG appliance 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 SG appliance which adapter interface uses the proxy IP address. Before the proxy can be used, you must: ❐

Configure the proxy server.

❐

Enable the explicit proxy (whether a service or a server).

The browsers described here are Internet Explorer 6.0 and Firefox 1.5. If you have different browsers or different versions of Internet Explorer or Firefox, refer to the vendor documentation for information on configuring proxies. From Internet Explorer: 1.

Select Tools > Internet Options > Connections > LAN Settings.

2.

Click Use a proxy server.

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.

192

Appendix B: Explicit and Transparent Proxy

From Firefox: 1.

Select Tools > Options > Genera l> Connection Settings.

2.

Click Manual proxy configuration.

3.

Enter proxy server IP addresses and port numbers for services such as HTTP, FTP, SOCKS, and SSL.

4.

Click OK.; click OK again.

Configuring Adapter Proxy Settings Once the explicit proxy is configured on the browser, decide which adapter interfaces listen for which service. Each adapter interface can listen for only one IP address; you can configure multiple proxies on one SG appliance using the same IP address. To provide configuration instructions on the SG appliance: 1.

Select Configuration > Network > Adapters.

2.

In the Adapter pane, select the adapter you want to use. If an adapter does not exist, the Adapter pane displays the word Empty.

3.

In the Interface pane, select the correct interface. Click Settings.

4.

Select Using a proxy.

5.

Click OK to close the Settings dialog.

Relevant CLI Syntax to Configure Adapter Proxy Settings SGOS#(config) interface fast-ethernet interface_#

Transparent Proxies A transparent proxy can be configured several ways: ❐

Through hardware: See “Configuring Transparent Proxy Hardware” on page 193.

❐

Through bridging: “Bridging” on page 194.

❐

Through using the SG appliance as a gateway: See “Configuring IP Forwarding” on page 195.

In addition to the transparent proxy configuration, you must create a proxy service for the transparent proxy and enable the service. At this time, you can also set other attributes for the service, including the destination IP address and port range. For information on creating or editing a proxy service for transparent configuration, see Chapter 3: "About Proxy Services" on page 23.

Configuring Transparent Proxy Hardware For transparent proxy to work, you must use one of the following: ❐

A bridge, either hardware or software

❐

Layer-4 switch

❐

WCCP

193

Volume 2: Proxies and Proxy Services

Bridging Network bridging through the SG appliance provides transparent proxy pass-through and failover support. This functionality allows SG appliances to be deployed in environments where L4 switches and WCCP-capable routers are not feasible options. The SG appliance 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. Note that 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. To set up a software bridge, refer to Volume 1: Getting Started.

❐

Hardware—The Blue Coat Pass-Through card is a 10/100 dual interface Ethernet device that enables a bridge, using its two adapters, so that packets can be forwarded across it. However, if the system crashes, the Pass-Through card becomes a network: the two Ethernet cables are connected so that traffic can continue to pass through without restriction. When the Pass-Through card is installed on the SG appliance, a bridge is automatically created and traffic going through the bridge is intercepted according to the proxy-service setting. Note that: •

Forwarding traffic behavior: By default, the bridge forwards packets that are not to be intercepted.

•

Proxy request behavior: Requests are proxied on either adapter, so if you connect one side of the bridge to your Internet connection, there might be a number of issues.

Configuring a Layer-4 Switch In transparent proxy acceleration, as traffic is sent to the origin content server, any traffic sent on port 80 is redirected to the SG appliance by the Layer 4 switch. The benefits to using a Layer 4 switch include: ❐

Built-in failover protection. In a multi-SG setup, if one appliance fails, the Layer 4 switch can route to the next SG appliance.

❐

Request partitioning based on IP address instead of on HTTP transparent proxying. (This feature is not available on all Layer 4 switches.)

❐

SG appliance bypass prevention. You can configure a Layer 4 device to always go through the SG appliance even for requests to a specific IP address.

❐

SG appliance bypass enabling. You can configure a Layer 4 device to never go through the SG appliance.

For information on configuring a layer-4 switch, refer to the manufacturer’s documentation.

194

Appendix B: Explicit and Transparent Proxy

Configuring a WCCP-Capable Router 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 SG appliances.

❐

Redirection safeguards—If no SG appliances are available, redirection stops and the router forwards traffic to the original destination address.

For information on using WCCP with a SG appliance, refer to Volume 5: Advanced Networking.

Configuring IP Forwarding IP Forwarding is a special type of transparent proxy. The SG appliance is configured to act as a gateway and is configured so that if a packet is addressed to the SG adapter, but not its IP address, the packet is forwarded toward the final destination. If IP forwarding is disabled, the packet is rejected as being mis-addressed. By default, IP forwarding is disabled to maintain a secure network. Important:

When IP forwarding is enabled, be aware that all SG ports are open and all the traffic coming through them is not subjected to policy, with the exception of the ports that have explicitly defined through the Configuration > Services > Proxy Services tab. To enable IP forwarding: 1.

Select Configuration > Network > Routing > Gateways.

2.

Select the Enable IP forwarding checkbox.

3.

Click OK; click Apply.

Related CLI Syntax to Enable IP Forwarding SGOS#(config) tcp-ip ip-forwarding enable

195

Volume 2: Proxies and Proxy Services

196

Index

A active client connections 107 ADN optimization attribute defined 28 Authenticate-401, attribute defined 27

B bandwidth gain additional configurations affecting 101 byte-range support effects 102 revalidate pragma-no-cache effects 103 bandwidth refresh, configuring 103 browser proxy, configuring 192 setting for explicit proxies 192 bypass list, overview 31 byte-range support bandwidth gain, affecting 102 configuring 102

C client consent certificates, using with SSL proxy 152

D destination IP address client trusted, configuring 37 trusting 37 DNS destination IP address, trusting 37 DNS proxy overview 59 resolving name list, explained 59 resource record, creating 61 document, conventions 10 dynamic bypass configuring 33 connection/receiving errors 33 dynamic_timeout value 33 lists, understanding 32 max_dynamic_bypass_entry parameter 33 server_bypass_threshold parameter 33 troubleshooting 32

dynamic_timeout value, using with dynamic bypass 33

E early intercept defined 27 explicit proxy browser settings 192 creating 192 Internet Explorer, using with 110 overview 191 SG appliance, using as proxy server 192 explicit TCP-Tunnel, explained 171

F FTP clients, configuring 82 spoofing 78 FTP proxy configuring 77 IP address 78 virtual IP address 78

H hardware models, licensing 38 HTTP proxy acceleration profile 96 bandwidth gain 101 bandwidth gain profile 97 byte-range support 102 normal profile 97 portal profile 97 pragma-no-cache, revalidating 103 profile settings configuring 100 explained 97 range request types 102 tolerant request parsing 104 traffic, controlling 96 HTTPS origination 125 HTTPS console creating 16 enabling 16 IP address, selecting 16

197

Volume 2: Proxies and Proxy Services

keyring, selecting 15 managing 16 HTTPS traffic, intercepting 148

I Internet Explorer, explicit proxy, using with 110 IP forwarding, enabling 195 issuer certificates, downloading for desktops 152

L license hardware models, limits 38 user limits, managing 38

M Management Console managing 13 SSH client keypairs, importing 19 configuring 18 Telnet console 21 max_dynamic_bypass_entry, using with dynamic bypass 33 meta tags, parsing 95 multiple listeners, best match 26

HTTPS console, creating 16 supported 13 Telnet console, creating 21 prompt, customizing for Telnet 133 proxies definition 9 explicit, browser settings 192 explicit, creating 192 interface settings 193 setting up 9 SOCKS, configuring 139 proxies, understanding 191 proxy server, using SG appliance as 192 proxy services, best-match algorithm 26 proxy-support header disabling through CPL 111 disabling through VPM 110 Internet Explorer, using with 110

R

O

range request types 102 realm banner, Telnet, customizing 133 refresh bandwidth, configuring 103 resolving name list, explained 59 restricted intercept CLI, using 36 understanding 35 revalidate pragma-no-cache bandwidth gain, using with 103 configuring 103 routing bypass list 31 policy-based bypass list 32

objects, served 106 origination, HTTPS 125

S

N Native FTP, understanding 77 NTLM explicit proxy, Internet Explorer, using with 110 Internet Explorer, using with 110

P PAC file, defined 192 Permeo customer ID, obtaining 141 PA client, about 140 PA license, disabling on SG appliance 142 PA limitations 142 SG appliance, PA licensing 141 policy bypass list 32 port services attributes 27 creating/editing 23

198

server_bypass_threshold, dynamic bypass, using with 33 shell proxies boundary conditions for 130 policy settings, customizing 129 See also Telnet Telnet 131 understanding 129 SOCKS compression gain statistics 143 connections, viewing 143 SOCKS clients, viewing 142 statistics 142

Index

SOCKS proxy bind timeout on accept value 140 configuring 139 connection timeout values 140 max-connection values 140 max-idle-timeout value 140 min-idle-timeout 140 SSH client keypairs, importing 19 managing 18 configuring 18 SSL proxy Add Server Certificate object, configuring 158 Add SSL Forward Proxy object, configuring 156 categorizing hostnames in server certificates 157 client consent certificates, using 152 explicit mode, configuring 151 HTTPS content, intercepting 156 traffic, intercepting 148 issuer certificates for desktops, downloading 152 rules, configuring 156 Server Certificate Category object, using 157 Set Server Certificate Validation object, using 158 SSL Access layer, using 157 SSL Intercept layer configuring through CPL 159 using 156 statistics unintercepted SSL byte 163 unintercepted SSL client 163 unintercepted SSL data 162 transparent mode, configuring 148 understanding 145 statistics active client connections 107 HTTP/FTP bytes served 107 objects served 106 SOCKS clients, viewing 142 SSL proxy unintercepted SSL bytes 163 unintercepted SSL clients 163 unintercepted SSL data 162

T TCP-Tunnel commands, explicit 174 explicit 171 overview 171 Telnet banner settings, configuring 133 proxy boundary conditions 135 settings, customizing 133 shell proxy creating service 131 understanding 131 Telnet console error message 21 port service, explained 21 troubleshooting 21 tolerant request parsing, setting through CLI 104 transparent proxy hardware, configuring 193 IP forwarding 195 IP forwarding, enabling 195 Layer-4 switch, using with 194 overview 191 troubleshooting explicit proxy and Internet Explorer 110 Telnet console 21 trust destination IP configuring behavior 41

U user license limits behavior if exceeded 39 concurrent users, viewing 41 configuring behavior 41 license metrics, viewing 39 managing 38 notifications, setting 39

W Web FTP troubleshooting 111 understanding 77 welcome banner, Telnet, customizing for 133

199

Volume 2: Proxies and Proxy Services

200

Blue Coat® Systems SG™ Appliance

Volume 3: Web Communication Proxies

SGOS Version 5.2.2

Volume 3: Web Communication Proxies

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected] Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02840 Document Revision: SGOS 5.2.2—09/2007

ii

Contents Contact Information Chapter 1: Introduction Document Conventions......................................................................................................................................7 Chapter 2: Managing Instant Messaging Protocols About the Risks of Instant Messaging..............................................................................................................9 About the Blue Coat IM Proxies........................................................................................................................9 HTTP Proxy Support ...................................................................................................................................9 Instant Messaging Proxy Authentication .................................................................................................9 Access Logging ...........................................................................................................................................10 Managing Skype.........................................................................................................................................10 About Instant Message Network Inter-activity ............................................................................................10 Recommended Deployments ...................................................................................................................10 About Instant Messaging Reflection .......................................................................................................11 Configuring SG Appliance IM Proxies...........................................................................................................13 Configuring IM Services ...........................................................................................................................14 Configuring IM DNS Redirection............................................................................................................17 The Default IM Hosts ................................................................................................................................18 Configuring Instant Messaging HTTP Handoff ....................................................................................18 Configuring IM Alerts ...............................................................................................................................19 Configuring IM Clients.....................................................................................................................................20 General Configuration...............................................................................................................................20 AOL Messenger Client Explicit Proxy Configuration ..........................................................................20 MSN Messenger Client Explicit Proxy Configuration..........................................................................22 Yahoo Messenger Client Explicit Proxy Configuration........................................................................23 Policy Examples.................................................................................................................................................24 Example 1: File Transfer............................................................................................................................24 Example 2: Send an IM Alert Message....................................................................................................26 Reference: Equivalent IM CLI Commands ....................................................................................................28 Reference: Access Log Fields ...........................................................................................................................28 Reference: CPL Triggers, Properties, and Actions .......................................................................................29 Triggers........................................................................................................................................................29 Properties and Actions ..............................................................................................................................29 IM History Statistics..........................................................................................................................................29 Chapter 3: Managing Streaming Media Section A: Concepts: Streaming Media About Streaming Media ...................................................................................................................................34 Supported Streaming Media Clients and Protocols .....................................................................................34

iii

Volume 3: Web Communication Proxies

Supported Streaming Media Clients and Servers ................................................................................. 34 Supported Streaming Protocols ............................................................................................................... 35 About Processing Streaming Media Content................................................................................................ 38 Delivery Methods ...................................................................................................................................... 38 Serving Content: Live Unicast ................................................................................................................. 38 Serving Content: Video-on-Demand Unicast ........................................................................................ 38 Serving Content: Multicast Streaming.................................................................................................... 38 About HTTP Handoff................................................................................................................................ 39 Limiting Bandwidth .................................................................................................................................. 39 Caching Behavior: Protocol Specific ....................................................................................................... 42 Caching Behavior: Video on Demand .................................................................................................... 42 Caching Behavior: Live Splitting ............................................................................................................. 42 Multiple Bit Rate Support......................................................................................................................... 43 Bitrate Thinning ......................................................................................................................................... 43 Pre-Populating Content ............................................................................................................................ 43 About Fast Streaming (Windows Media)............................................................................................... 44 About QoS Support ................................................................................................................................... 44 About Windows Media Over RTSP ............................................................................................................... 44 License Requirements ............................................................................................................................... 44 Upgrade/Downgrade Issues ................................................................................................................... 44 Management Console and CLI Changes ................................................................................................ 45 Supported Streaming Features ................................................................................................................ 45 Other Supported Features ........................................................................................................................ 46 Supported VPM Properties and Actions ................................................................................................ 46 Bandwidth Management .......................................................................................................................... 47 About Streaming Media Authentication ....................................................................................................... 47 Windows Media Server-Side Authentication ........................................................................................ 47 Windows Media Proxy Authentication.................................................................................................. 47 Real Media Proxy Authentication ........................................................................................................... 48 QuickTime Proxy Authentication ........................................................................................................... 48 Section B: Configuring Streaming Media Configuring Streaming Services ..................................................................................................................... 49 Configuring Streaming Proxies....................................................................................................................... 52 Limiting Bandwidth ......................................................................................................................................... 53 Configuring Bandwidth Limits—Global................................................................................................ 54 Configuring Bandwidth Limits—Protocol-Specific.............................................................................. 54 Configuring Bandwidth Limitation—Fast Start (WM) ........................................................................ 55 Configuring the SG Appliance Multicast Network ..................................................................................... 55 Configuring Media Server Authentication Type (Windows Media) ........................................................ 56 Related CLI Syntax to Manage Streaming..................................................................................................... 56 Reference: Access Log Fields........................................................................................................................... 57

iv

Contents

Reference: CPL Triggers, Properties, and Actions ....................................................................................... 58 Triggers........................................................................................................................................................ 58 Properties and Actions.............................................................................................................................. 58 Streaming History Statistics ............................................................................................................................ 58 Viewing Windows Media Statistics ........................................................................................................ 58 Viewing Real Media Statistics.................................................................................................................. 59 Viewing QuickTime Statistics .................................................................................................................. 60 Viewing Current and Total Streaming Data Statistics ......................................................................... 60 Viewing Streaming Bandwidth Gain...................................................................................................... 62 Section C: Additional Configuration Tasks—Windows Media (CLI) Managing Multicast Streaming for Windows Media .................................................................................. 63 About Multicast Stations .......................................................................................................................... 63 About Broadcast Aliases ........................................................................................................................... 64 Creating a Multicast Station ..................................................................................................................... 64 Monitoring the Multicast Station............................................................................................................. 66 Managing Simulated Live Content (Windows Media) ............................................................................... 67 About Simulated Live Content ................................................................................................................ 67 Creating a Broadcast Alias for Simulated Live Content ...................................................................... 68 ASX Rewriting (Windows Media).................................................................................................................. 69 About ASX Rewrite ................................................................................................................................... 69 Section D: Windows Media Player Configuring Windows Media Player ............................................................................................................. 72 Windows Media Player Inter-activity Notes ................................................................................................ 73 Striding ........................................................................................................................................................ 73 Other Notes................................................................................................................................................. 73 Section E: RealPlayer Configuring RealPlayer.................................................................................................................................... 75 Section F: QuickTime Player Configuring QuickTime Player....................................................................................................................... 79 Appendix A: Glossary Index

v

Volume 3: Web Communication Proxies

vi

Chapter 1: Introduction

A proxy filters traffic, monitors Internet and intranet resource usage, blocks or allows specific Internet and intranet resources for individuals or groups, and enhances the quality of Internet or intranet user experiences. The Blue Coat SG appliance Instant Messaging (IM) proxies allow you to control, track, and record communications that occur over AOL, MSN, or Yahoo IM clients on your corporate networks. The Streaming proxies allow you to alter allowed bandwidth and manage the broadcasts of streaming content over Microsoft and RealNetworks (with limited support for Apple) protocols. This document contains the following chapters: ❐

Chapter 2: "Managing Instant Messaging Protocols" on page 9

❐

Chapter 3: "Managing Streaming Media" on page 33

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

7

Volume 3: Web Communication Proxies

8

Chapter 2: Managing Instant Messaging Protocols

This chapter discusses how to control Instant Messaging (IM) activity through the SG appliance.

About the Risks of Instant Messaging Instant Messaging use in an enterprise environment creates security concerns because regardless of how network security is configured, IM connections can occur from any established protocol, such as HTTP or SOCKS, on any open port. Because it is common for coworkers to use IM to communicate, especially in remote offices, classified company information can be exposed outside the network. Viruses and other malicious code can also be introduced into the network from file sharing through IM clients.

About the Blue Coat IM Proxies The SG appliance serves as an IM proxy. With policy, you can control IM actions by allowing or denying IM communications and file sharing based on users (both employee identities and IM handles), groups, file types and names, and other triggers. All IM communications can be logged and archived for review. The SG appliance supports the AOL, MSN, and Yahoo IM client protocols. For the most current list of supported client versions, refer to the most current Release Notes for this release.

HTTP Proxy Support The SG appliance supports instant messaging through the HTTP proxy. IM clients are configured to connect to IM services through HTTP, which allows IM activity from behind restrictive firewalls. The application of policies and IM activity logging is accomplished by the HTTP proxy handing off IM communications to the IM proxy. Notes ❐

AOL and Yahoo clients lose certain features when connected through HTTP proxy rather than through SOCKS or transparent connections:

❐

AOL—Direct connections, file transfers, and files sharing are not available.

❐

Yahoo—Client cannot create a chat room.

Instant Messaging Proxy Authentication The SG appliance supports explicit proxy authentication if explicit SOCKS V5 proxy is specified in the IM client configuration. Because the IM protocols do not natively support proxy authentication, authentication for transparently redirected clients is not supported because policies requiring authentication would deny transparently redirected clients.

9

Volume 3: Web Communication Proxies

Notes Consider the following proxy authentication notes, which apply to IM clients using HTTP proxy: ❐

AOL IM—Proxy authentication is supported.

❐

MSN IM (5.0 and above)—The SG appliance supports MSN/Live Messenger if the appliance is configured to use HTTP ProxyAuth code 407, not HTTP auth code 401.

❐

Yahoo IM—Yahoo IM clients do not have proxy authentication configuration abilities.

Access Logging Access log entries occur from various IM actions, such as logging on or joining a chat room. By default, the SG appliance uses the Blue Coat IM access log format: date time c-ip cs-username cs-auth-group cs-protocol x-im-method x-imuser-id x-im-user-name x-im-user-state x-im-client-info x-im-buddy-id x-im-buddy-name x-im-buddy-state x-im-chat-room-id x-im-chat-room-type x-im-chat-room-members x-im-message-text x-im-message-size x-immessage-route x-im-message-type x-im-file-path x-im-file-size s-action

For a reference list and descriptions of used log fields, see “Reference: Access Log Fields” on page 28.

Managing Skype Skype is the most used IM service outside of the United States. It provides free PC-to-PC calling using VoIP. Skype communication is based on Peer-to-Peer technology. Managing Skype communications requires the creation of firewall and SG appliance policies, procedures that are outside the scope of this chapter. See the Blue Coat Controlling Skype Technical Brief, available on the Blue Coat Web site Download page.

About Instant Message Network Inter-activity This section discusses IM deployment and describes IM reflection, which is how the SG appliance policy dictates IM communications.

Recommended Deployments Blue Coat recommends the following deployments: ❐

For large networks with unimpeded Internet access, Blue Coat recommends transparently redirecting the IM protocols to the SG appliance, which requires the SG appliance bridging feature or an L4 switch or WCCP.

❐

For networks that do not allow outbound access, Blue Coat recommends using the SOCKS proxy and configuring policy and content filtering denials for HTTP requests to IM servers.

10

Chapter 2: Managing Instant Messaging Protocols

About Instant Messaging Reflection IM reflection allows you to contain IM traffic within the enterprise network, which further reduces the risk of exposing company-confidential information through public IM networks or allow a client to incur a virus or malicious code. Normally, an IM sent from one buddy to another is sent to and from an IM service. With IM reflection, IM traffic between buddies, including chat messaging, on the same network never has to travel beyond the SG appliance. This includes IM users who login to two different SG appliances configured in a hierarchy (proxy chaining).

IM Reflection with Fail Open When the SG appliance policy is configured to fail open, IM reflection operates essentially the same as passthrough mode. All messages are allowed in and out of the network. The following diagram illustrates IM processes with SG appliance fail open policy.

Figure 2-1. IM Reflection with SG appliance fail open policy.

IM Reflection With Fail Closed If the SG appliance is configured with fail closed policy, messages cannot leave the network (they never reach the IM service provider). Only clients on allowed enterprise networks can send and receive IMs. The following diagram illustrates IM processes with SG appliance fail closed policy.

11

Volume 3: Web Communication Proxies

Figure 2-2. IM Reflection with SG appliance fail close policy

IM Reflection With A Hierarchy Of Proxies While the previous two sections document the conceptual fail open/fail closed functionality, larger, more typical enterprise networks have users logging in through different primary SG appliance appliances. IM reflection involving clients in different buildings and even on different sites is still possible by using SOCKS and HTTP forwarding, policy, and an SG appliance hierarchy. The following diagram illustrates IM processes with SG appliance proxy chaining and a combination of fail open/fail closed policies.

12

Chapter 2: Managing Instant Messaging Protocols

Figure 2-3. Proxy chaining deployment with fail open/fail closed policies.

Configuring SG Appliance IM Proxies This chapter contains the following sections: ❐

“Configuring IM Services” on page 14

❐

“Configuring IM DNS Redirection” on page 17

❐

“The Default IM Hosts” on page 18

❐

“Configuring Instant Messaging HTTP Handoff” on page 18

❐

“Configuring IM Alerts” on page 19

13

Volume 3: Web Communication Proxies

Configuring IM Services Defaults: ❐

❐

Proxy Edition: Upon upgrade and on new systems, the SG appliance has IM services configured for transparent connections on the following ports: •

AOL-IM: 5190

•

MSN-IM: 1863 and 6891

•

Yahoo-IM: 5050 and 5101

MACH5 Edition: IM services are not created and are not included in trend data.

Notes: ❐

MSN port 1863 and Yahoo port 5050 are the default client login ports. MSN port 6891 and Yahoo port 5101 are the default for client-to-client direct connections and file transfers. If these ports are not enabled:

❐

Client-to-client direct connections do not occur.

❐

After a file transfer request is allowed by the SG appliance, the resulting data is sent directly from one client to another without passing through the SG appliance: •

For MSN: The above bullet point only applies to MSN version previous to and including 6.0. Post-6.0 versions use a dynamic port for file transfers; therefore, port 6891 is not required for the SG appliance to intercept file transfers.

•

For Yahoo: The above bullet only applies to standard file transfer requests. Port 5101 must be enabled to allow file list requests.

Note: All file transfers for AOL clients are handled through the default (5190) or specified client login port.

By default, these services are configured be Transparent and in Bypass mode. The following procedure describes how to change them to Intercept mode, and explains other attributes within the service. To configure the IM proxies services attributes: 1.

From the Management Console, select Configuration > Services > Proxy Services.

14

Chapter 2: Managing Instant Messaging Protocols

2

3

2.

Scroll the list of services to display the default one of the IM service lines (this example uses Yahoo). Notice the Action is Bypass. You can select Intercept from the drop-down list, but for the purposes of this procedures, select the service line to highlight it.

3.

Click Edit. The Edit Service dialog appears with the default settings displays.

15

Volume 3: Web Communication Proxies

4a

4b

4c

4.

Configure the service attributes: a.

In the Name field, enter a name that intuitively labels this service. This example accepts the default name.

b.

The TCP/IP Settings options allow you to manage the data connections:

c.

•

Reflect Client IP: If this is enabled, the connection to the IM server appears to come from the client, not the SG appliance.

•

Early Intercept: Not valid for this service.

In the Listeners field, select Intercept from the drop-down list; the SG appliance must intercept the IM connection. Perform this step for both ports

.

Note: You can also change the mode from Bypass to Intercept from the main

services page. d. Click OK. 5.

Click Apply.

Result: The IM service status appears in Management Console.

16

Chapter 2: Managing Instant Messaging Protocols

Figure 2-4. The Configured IM Listener

6.

(Optional) Configure AOL and MSN IM proxies to Intercept.

Now that the IM listeners are configured, you can configure the IM proxies.

Configuring IM DNS Redirection The SG appliance is configured as an IM proxy that performs a DNS redirection for client requests. This provides greater control because it prevents IM clients from making outside connections. The IM clients provide the DNS lookup to the IM server, which the SG appliance DNS module uses to connect to the IM server. To the client, the SG appliance appears to be the IM server. A virtual IP address used only for IM must be configured, as it is used to represent the IM server address for all IM protocols. To configure DNS redirection for IM: 1.

Select to Configuration > Network > Advanced > VIPs.

2b

2a

2.

3. 4.

Create a virtual IP address: a.

Click New. The Add Virtual IP dialog appears.

b.

Enter a unique IP address (used only to represent IM connections).

c.

Click OK to add the VIP to the list.

Click Apply. From the Management Console, select Configuration > Services > IM Proxies > IM Proxy Settings.

17

Volume 3: Web Communication Proxies

5.

In the General Settings field, select the VIP from the Explicit Proxy Virtual IP drop-down list.

6.

Click Apply.

Result: IM clients regard the SG appliance as the IM server. Remain on this screen and continue to the next section.

The Default IM Hosts Each IM client has hard-coded IM hosts. The SG appliance displays these values on the Configuration > Services > IM Proxies > IM Proxy Settings tab, which vary in number and fields dependent upon the selected IM protocol. Do not alter these hosts unless the client experiences a hard-coded change.

Configuring Instant Messaging HTTP Handoff HTTP handoff allows the Blue Coat HTTP proxy to handle requests from supported IM protocols. If HTTP handoff is disabled, requests are passed through, and IM-specific policies are not applied. Enable HTTP handoff if you create and apply IM policy. To allow a specific IM client to connect using the HTTP protocol through the SG appliance and that IM protocol has not been licensed, disable HTTP handoff to allow the traffic to be treated as plain HTTP traffic and to avoid an error in the licensing check performed by the IM module. This might be also be necessary to temporarily pass through traffic from new versions of IM clients that are not yet supported by Blue Coat. To enable HTTP handoff: 1.

From the Management Console, select Configuration > Services > IM Proxies > IM Proxy Settings.

2.

In the General Settings field, select Enable HTTP Handoff.

3.

Click Apply.

Result: IM-specific policies are applicable on IM communications.

18

Chapter 2: Managing Instant Messaging Protocols

Configuring IM Alerts A SG appliance IM alert is an IM message sent to clients upon an action triggered by policy. An IM alert contains two elements: ❐

Admin buddy names: You can assign an administrator buddy name for each client type. An administrator buddy name can be a registered name user handle or a fictitious handle. The benefit of using a registered name is that users can send IM messages to the administrator directly to report any issues, and that communication can be logged for tracking and record-keeping. By default, the SG appliance assigns each IM protocol the admin buddy name: Blue Coat SG appliance.

❐

Exception message delivery method: Alert messages can be delivered in the same window or spawn a new window.

To configure IM alert components: 1.

From the Management Console, select Configuration > Services > IM Proxies > IM Alert Settings.

2

3a

3b

2.

3.

In the Admin buddy names field, enter the handle or handles to represent the administrator. In this example, the company sanctions AOL Messenger as the one used for internal communications. IM alerts are sent from Example Corp IT. MSN and Yahoo are acceptable for personal use, but a created policy denies file transfers. Alerts are sent from Example Corp HR. Specify the exceptions message delivery method: a.

Send exception messages in a separate window (out-of-band)—If an exception occurs, the user receives the message in a separate IM window.

b.

Send exception messages in the existing window (in-band)—If an exception occurs, the message appears in the same IM window. The message appears to be sent by the buddy on the other end, with the exception that when in a chat room, the message always appears to be sent by the configured Admin buddy name. You can enter a prefix message that appears in the client window before the message. For example: Inappropriate IM use. Refer to Employee Conduct Handbook concerning Internet usage.

19

Volume 3: Web Communication Proxies

Note: Regardless of the IM exception delivery configuration, IM alert messages triggered by policy based on certain protocol methods are always sent out-ofband because a specific buddy is not associated.

4.

Click Apply.

SG appliance IM proxy configuration is complete. The final step is to configure IM clients to send traffic to the SG appliance.

Configuring IM Clients This section describes how to configure the IM clients to send traffic through the SG appliance.

General Configuration As each IM client has different menu structures, the procedures to configure them differ. This section provides the generic tasks that need to be completed.

Explicit Proxy Perform the following tasks on the IM client: 1.

Navigate to the Connection Preferences dialog.

2.

Select Use Proxies.

3.

Select proxy type as SOCKS V5.

4.

Enter the SG appliance IP address.

5.

Enter the SOCKS port number; the default is 1080.

6.

Enter authentication information, if required.

Transparent Proxy IM clients do not require any configuration changes for transparent proxy. An L4 switch or inline SG appliance routes the traffic.

AOL Messenger Client Explicit Proxy Configuration The following example configures a Yahoo Messenger client for explicit proxy. Note: This example uses AOL Messenger 5.9. Other versions might vary.

1.

Select My AIM > Edit Options > Edit Preferences.

20

Chapter 2: Managing Instant Messaging Protocols

3a 3b

2a 3c

3d 3e

2b

2.

3.

Navigate to Connection Preferences: a.

Select Sign On/Off.

b.

Click Connection.

Configure the proxy settings: a.

Select Connect using proxy.

b.

In the Host field, enter the SG appliance IP address. If the default port is 1080, accept it; if not, change it to port 1080.

c.

Select SOCKS 5.

d. If authentication is required on the SG appliance, enter the authentication user name and password. e. 4.

Click OK to close the Connections Preferences dialog.

Click OK to close the Preferences dialog. Result: the AOL client now sends traffic to the SG appliance.

21

Volume 3: Web Communication Proxies

MSN Messenger Client Explicit Proxy Configuration The following example configures a Yahoo Messenger client for explicit proxy. Note: This example uses MSN Messenger 7.5. Other versions might vary.

1.

From MSN Messenger, select Tools > Options.

3a

3b

2a

3c 2b

2.

3.

4.

Navigate to Settings: a.

Click Connection.

b.

Click Advanced Settings. The Settings dialog appears.

Configure the proxy settings: a.

In the SOCKS field, enter the SG appliance IP address. If the default port is 1080, accept it; if not, change it to port 1080.

b.

If authentication is required on the SG appliance, enter the authentication user name and password.

c.

Click OK.

Click OK to close the Options dialog. Result: the MSN client now sends traffic to the SG appliance.

22

Chapter 2: Managing Instant Messaging Protocols

Yahoo Messenger Client Explicit Proxy Configuration The following example configures a Yahoo Messenger client for explicit proxy. Note: This example uses Yahoo Messenger 7.0. Other versions might vary.

1.

From Yahoo Messenger, select Messenger > Preferences.

2b 2a 2d 2c

2e

2f

2.

Configure the following features: a.

Click Connection.

b.

Select Use proxies.

c.

Select Enable SOCKS proxy; select Ver 5.

d. Enter the SG appliance IP address. If the default port is 1080, accept it; if not, change it to port 1080. e.

If authentication is required on the SG appliance, enter the authentication user name and password.

f.

Click Apply and OK. Result: the Yahoo client now sends traffic to the SG appliance.

Notes If Yahoo Messenger is configured for explicit proxy (SOCKS) through the SG appliance, the IM voice chat feature is disabled. Any client attempting a voice chat with a client behind the SG appliance firewall receives an error message. The voice data stream is carried by default on port 5001; therefore, you can create and open this port and configure Yahoo IM to use transparent proxy. However, the SG appliance only supports the voice data in pass-through mode.

23

Volume 3: Web Communication Proxies

Policy Examples After the IM clients are configured to send traffic through the SG appliance, you can control and limit IM activity. The Visual Policy Manager (VPM) allows you to create rules that control and track IM communications, including IM activities based on users and groups, IM handle, chat room handle, file name, and other triggers. To learn about the VPM, refer to Volume 7: VPM and Advanced Policy.

Example 1: File Transfer The following example demonstrates an IM rule created with the VPM that IM handle Nigel1 can perform a file transfer at any time, but the file must be between 1 and 5 MB in size, and the handle, the file path, and file size are logged.

1

2a

2c

2b

1.

In the VPM, select Policy > Add Web Access Layer; name it IM_File_Transfer.

2.

Create a new IM user object: a.

Right-click the Source field; select Set. The Set Source Object dialog appears.

b.

Click New; select IM User. The Add IM User Object dialog appears.

c.

In the IM User field, enter Nigel1; click OK in each dialog.

24

Chapter 2: Managing Instant Messaging Protocols

3a

3c

3b

3.

Create a File Transfer object: a.

Right-click the Service field; select Set. The Set Service Object dialog appears.

b.

Click New; select IM File Transfer. The Add IM File Transfer dialog appears.

c.

Select Size and enter a range 1 and 5.

d. Select MBytes from the drop-down list; click OK in each dialog. 4.

Right-click the Track field; select Set. The Add Track Object dialog appears.

5.

Click New; select Event Log. The Add Event Log Object dialog appears.

25

Volume 3: Web Communication Proxies

6

6.

From the Substitution Variables list, select x-im-buddy-name and click insert. Repeat for x-im-file-path and x-im-file-size. Click OK in each dialog.

7

7.

In the VPM, click Install Policy.

Example 2: Send an IM Alert Message The following example demonstrates a rule created with the VPM that informs all IM users when they login that their IM activity is tracked and logged. 1.

In the VPM, select Policy > Add Web Access Layer; name it IM_NotifyMessage.

2.

Right-click the Service field; select Set. The Set Service Object dialog appears.

3.

Click New; select Protocol Methods. The Add Methods Object dialog appears.

26

Chapter 2: Managing Instant Messaging Protocols

2a 2b

4.

Configure protocol method options: a.

From the Protocol drop-down list, select Instant Messaging.

b.

Click Login/Logout; LOGIN; click OK to close the dialog; click OK to insert the object in the rule.

c.

Click OK in each dialog.

5.

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

6.

Click New; select Send IM Alert. The Add Send IM Alert Object dialog appears.

7

7.

In the Alert Text field, enter a message that appears to users. For example, Employee notice: Your Instant Messaging activity is tracked and logged.

8.

Click OK to close the dialog; click OK to insert the object in the rule.

9.

Click Install Policy.

27

Volume 3: Web Communication Proxies

Reference: Equivalent IM CLI Commands The configuration tasks describes in this chapter can also be accomplished through the SG appliance CLI. The following are the equivalent CLI command syntaxes: ❐

To enter configuration mode: SGOS#(config) proxy-services SGOS#(config proxy-services) create {aol-im | msn-im | yahoo-im} service_name

❐

The following submodes are available: SGOS#(config proxy-services) edit service-name SGOS#(config service-name) add all | ip_address | ip_address/subnetmask} {port | first_port-last_port} [intercept | bypass] SGOS#(config service-name) attribute reflect-client-ip {enable | disable} SGOS#(config service-name) bypass all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) exit SGOS#(config service-name) intercept all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) remove all | ip_address | ip_address/ subnet-mask} {port | first_port-last_port} SGOS#(config service-name) view

Reference: Access Log Fields The default Blue Coat IM fields are (only IM-specific or relative are listed and described): ❐

cs-protocol: Protocol used in the client's request.

❐

x-im-method: The method associated with the instant message.

❐

x-im-user-id: Instant messaging user identifier.

❐

x-im-user-name: Display name of the client.

❐

x-im-user-state: Instant messaging user state.

❐

x-im-client-info: The instant messaging client information.

❐

x-im-buddy-id: Instant messaging buddy ID.

❐

x-im-buddy-name: Instant messaging buddy display name.

❐

x-im-buddy-state: Instant messaging buddy state

❐

x-im-chat-room-id: Instant messaging identifier of the chat room in use.

❐

x-im-chat-room-type: The chat room type, one of public or public, and possibly invite_only, voice and/or conference.

❐

x-im-chat-room-members: The list of chat room member IDs.

❐

x-im-message-text: Text of the instant message.

❐

x-im-message-size: Length of the instant message

❐

x-im-message-route: The route of the instance message.

❐

x-im-message-type: The type of the instant message.

❐

x-im-file-path: Path of the file associated with an instant message.

28

Chapter 2: Managing Instant Messaging Protocols

❐

x-im-file-size: Size of the file (in...?) associated with an instant message.

Reference: CPL Triggers, Properties, and Actions The following Blue Coat CPL is supported for IM:

Triggers ❐

im.buddy=

❐

im.chat_room.conference=

❐

im.chat_room.id=

❐

im.chat_room.invite_only=

❐

im.chat_room.type=

❐

im.chat_room.member=

❐

im.chat_room.voice_enabled=

❐

im.client=

❐

im.file.extension=

❐

im.file.name=

❐

im.file.path=

❐

im.file.size=

❐

im.message.opcode=

❐

im.message.reflected=

❐

im.message.route=

❐

im.message.size=

❐

im.message.text=

❐

im.message.type=

❐

im.method=

❐

im.user_agent=

❐

im.user_id=

Properties and Actions ❐

im.block_encryptions()

❐

im.reflect()

❐

im.strip_attachments()

❐

im.transport()

❐

im.alert()

IM History Statistics The IM statistics allow you to track IM connections, file transfers, and messages that are currently in use and in total, or have been allowed and denied. The information can be displayed for each IM client type or combined.

29

Volume 3: Web Communication Proxies

IM Connection Data Tab The following IM Connection Data statistics indicate current and overall connection data since the last statistics clear: ❐

Native Clients—The number of native IM clients connected.

❐

HTTP Clients—The number of HTTP IM clients connected.

❐

Chat Sessions—The number of IM chats occurring.

❐

Direct IM Sessions—The number of chats using direct connections.

❐

File Transfers—The number of file transfers sent through IM clients.

To view the connection data statistics: 1.

Select Statistics > Protocol Details > IM History > IM Connection Data.

2.

The default protocol is All. To select a specific protocol, select AOL, MSN, or Yahoo from the drop-down list.

IM Activity Data Tab The following IM Activity Data statistics indicate allowed and denied connections since the last statistics clear: ❐

Logins—The number of times IM clients have logged in.

❐

Messages—The number of IM messages.

❐

File Transfers—The number of file transfers sent through IM clients.

❐

Voice Chats—The number of voice conversations through IM clients.

❐

Messages—The number of IM messages reflected or not reflected (if IM Reflection

policy is enabled). Note: The IM activity data statistics are available only through the Management Console.

To view the activity data statistics: 1.

Select Statistics > Protocol Details > IM History > IM Activity Data.

30

Chapter 2: Managing Instant Messaging Protocols

2.

The default protocol is All. To select a specific protocol, select AOL, MSN, or Yahoo from the drop-down list.

IM Clients Tab The IM Clients tab displays dynamic graphical statistics for connections over 60 minutes, 24 hours and 30 days. The page displays all values in the graph or clip a percentage of peak values. When peak values are clipped by a percentage, that percentage is allowed to fall off the top of the scale. For example, if you clip 25% of the peaks, the top 25% of the values are allowed to exceed the scale for the graph, showing greater detail for the remaining 75% of the values. Move the cursor over the graphs to dynamically display the color-coded AOL, MSN, Yahoo, and total statistics. Note: The IM clients statistics are available only through the Management Console.

To view the client connection statistics: 1.

Select Statistics > Protocol Details > IM History > IM Clients.

31

Volume 3: Web Communication Proxies

2.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

32

Chapter 3: Managing Streaming Media

This chapter contains the following sections: ❐

"Section A: Concepts: Streaming Media"—Provides streaming media terminology and Blue Coat streaming solution concepts.

❐

"Section B: Configuring Streaming Media"—Provides feature-related concepts and procedures for configuring the SG to manage streaming media applications and bandwidth.

❐

"Section C: Additional Configuration Tasks—Windows Media (CLI)"—Provides procedures that can only be performed through the CLI, not the Management Console.

❐

"Section D: Windows Media Player"—Describes how to configure the Windows Media client and describes associated interactivities and access log conventions.

❐

"Section E: RealPlayer"—Describes how to configure the Real Media client and describes associated interactivities and access log conventions.

❐

"Section F: QuickTime Player"—Describes how to configure the QuickTime client and describes associated interactivities and access log conventions.

33

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media

Section A: Concepts: Streaming Media This section contains the following topics: ❐

"About Streaming Media" on page 34

❐

"Supported Streaming Media Clients and Protocols" on page 34

❐

"About Processing Streaming Media Content" on page 38

❐

"About Streaming Media Authentication" on page 47

About Streaming Media Streaming is a method of content delivery. With media streaming, video and audio are delivered over the Internet rather than the user having to wait for an entire file to be downloaded before it can be played. Streaming media support on the SG appliance provides the following features: ❐

Streaming media files can be live or prerecorded.

❐

Employs flexible delivery methods: unicast, multicast, HTTP, TCP, and UDP.

❐

Ability to seek, fast-forward, reverse, and pause.

❐

Ability to play entire file and control media playback, even before it is downloaded.

❐

Adjust media delivery to available bandwidth, including multi-bit-rate and thinning support.

Supported Streaming Media Clients and Protocols This section describes the vendor-specific streaming protocols supported by the SG appliance.

Supported Streaming Media Clients and Servers The SG appliance supports Microsoft Windows Media, RealNetworks RealPlayer, and Apple QuickTime; however, the various players might experience unexpected behavior dependent upon certain SGOS configurations and features. Feature sections list such interactivities, as necessary. For a list of the most current versions of each supported client, refer to the Blue Coat SGOS Release Notes for this release.

Supported Windows Media Players and Servers The SG appliance supports the following versions and formats: ❐

Windows Media Player

❐

Windows Media Server

34

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media

Supported Real Media Players and Servers The SG appliance supports the following versions: ❐

RealOne Player

❐

RealPlayer

❐

RealServer

❐

Helix Universal Server Note: Blue Coat recommends not deploying a Helix proxy between the SG appliance and a Helix server where the Helix proxy is the parent to the SG appliance. This causes errors with the Helix server. The reverse is acceptable (using a Helix proxy as a child to the SG appliance).

Supported QuickTime Players and Servers The SG appliance supports the following versions, but in pass-through mode only: ❐

QuickTime Player

❐

Darwin Streaming Server

❐

Helix Universal Server

Supported Streaming Protocols Each streaming media platform supports their own set of protocols. This section describes the protocols the SG appliance supports.

Windows Media Protocols The SG appliance supports the following protocols: ❐

MMS-UDP (Microsoft Media Streaming—User Data Protocol)

❐

MMS-TCP (Microsoft Media Streaming—Transmission Control Protocol)

❐

HTTP streaming.

❐

All protocols between the client and the SG appliance for video-on-demand and live unicast content.

❐

MMS-TCP and HTTP streaming between the SG appliance and origin server for video-on-demand and live unicast content.

❐

Multicast-UDP is the only delivery protocol supported for multicast. No TCP control connection exists for multicast delivery.

The following briefly describes each of the supported delivery protocols: ❐

MMS-UDP—UDP provides the most efficient network throughput from server to client. The disadvantage to UDP is that many network administrators close their firewalls to UDP traffic, limiting the potential audience for Multicast-UDP-based streams.

35

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media The Windows Media Player attempts to connect in the following order: •

Multicast session. Multicast-UDP uses a TCP connection for control messages and UDP for streaming data. TCP provides packet receipt acknowledgement back to the sender. This insures control message delivery.

•

MMS-TCP session. If an MMS-UDP session cannot be established, the client falls back to MMS-TCP automatically.

The SG appliance then establishes a connection to the origin server running the Microsoft Windows Media service. ❐

MMS-TCP—TCP provides a reliable protocol for delivering streaming media content from a server to a client. At the expense of less efficiency compared to MMS-UDP data transfer, MMS-TCP provides a reliable method for streaming content from the origin server to the SG appliance. Note: The MMS protocol is usually referred to as either MMS-TCP or MMS-UDP depending on whether TCP or UDP is used as the transport layer for sending streaming data packets. MMS-UDP uses a TCP connection for sending and receiving media control messages, and a UDP connection for streaming the actual media data. MMS-TCP uses TCP connections to send both control and data messages.

❐

HTTP Streaming—The Windows Media server also supports HTTP-based media control commands along with TCP-based streaming data delivery. This combination has the benefit of working with all firewalls that let only Web traffic through (port 80).

Depending on the configuration, if MMS-UDP is used between the SG appliance and the client, the appliance can use MMS-TCP, HTTP, or multicast-UDP as the connection to the media server. No protocol relationship exists between the SG appliance and the media server, or between the SG appliance and the client.

Windows Media Over RTSP The SG appliance supports Windows Media content streamed over RTSP. The following Windows Media RTSP transports are supported: Client-side ❐

RTP over unicast UDP (RTSP over TCP, RTP over unicast UDP)

❐

Interleaved RTSP (RTSP over TCP, RTP over TCP on the same connection)

❐

RTP over multicast UDP (RTP over multicast UDP; for live content only)

Server-side ❐

Interleaved RTSP

Server-side RTP over UDP is not supported. If policy directs the RTSP proxy to use HTTP as server-side transport, the proxy denies the client request. The client then rolls over to MMS or HTTP.

36

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media

Real Media Protocols The SG appliance supports the following Real Media protocols: Client-Side ❐

RDT over unicast UDP (RTSP over TCP, RDT over unicast UDP)

❐

Interleaved RTSP (RTSP over TCP, RDT over TCP on the same connection)

❐

RDT over multicast UDP (RTSP over TCP, RDT over multicast UDP; for live content only)

❐

HTTP streaming (RTSP and RDT over TCP tunneled through HTTP)—HTTP streaming is supported through a handoff process from HTTP to RTSP. HTTP accepts the connection and, based on the headers, hands off to RTSP. The headers identify an RTSP URL.

Server-Side ❐

Interleaved RTSP

❐

HTTP streaming

Unsupported Protocols The following Real Media protocols are not supported in this version of SGOS: ❐

PNA.

❐

Server-side RDT/UDP (both unicast and multicast).

QuickTime Protocols The SG appliance supports the following protocols: ❐

RTP over unicast UDP (RTSP over TCP, RDT over unicast UDP)

❐

Interleaved RTSP (RTSP over TCP, RDT over TCP on the same connection)

❐

HTTP streaming (RTSP and RDT over TCP tunneled through HTTP)—HTTP streaming is supported through a handoff process from HTTP to RTSP. HTTP accepts the connection and, based on the headers, hands off to RTSP. The headers identify an RTSP URL.

Server-Side ❐

Interleaved RTSP

❐

HTTP streaming

Unsupported Protocols The following QuickTime protocols are not supported in this version of SGOS: ❐

Server-side RTP/UDP, both unicast and multicast, is not supported.

❐

Client-side multicast is not supported.

37

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media

About Processing Streaming Media Content The following sections describe how the SG appliance processes, stores, and serves streaming media requests. Using the SG appliance for streaming delivery minimizes bandwidth use by allowing the SG appliance to handle the broadcast and allows for policy enforcement over streaming use. The delivery method depends on if the content is live or video-on-demand.

Delivery Methods The SG appliance supports the following streaming delivery methods: ❐

Unicast—A one-to-one transmission, where each client connects individually to the source, and a separate copy of data is delivered from the source to each client that requests it. Unicast supports both TCP- and UDP-based protocols. The majority of streaming media traffic on the Internet is unicast.

❐

Multicast—Allows efficient delivery of streaming content to a large number of users. Multicast enables hundreds or thousands of clients to play a single stream, thus minimizing bandwidth use.

The SG appliance provides caching, splitting, and multicast functionality.

Serving Content: Live Unicast An SG appliance can serve many clients through one unicast connection by receiving the content from the origin server and then splitting that stream to the clients that request it. This method saves server-side bandwidth and reduces the server load. You cannot pause or rewind live broadcasts. A live broadcast can be of prerecorded content. A common example is a company president making a speech to all employees.

Serving Content: Video-on-Demand Unicast An SG appliance can store frequently requested data and distribute it upon client requests. Because the SG appliance is closer to the client than the origin server, the data is served locally, which saves firewall bandwidth and increases quality of service by reducing pauses or buffering during playback. The SG appliance provides higher quality streams (also dependent on the client connection rate) than the origin server because of its closer proximity to the end user. VOD content can be paused, rewound, and played back. Common examples include training videos or news broadcasts.

Serving Content: Multicast Streaming This section describes multicast streaming and how to configure the SG appliance to manage multicast broadcasts.

About Multicast Content The SG appliance can take a unicast stream from the OCS and deliver it as a multicast broadcast. This enables the SG appliance to take a one-to-one stream and split it into a one-to-many stream, saving bandwidth and reducing the server load. It also produces a higher quality broadcast. For Windows Media multicast, an NSC file is downloaded through HTTP to acquire the control information required to set up content delivery.

38

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media For Real Media and QuickTime (through RTSP), multicasting maintains a TCP control (accounting) channel between the client and media server. The multicast data stream is broadcast using UDP from the SG appliance to streaming clients, who join the multicast.

About Serving Multicast Content The SG appliance takes a multicast stream from the origin server and delivers it as a unicast stream. This avoids the main disadvantage of multicasting—that all of the routers on the network must be multicast-enabled to accept a multicast stream. Unicast-tomulticast, multicast-to-multicast, and broadcast alias-(scheduled live from stored content)-to-multicast are also supported.

Multicast to Unicast Live Conversion at the SG Appliance The SG appliance supports converting multicast streams from an origin content server to unicast streams. The stream at the SG appliance is given the appropriate unicast headers to allow the appliance to direct one copy of the content to each user on the network. Multicast streaming only uses UDP protocol and does not know about the control channel, which transfers essential file information. The .nsc file (a file created off-line that contains this essential information) is retrieved at the beginning of a multicast session from an HTTP server. The multicast-alias command specifies an alias to the URL to receive this .nsc file. The converted unicast stream can use any of the protocols supported by Windows Media and Real Media, including HTTP streaming. When a client requests the alias content, the SG uses the URL specified in the multicastalias command to fetch the .nsc file from the HTTP server. The .nsc file contains all of the multicast-related information, such as addresses and .asf file header information that is normally exchanged through the control connection for unicast-delivered content. Note: For Windows Media steaming clients, additional multicast information is provided in “ Managing Multicast Streaming for Windows Media” on page 63.

About HTTP Handoff When a Windows Media, Real Media, or QuickTime client requests a stream from the SG appliance over port 80, which in common deployments is the only port allowing traffic through a firewall, the HTTP module passes control to the streaming module so HTTP streaming can be supported through the HTTP proxy port.

Limiting Bandwidth The following sections describe bandwidth limitation and how to configure the SG to limit global and protocol-specific media bandwidth. Streaming media bandwidth management is achieved by configuring the SG appliance to restrict the total number of bits per second the appliance receives from the origin media servers and delivers to clients. The configuration options are flexible to allow you to configure streaming bandwidth limits for the SG appliance, as well as for each streaming protocol (Windows Media, Real Media, and QuickTime).

39

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media

Note: Bandwidth claimed by HTTP, non-streaming protocols, and network infrastructure is not constrained by this limit. Transient bursts that occur on the network can exceed the hard limits established by the bandwidth limit options.

After it has been configured, the SG appliance limits streaming access to the specified threshold. If a client tries to make a request after a limit has been reached, the client receives an error message. Note: If a maximum bandwidth limitation has been specified for the SG appliance, the

following condition can occur. If a Real Media client, followed by a Windows Media client, requests streams through the same SG appliance and total bandwidth exceeds the maximum allowance, the Real Media client enters the rebuffering state. The Windows Media client continues to stream.

40

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media Consider the following features when planning to limit streaming media bandwidth: ❐

SG appliance to server (all protocols)—The total kilobits per second allowed between the appliance and any origin content server or upstream proxy for all streaming protocols. Setting this option to 0 effectively prevents the SG appliance from initiating any connections to the media server. The SG appliance supports partial caching in that no bandwidth is consumed if portions of the media content are stored in the SG appliance.

❐

Client to SG appliance (all protocols)—The total kilobits per second allowed between streaming clients and the SG. Setting this option to 0 effectively prevents any streaming clients from initiating connections through the SG appliance.

❐

SG appliance to server—The total kilobits per second allowed between the Appliance and the media server. Setting this option to 0 effectively prevents the SG appliance from accepting media content. Limiting SG appliance bandwidth restricts the following streaming media-related functions:

❐

•

Live and video-on-demand media, the sum of all bit rates

•

Limits the ability to fetch new data for an object that is partially cached

•

Reception of multicast streams

Client to SG appliance—The total kilobits per second allowed between Windows Media streaming media clients and the SG appliance. Setting this option to 0 effectively prevents streaming clients from making connections to the SG appliance. Limiting server bandwidth restricts the following streaming media-related functions:

❐

•

MBR is supported; the SG appliance assumes the client is using the maximum bit rate

•

Limits the transmission of multicast streams

Client connections—The total number of clients that can connect concurrently. When this limit is reached, clients attempting to connect receive an error message and are not allowed to connect until other clients disconnect. Setting this variable to 0 effectively prevents any streaming media clients from connecting.

Selecting a Method to Limit Streaming Bandwidth You can control streaming bandwidth using two different methods: you can use the streaming features described in “Limiting Bandwidth” on page 39, or you can use the bandwidth management features described in Volume 6: Advanced Networking. Do not, however, use both methods to control streaming bandwidth. The way that each method controls bandwidth differs—read the information below to decide which method best suits your deployment requirements. Limiting streaming bandwidth using the streaming features (described in this chapter) works this way: if a new stream comes in that pushes above the specified bandwidth limit, that new stream is denied. This allows existing streams to continue to get the same level of quality they currently receive. Limiting streaming bandwidth using the bandwidth management features works this way: all streaming traffic for which you have configured a bandwidth limit shares that limit. If a new stream comes in that pushes above the specified bandwidth limit, that stream is allowed, and the amount of bandwidth available for existing streams is reduced.

41

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media This causes streaming players to drop to a lower bandwidth version of the stream. If a lower bandwidth version of the stream is not available, players that are not receiving enough bandwidth can behave in an unpredictable fashion. In other words, if the amount of bandwidth is insufficient to service all of the streams, some or all of the media players experience a reduction in stream quality. For most circumstances, Blue Coat recommends that you use the streaming features to control streaming bandwidth rather than the bandwidth management features.

Caching Behavior: Protocol Specific This section describes what is cached for each supported protocol.

Windows Media The SG appliance caches Windows Media-encoded video and audio files. The standard extensions for these file types are: .wmv, .wma, and .asf.

Real Media The SG appliance caches Real Media-encoded files, such as RealVideo and RealAudio. The standard extensions for these file types are: .ra, .rm, and .rmvb. Other content served from a Real Media server through RTSP is also supported, but it is not cached. This content is served in pass-through mode only.

QuickTime The SG appliance does not cache QuickTime content (.mov files). All QuickTime content is served in pass-through mode only.

Caching Behavior: Video on Demand The SG appliance supports the caching of files for VOD streaming. First, the client connects to the SG appliance, which in turn connects to the origin server and pulls the content, storing it locally. Subsequent requests are served from the SG appliance. This provides bandwidth savings, as every hit to the SG appliance means less network traffic. Blue Coat also supports partial caching of streams .

Note: On-demand files must be unicast.

Caching Behavior: Live Splitting The SG appliance supports splitting of live content, but behavior varies depending upon the media type. For live streams, the SG appliance can split streams for clients that request the same stream. First, the client connects to the SG appliance, which then connects to the origin server and requests the live stream. Subsequent requests are split from the appliance. Two streams are considered identical by the SG appliance if they share the following characteristics: ❐

The stream is a live or broadcast stream.

❐

The URL of the stream requested by client is identical.

❐

MMS, MMSU, MMST, and HTTP are considered as identical.

42

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media

Note: If the URL is composed of host names instead of IP addresses, splitting does not occur across WMP 7.0 clients.

Splitting of live unicast streams provides bandwidth savings, since subsequent requests do not increase network traffic.

Multiple Bit Rate Support The SG appliance supports multiple bit rate (MBR), which is the capability of a single stream to deliver multiple bit rates to clients requesting content from caches from within varying levels of network conditions (such as different connecting bandwidths and traffic). This allows the SG appliance and the client to negotiate the optimal stream quality for the available bandwidth even when the network conditions are bad. MBR increases client-side streaming quality, especially when the requested content is not cached. Only the requested bitrate is cached. Therefore, a media client that requests a 50Kbps stream receives that stream, and the SG appliance caches only the 50Kbps bitrate content.

Bitrate Thinning Thinning support is closely related to MBR, but different in that thinning allows for data rate optimizations even for single data-rate media files. If the media client detects that there is network congestion, it requests a subset of the single data rate stream. For example, depending on how congested the network is, the client requests only the key video frames or audio-only instead of the complete video stream.

Pre-Populating Content The SG appliance supports pre-population of streaming files from HTTP servers and origin content servers. Downloading streaming files from HTTP servers reduces the time required to pre-populate the file. Note: QuickTime content is not supported. Windows Media RTSP only supports prepopulation of streaming files from origin content servers. However, whenever origin content server allows faster caching of streaming content, Windows Media RTSP prepopulates the content much faster.

Pre-population can be accomplished through streaming from the media server. The required download time was equivalent to the file length; for example, a two-hour movie required two hours to download. Now, if the media file is hosted on a HTTP server, the download time occurs at normal transfer speeds of an HTTP object, and is independent of the play length of the media file. Note: Content must be hosted on a HTTP server in addition to the media server.

Using the content distribute CLI command, content is downloaded from the HTTP server and renamed with a given URL argument. A client requesting the content perceives that the file originated from a media server. If the file on the origin media server experiences changes (such as naming convention), SGOS bypasses the cached mirrored version and fetches the updated version.

43

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media

About Fast Streaming (Windows Media) Note: This feature applies to Windows Media only.

Windows Media Server version 9 contains a feature called Fast Streaming that allows clients to provide streams with extremely low buffering time. SGOS 4.x supports the following functionality for both cached and uncached content: ❐

Fast Start

❐

Fast Cache

Fast Recovery and Fast Reconnect are currently not supported.

About QoS Support The SG appliance supports Quality of Service (QoS), which allows you to create policy to examine the Type of Service fields in IP headers and perform an action based on that information. For streaming protocols, managing the QoS assists with managing bandwidth classes. For detailed information about managing QoS, see the Advanced Policy chapter in Volume 6: Advanced Networking.

About Windows Media Over RTSP This section provides inter-activity notes for Windows Media over RTSP deployments.

License Requirements The Windows Media RTSP functionality is included in the existing Windows Media license.

Standard License When a standard Windows Media license is installed, only pass-through streaming mode and full policy control are available. Advanced features, for example, live splitting, VOD caching, or multicast-station are not available.

Premium License When a premium Windows Media license is installed, the full functionality for Windows Media RTSP is available. If a Windows Media license is not installed, or the license has expired, client connections are denied.

Upgrade/Downgrade Issues There are no software upgrade/downgrade requirements associated with Windows Media RTSP. If the SG appliance is downgraded to a release prior to SGOS 4.2.3, RTSP connections from a Windows Media Player are denied. However, the client will fail over to MMS or HTTP, which are handled by the MMS proxy.

44

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media

Management Console and CLI Changes No Management Console or CLI changes are related to the Windows Media RTSP feature.

Supported Streaming Features The following table describes the supported Windows Media streaming features.

Live Support Table 3-1. Windows Media live RTSP streaming feature support Feature

Live Support

Multi-Bit Rate and Thinning

Yes

UDP Retransmission

No

Server-Side Playlists

Yes

Stream Change

Yes

Splitting Server-Authenticated Data

Yes

Splitting Proxy-Authenticated Data

Yes

Adherence to RTSP Cache Directives

Yes

On Demand Support Table 3-2. Windows Media on demand RTSP streaming feature support Feature

On Demand Support

Multi-Bit Rate and Thinning

Yes

Fast Forward and Rewind

Yes

Fast Streaming

Yes

UDP Retransmission

No

Server-Side Playlists

No Caching

Stream Change

No

Caching Server-Authenticated Data

Yes

Caching Proxy-Authenticated Data

Yes

Adherence to RTSP Cache Directives

Yes

Partial File Caching

Yes

File Invalidation/Freshness checking for

Yes

Cached Files

45

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media

Multicast Support Table 3-3. Windows Media Multicast UDP streaming feature support Feature

Multicast

Multi-Bit Rate and Thinning

Yes

Server-Side Playlists

No

Stream Change

No

Multicasting Server-Authenticated Data

No

Multicasting Proxy-Authenticated Data

No

Other Supported Features The Windows Media RTSP streaming feature also supports the following features: ❐

Access logging for unicast clients

❐

Summary statistics in the Management Console

❐

Detailed statistics

Supported VPM Properties and Actions Windows Media RTSP supports the following policy properties and actions: ❐

allow, deny, force_deny

❐

access_server(yes|no). Forces the SG appliance to deliver content only from the cache. Requests for live streams are denied.

❐

authenticate(realm)

❐

forward(alias_list|no)

❐

forward.fail_open(yes|no)

❐

reflect_ip(auto|no|client|vip|)

❐

bypass_cache(yes|no). Forces the SG appliance to deliver content in pass-through

mode. ❐

limit_bandwidth()

❐

rewrite(). One-way URL rewrite of server-side URLs is supported.

Windows Media RTSP also supports the following streaming-relevant properties: ❐

max_bitrate(bitrate|no). Sets the maximum bit rate that can be served to the client. (This property does not apply to the bit rate consumed on the gateway connection.) If the bit rate of a client-side session exceeds the maximum bit rate set by policy, that client session is denied.

❐

force_cache(yes|no). Causes the SG appliance to ignore RTSP cache directives and

cache VOD content while serving it to clients. Note: Windows Media RTSP does not support policy-based streaming transport selection.

46

Chapter 3: Managing Streaming Media

Section A: Concepts: Streaming Media

Bandwidth Management Windows Media RTSP supports bandwidth management for both client-side and gateway-side streaming traffic. Bandwidth limiting is supported for both client-side and gateway-side streaming traffic. Bandwidth limits are also be supported for pass-through streams.

About Streaming Media Authentication The following sections discuss authentication between streaming media clients and SG appliances and between SG appliances and origin content servers (OCS).

Windows Media Server-Side Authentication Windows Media server authentication for HTTP and MMS supports the following authentication types: ❐

HTTP—BASIC Authentication and Membership Service Account

❐

HTTP—BASIC Authentication and Microsoft Windows Integrated Windows Authentication (IWA) Account Database

❐

IWA Authentication and IWA Account Database

The SG appliance supports the caching and live-splitting of server-authenticated data. The functionality is also integrated with partial caching functionality so that multiple security challenges are not issued to the Windows Media Player when it accesses different portions of the same media file. When Windows Media content on the server is accessed for the first time, the SG appliance caches the content along with the authentication type enabled on the server. The cached authentication type remains until the appliance learns that the server has changed the enabled authentication type, either through cache coherency (checking to be sure the cached contents reflect the original source) or until the SG appliance connects to the origin server (to verify access credentials). Authentication type on the server refers to the authentication type enabled on the origin server at the time when the client sends a request for the content.

Windows Media Proxy Authentication If proxy authentication is configured, Windows Media clients are authenticated based on the policy settings. The the SG appliance evaluates the request from the client and verifies the accessibility against the set policies. The Windows Media player then prompts the client for the proper password. If the client is accepted, the Windows Media server might also require the client to provide a password for authentication. If a previously accepted client attempts to access the same Windows Media content again, the SG appliance verifies the user credentials using its own credential cache. If successful, the client request is forwarded to the Windows Media server for authentication. Windows Media Player Authentication Interactivities Consider the following proxy authentication interactivities with the Windows Media player (except when specified, these do not apply to HTTP streaming): ❐

If the proxy authentication type is configured as BASIC and the server authentication type is configured as IWA, the default is denial of service.

47

Volume 3: Web Communication Proxies Section A: Concepts: Streaming Media ❐

If proxy authentication is configured as IWA and the server authentication is configured as BASIC, the proxy authentication type defaults to BASIC.

❐

The SG appliance does not support authentication based on url_path or url_path_regex conditions when using mms as the url_scheme.

❐

Transparent style HTTP proxy authentication fails to work with Windows Media players when the credential cache lifetime is set to 0 (independent of whether serverside authentication is involved).

❐

If proxy authentication is configured, a request for a stream through HTTP prompts the user to enter access credentials twice: once for the proxy authentication and once for the media server authentication.

❐

Additional scenarios involving HTTP streaming exist that do not work when the TTL is set to zero (0), even though only proxy authentication (with no server authentication) is involved. The SG appliance returning a 401-style proxy authentication challenge to the Windows Media Player 6.0 does not work because the Player cannot resolve inconsistencies between the authentication response code and the server type returned from the SG appliance. This results in an infinite loop of requests and challenges. Example scenarios include transparent authentication— resulting from either transparent request from player or hard-coded service specified in the SG appliance—and request of cache-local (ASX-rewritten or unicast alias) URLs.

Real Media Proxy Authentication If proxy authentication is configured, Real Media clients are authenticated based on the policy settings. The proxy (the SG appliance) evaluates the request from the client and verifies the accessibility against the set policies. Next, RealPlayer prompts the client for the proper password. If the client is accepted, the Real Media server can also require the client to provide a password for authentication. If a previously accepted client attempts to access the same Real Media content again, the SG appliance verifies the user credentials using its own credential cache. If successful, the client request is forwarded to the Real Media server for authentication. Real Media Player Authentication Limitation Using RealPlayer 8.0 in transparent mode with both proxy and Real Media server authentication configured to BASIC, RealPlayer 8.0 always sends the same proxy credentials to the media server. This is regardless of whether a user enters in credentials for the media server. Therefore, the user is never authenticated and the content is not served.

QuickTime Proxy Authentication BASIC is the only proxy authentication mode supported for QuickTime clients. If an IWA challenge is issued, the mode automatically downgrades to BASIC.

48

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media

Section B: Configuring Streaming Media This section describes how to configure the various SG appliance streaming options. This section contains the following topics: ❐

"Configuring Streaming Services" on page 49

❐

"Configuring Streaming Proxies" on page 52

❐

"Limiting Bandwidth" on page 53

❐

"Configuring the SG Appliance Multicast Network" on page 55

❐

"Configuring Media Server Authentication Type (Windows Media)" on page 56

❐

"Related CLI Syntax to Manage Streaming" on page 56

❐

"Reference: Access Log Fields" on page 57

❐

"Reference: CPL Triggers, Properties, and Actions" on page 58

❐

"Streaming History Statistics" on page 58

Related Topics You must also configure the network service (Configuration > Network > Services) to assign port numbers and modes (transparent or proxy). For more information, refer to Volume 3: Proxies and Proxy Services.

Configuring Streaming Services By default, the streaming services (MMS and RTSP) are configured be Transparent and in Bypass mode. The following procedure describes how to change them to Intercept mode, and explains other attributes within the service. To configure the MMS/RTSP proxy services attributes: 1.

From the Management Console, select Configuration > Services > Proxy Services.

49

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media

2

3

2.

Scroll the list of services to display the default one of the IM service lines (this example uses MMS). Notice the Action is Bypass. You can select Intercept from the drop-down list, but for the purposes of this procedures, select the service line to highlight it.

3.

Click Edit. The Edit Service dialog appears with the default settings displays.

50

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media

4a

4b

4c

4.

Configure the service attributes: a.

In the Name field, enter a name that intuitively labels this service. This example accepts the default name.

b.

The TCP/IP Settings options allow you to manage the data connections:

c.

•

Reflect Client IP: If this is enabled, the connection to the origin content server appears to come from the client, not the SG.

•

Early Intercept: Not valid for this service.

In the Listeners field, select Intercept from the drop-down list; the SG must intercept the streaming connection. Note: You can also change the mode from Bypass to Intercept from the main

services page. d. Click OK 5.

Click Apply.

Result: The streaming service is configured and appears in Management Console.

51

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media

Now that the streaming listeners are configured, you can configure the streaming proxies.

Configuring Streaming Proxies This section describes how to configure the Streaming Media proxies. The Windows Media and Real Media proxy options are identical except for one extra option for Real Media. As QuickTime is not cached but passed through the SG appliance, there is only one option. To configure Windows Media, Real Media, and QuickTime streaming proxies: 1.

From the Management Console, select Configuration > Services > Streaming Proxies > Windows Media, Real Media, or QuickTime (configures HTTP Handoff only).

2

3 4 5

2.

Specify the when the SG appliance checks cached streaming content for freshness. •

Never check freshness: The default, but Blue Coat recommends not using this

option. •

Check freshness every value hours: The SG appliance checks content freshness

every n.nn hours. •

Check freshness every access: Every time cached content is requested, it is

checked for freshness.

52

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media

Note: A value of 0 requires the streaming content to always be checked for freshness.

3.

Enable HTTP handoff: Enabled by default. Only disable if you do not want HTTP

streams to be cached or split. See “About HTTP Handoff” on page 39. 4.

Forward client-generated logs to origin media server: Enabled by default. The SG

appliance logs information, such as client IP address, the date, and the time, to the origin server for Windows Media and Real Media content. Note: For Real Media, the log is only forwarded before a streaming session is halted; QuickTime log forwarding is not supported.

5.

Enable multicast (Real Media proxy only): The SG appliance receives a unicast stream from the origin RealServer and serves it as a multicast broadcast. This allows the SG to take a one-to-one stream and split it into a one-to-many stream, saving bandwidth and reducing the server load. It also produces a higher quality broadcast.

Multicasting maintains a TCP control (accounting) channel between the client and RealServer. The multicast data stream is broadcast using UDP from the SG appliance to RealPlayers that join the multicast. The SG appliance support for Real Media uses UDP port 554 (RTSP) for multicasting. This port number can be changed to any valid UDP port number. 6.

Click Apply.

Note: For Multicast, additional configuration is required. See “Configuring the SG Appliance Multicast Network” on page 55.

Limiting Bandwidth This section describes how to limit bandwidth from both the clients to the SG appliance and the SG appliance to origin content servers (OCS).

53

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media

Configuring Bandwidth Limits—Global This section describes how to limit all bandwidth use through the SG appliance. To specify the bandwidth limit for all streaming protocols: 1.

Select Configuration > Services > Streaming Proxies > General.

2a 2b

2.

To limit the client connection bandwidth: a.

In the Bandwidth field, select Limit client bandwidth to. In the Kilobits/sec field, enter the maximum number of kilobits per second that the SG appliance allows for all streaming client connections. Note: This option is not based on individual clients.

b.

3.

In the Bandwidth pane, select Limit gateway bandwidth. In the Kilobits/sec field, enter the maximum number of kilobits per second that the SG appliance allows for all streaming connections to origin media servers.

Click Apply.

Configuring Bandwidth Limits—Protocol-Specific This section describes how to limit bandwidth use per-protocol through the SG appliance. You can also limit the number of connections from the SG appliance to the OCS. The following example uses Real Media, but the Management Console screens are identical for all protocols.

54

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media To specify the bandwidth limit for Windows Media, Real Media, or QuickTime: 1.

Select Configuration > Services > Streaming Proxies > WMedia Bandwidth -or- RMedia Bandwidth -or- QuickTime Bandwidth.

2a 2b 3

2.

Configure bandwidth limit options: a.

To limit the bandwidth for client connections to the SG appliance, select Limit client bandwidth to. In the Kilobits/sec field, enter the maximum number of kilobits per second that the SG appliance allows for all streaming client connections.

b.

3.

To limit the bandwidth for connections from the SG appliance to origin content servers, select Limit gateway bandwidth to. In the Kilobits/sec field, enter the maximum number of kilobits per second that the SG appliance allows for all streaming connections to origin media servers.

To limit the bandwidth for connections from the SG appliance to the OCS, select Limit maximum connections. In the clients field, enter the total number of clients that can connect concurrently.

4.

Click Apply.

Configuring Bandwidth Limitation—Fast Start (WM) Note: This section applies to Windows Media only and can only accomplished through the CLI.

Upon connection to the SG appliance, Windows Media clients do not consume more bandwidth (in kilobits per second) than the defined value. To specify the maximum starting bandwidth: At the (config) prompt, enter the following command: SGOS#(config) streaming windows-media max-fast-bandwidth kbps

Configuring the SG Appliance Multicast Network This section describes how to configure the SG appliance multicast service. Additional steps are required to configure the SG appliance to serve multicast broadcasts to streaming clients (Windows Media and Real Media). Those procedures are provided in subsequent sections.

55

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media To configure the multicast service: 1.

Select Configuration > Services > Streaming Proxies > General.

2a 2b 2c

2.

Configure Multicast options: a.

In the Maximum Hops field, enter a time-to-live (TTL) value.

b.

In the IP Range fields, enter the IP address range.

c.

In the Port Range fields, enter the port range.

3.

Click Apply.

4.

Enable Windows and Real Media multicast: •

Real Media: See Step 5 on page 53.

•

Windows Media: See "Managing Multicast Streaming for Windows Media" on page 63.

Configuring Media Server Authentication Type (Windows Media) Note: This section applies to Windows Media streaming only and can only be configured through the CLI.

Configure the SG appliance to recognize the type of authentication the origin content server is using: BASIC or NTLM/Kerberos. To configure the media server authentication type: At the (config) prompt, enter the following command: SGOS#(config) streaming windows-media server-auth-type {basic | ntlm}

Related CLI Syntax to Manage Streaming ❐

To enter configuration mode: SGOS#(config) proxy-services SGOS#(config proxy-services) create {mms | rtsp} service_name

❐

The following submodes are available: SGOS#(config) streaming max-client-bandwidth kbits_second SGOS#(config) streaming max-gateway-bandwidth kbits_second

56

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media SGOS#(config) streaming {windows-media | real-media | quicktime} {maxclient-bandwidth kbits_second | no max-client-bandwidth} SGOS#(config) streaming {windows-media | real-media | quicktime} {maxgateway-bandwidth kbits_second | no max-gateway-bandwidth} SGOS#(config) streaming {windows-media | real-media | quicktime} {maxconnections number | no max-connection} SGOS#(config) streaming {windows-media | real-media | quicktime} httphandoff disable SGOS#(config) streaming {windows-media | real-media} refresh-interval number.number SGOS#(config) streaming real-media multicast enable SGOS#(config) streaming windows-media server-auth-type {basic | ntlm} SGOS#(config) content-distribute url [from url]

Reference: Access Log Fields The default Blue Coat streaming fields are (only Streaming-specific or relative are listed and described): c-ip date time c-dns cs-uri-scheme cs-host cs-uri-port cs-uri-path csuri-query c-starttime x-duration c-rate c-status c-playerid cplayerversion c-playerlanguage cs(User-Agent) cs(Referer) c-hostexe chostexever c-os c-osversion c-cpu filelength filesize avgbandwidth protocol transport audiocodec videocodec channelURL sc-bytes c-bytes s-pkts-sent c-pkts-received c-pkts-lost-client c-pkts-lost-net c-pktslost-cont-net c-resendreqs c-pkts-recovered-ECC c-pkts-recoveredresent c-buffercount c-totalbuffertime c-quality s-ip s-dns stotalclients s-cpu-util x-cache-user x-cache-info x-client-address ❐

audiocodec: Audio codec used in stream.

❐

avgbandwidth: Average bandwidth (in bits per second) at which the client was

connected to the server. ❐

channelURL: URL to the .nsc file.

❐

c-buffercount: Number of times the client buffered while playing the stream.

❐

c-bytes: An MMS-only value of the total number of bytes delivered to the client.

❐

c-cpu: Client computer CPU type.

❐

c-hostexe: Host application.

❐

c-os: Client computer operating system.

❐

c-osversion: Client computer operating system version number.

❐

c-playerid: Globally unique identifier (GUID) of the player.

❐

c-playerlanguage: Client language-country code.

❐

c-playerversion: Version number of the player.

❐

c-rate: Mode of Windows Media Player when the last command event was sent.

❐

c-starttime: Timestamp (in seconds) of the stream when an entry is generated in the

log file. ❐

c-status: Codes that describe client status.

57

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media ❐

c-totalbuffertime: Time (in seconds) the client used to buffer the stream.

❐

filelength: Length of the file (in seconds).

❐

filesize: Size of the file (in bytes).

❐

protocol: Protocol used to access the stream: mms, http, or asfm.

❐

s-totalclients: Clients connected to the server (but not necessarily receiving streams).

❐

transport: Transport protocol used (UDP, TCP, multicast, and so on).

❐

videocodec: Video codec used to encode the stream.

❐

x-cache-info: Values: UNKNOWN, DEMAND_MISS, DEMAND_PARTIAL_HIT, DEMAND_HIT, LIVE_FROM_ORIGIN, LIVE_PARTIAL_SPLIT, LIVE_SPLIT.

❐

x-duration: Length of time a client played content prior to a client event (FF, REW,

Pause, Stop, or jump to marker). ❐

x-wm-c-dns: Hostname of the client determined from the Windows Media protocol.

❐

x-wm-c-ip: The client IP address determined from the Windows Media protocol.

❐

x-cs-streaming-client: Type of streaming client in use (windows_media, real_media, or quicktime).

❐

x-rs-streaming-content: Type of streaming content served.

❐

x-streaming-bitrate: The reported client-side bitrate for the stream.

Reference: CPL Triggers, Properties, and Actions The following Blue Coat CPL is supported in Streaming:

Triggers ❐

streaming.client=

❐

streaming.content=

Properties and Actions streaming.transport=

Streaming History Statistics The Streaming History tabs (Windows Media, Real Media, and QuickTime) display bar graphs that illustrate the number of active client connections over the last 60 minutes, 24 hours, and 30 days. These statistics are not available through the CLI. The Current Streaming Data and Total Streaming Data tabs display real-time values for current connection and live traffic activity on the SG appliance. Current and total streaming data statistics are available through the CLI.

Viewing Windows Media Statistics The Windows Media tab shows the number of active Windows Media client connections over the last 60 minutes, 24 hours, and 30 days.

58

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media To view Windows Media client statistics: 1.

2.

Select Statistics > Protocol Details > Streaming History > Windows Media.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Viewing Real Media Statistics The Real Media tab shows the number of active Real Media client connections over the last 60-minutes, 24 hours, and 30 days. To view Real Media data statistics: 1.

2.

Select Statistics > Protocol Details > Streaming History > Real Media.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

59

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media

Viewing QuickTime Statistics The QuickTime tab shows the number of active QuickTime client connections over the last 60 minutes, 24 hours and 30 days. To view QuickTime data statistics: 1.

2.

Select Statistics > Protocol Details > Streaming History > QuickTime.

(Optional) To set the graph scale to a different value, select a value from the Graph scale should drop-down list.

Viewing Current and Total Streaming Data Statistics The Management Console Current Streaming Data tab and the Total Streaming Data tab show real-time values for Windows Media, Real Media, and QuickTime activity on the SG appliance. These statistics can also viewed through the CLI. To view current streaming data statistics: 1.

Select Statistics > Protocol Details > Streaming History > Current Streaming Data.

60

Chapter 3: Managing Streaming Media

Section B: Configuring Streaming Media

2.

Select a streaming protocol from the Protocol drop-down list.

3.

Select a traffic connection type (Live, On-Demand, or Pass-thru) from the drop-down list.

To view total streaming data statistics: 1.

Select Statistics > Streaming History > Total Streaming Data.

2.

Select a streaming protocol from the Protocol drop-down list.

3.

Select a traffic connection type (Live, On-Demand, or Passthru) from the drop-down list.

To clear streaming statistics: Enter the following command at the prompt: SGOS# clear-statistics {quicktime | real-media | windows-media}

61

Volume 3: Web Communication Proxies Section B: Configuring Streaming Media

Viewing Streaming Bandwidth Gain The Management Console Streaming Bandwidth Gain tab show real-time statistics for bandwidth gained when you employ

62

Chapter 3: Managing Streaming Media

Section C: Additional Configuration Tasks—Windows Media (CLI)

Section C: Additional Configuration Tasks—Windows Media (CLI) This section provides Windows Media configuration tasks that cannot be accomplished through the Management Console, but can be accomplished through the CLI. This section contains the following topics: ❐

"Managing Multicast Streaming for Windows Media" on page 63

❐

"Managing Simulated Live Content (Windows Media)" on page 67

❐

"ASX Rewriting (Windows Media)" on page 69

Managing Multicast Streaming for Windows Media This section describes multicast station and .nsc files, and describes how to configure the SG appliance to send multicast broadcasts to Windows Media clients.

About Multicast Stations A multicast station is a defined location from where the Windows Media player retrieves live streams. This defined location allows .asf streams to be delivered to many clients using only the bandwidth of a single stream. Without a multicast station, streams must be delivered to clients through unicast. A multicast station contains all of the information needed to deliver .asf content to a Windows Media player or to another SG appliance, including: ❐

IP address

❐

Port

❐

Stream format

❐

TTL value (time-to-live, expressed hops)

The information is stored in an .nsc file, which the Window Media Player must be able to access to locate the IP address. If Windows Media Player fails to find proper streaming packets on the network for multicast, the player can roll over to a unicast URL. Reasons for this include lack of a multicast-enabled router on the network or if the player is outside the multicast station’s TTL. If the player fails to receive streaming data packets, it uses the unicast URL specified in the .nsc file that is created from the multicast station configuration. All .nsc files contain a unicast URL to allow rollover. Unicast to Multicast Unicast to multicast streaming requires converting a unicast stream on the server-side connection to a multicast station on the SG appliance. The unicast stream must contain live content before the multicast station works properly. If the unicast stream is a videoon-demand file, the multicast station is created but is not able to send packets to the network. For video-on-demand files, use the broadcast-alias command, discussed below. Multicast to Multicast Use the multicast-alias command to get the source stream for the multicast station.

63

Volume 3: Web Communication Proxies Section C: Additional Configuration Tasks—Windows Media (CLI)

About Broadcast Aliases A broadcast alias defines a playlist, specify a starting time, date, and the number of times the content is repeated.

Creating a Multicast Station To create a multicast station, you must perform the following: ❐

Define a name for the multicast station.

❐

Define the source of the multicast stream.

❐

The port range to be used.

❐

Define the address range of the multicast stream.

❐

Define the TTL value.

❐

Create the multicast alias, unicast alias, and broadcast alias commands to enable the functionality.

Syntax multicast-station name {alias | url} [address | port | ttl]

where •

name specifies the name of the multicast station, such as station1.

•

{alias | url} defines the source of the multicast stream. The source can be a URL or it can be a multicast alias, a unicast alias, or simulated live. (The source commands must be set up before the functionality is enabled within the multicast station.)

•

[address | port | ttl] are optional commands that you can use to override the default ranges of these values. (Defaults and permissible values are discussed below.)

Example 1: Create a Multicast Station This example: ❐

Creates a multicast station, named station1, on SG 10.25.36.47.

❐

Defines the source as mms://10.25.36.47/tenchi.

❐

Accepts the address, port, and TTL default values. SGOS#(config) streaming windows-media multicast-station station1 mms:/ /10.25.36.47/tenchi.

To delete multicast station1: SGOS#(config) streaming no multicast-station station1

Example 2: Create a Broadcast Alias and Direct a Multicast Station to use It This example: ❐

To allow unicast clients to connect through multicast, creates a broadcast alias named array1; defines the source as mms://10.25.36.48/tenchi2.

❐

Instructs the multicast station from Example 1, station1, to use the broadcast alias, array1, as the source.

64

Chapter 3: Managing Streaming Media

Section C: Additional Configuration Tasks—Windows Media (CLI) SGOS#(config) streaming windows-media broadcast-alias array1 mms:// 10.25.36.48/tenchi2 0 today noon SGOS#(config) streaming windows-media multicast-station station1 array1

Changing Address, Port, and TTL Values Specific commands allow you to change the address range, the port range, and the default TTL value. To leave the defaults as they are for most multicast stations and change it only for specified station definitions, use the multicast-station command. The multicast-station command randomly creates an IP address and port from the specified ranges. ❐

Address-range: the default ranges from 224.2.128.0 to 224.2.255.255; the permissible range is 224.0.0.2 and 239.255.255.255.

❐

Port-range: the default ranges from 32768 to 65535; the permissible range is between 1 and 65535.

❐

TTL value: the default is 5 hops; the permissible range is from 1 to 255.

Syntax, with Defaults Set multicast address-range - multicast port-range - multicast ttl

Getting the .nsc File The .nsc file is created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work. To get an .nsc file from newly created station1, open the file by navigating through the browser to the multicast station’s location (where it was created) and save the file as station1.nsc. The file location, based on the streaming configuration above: http://10.25.36.47/MMS/nsc/station1.nsc

Save the file as station1.nsc. Note: You can also enter the URL in the Windows Media Player to start the stream.

The newly created file is not editable; the settings come from streaming configuration file. In that file, you have already defined the following pertinent information for the file: ❐

The address, which includes TTL, IP Address, IP Port, Unicast URL, and the NSC URL. All created .nsc files contain a unicast URL for rollover in case the Windows Media Player cannot find the streaming packets.

❐

The description, which references the MMS URL that you defined.

❐

The format, which contains important ASF header information. All streams delivered by the multicast station definition have their ASF headers defined here.

65

Volume 3: Web Communication Proxies Section C: Additional Configuration Tasks—Windows Media (CLI)

Monitoring the Multicast Station You can determine the multicast station definitions by viewing the streaming windows configuration. To determine the current client connections and current SG appliance connections, use the show streaming windows-media statistics command. To view the multicast station setup: SGOS#(config) show streaming windows config ; Windows Media Configuration license: 1XXXXXXX-7XXXXXXX-7XXXXX logging: enable logging enable http-handoff: enable live-retransmit: enable transparent-port (1755): enable explicit proxy: 0 refresh-interval: no refresh interval (Never check freshness) max connections: no max-connections (Allow maximum connections) max-bandwidth: no max-bandwidth (Allow maximum bandwidth) max-gateway-bandwidth: no max-gateway-bandwidth (Allow maximum bandwidth) multicast address: 224.2.128.0 – 224.2.255.255 multicast port: 32768 – 65535 multicast TTL: 5 asx-rewrite: No rules multicast-alias: No rules unicast-alias: No rules broadcast-alias: No rules multicast-station: station1 mms://10.25.36.47/tenchi 224.2.207.0 40465 5 (playing) Note: Playing at the end of the multicast station definition indicates that the station

is currently sending packets onto the network. The IP address and port ranges have been randomly assigned from among the default ranges allowed. To view the multicast station statistics: SGOS#(config) show streaming windows stat ;Windows Media Statistics Current client connections: by transport: 0 UDP, 0 TCP, 0 HTTP, 1 multicast by type: 1 live, 0 on-demand Current gateway connections: by transport: 0 UDP, 1 TCP, 0 HTTP, 0 multicast by type: 1 live, 0 on-demand

66

Chapter 3: Managing Streaming Media

Section C: Additional Configuration Tasks—Windows Media (CLI)

Managing Simulated Live Content (Windows Media) This section describes simulated live content and how to configure the SG appliance to manage and serve simulated live content.

About Simulated Live Content The simulated live content feature defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day. If used in conjunction with the multicast-alias command, the live content is multicast; otherwise, live content is accessible as live-splitting sources. The feature does not require the content to be cached. When a starting date and time for the simulated live content have been set, the broadcast of the content starts when there is at least one client requesting the file. Clients requesting the simulated live content before the scheduled time are put into wait mode. Clients requesting the content after all of the contents have played receive an error message. Video-on-demand content does not need to be on the SG appliance before the scheduled start time, but prepopulating the content on the appliance provides better streaming quality. Before configuring simulated live, consider the following: ❐

The simulated live content name must be unique. Aliases are not case sensitive.

❐

The name cannot be used for both a unicast and a multicast alias name.

❐

After simulated live content is referenced by one or more multicast stations, the simulated live content cannot be deleted until all multicast stations referencing the simulated live content are first deleted.

The multicast station appears as another client of simulated live content, just like a Windows Media Player. Note: This note applies to HTTP only. If a client opens Windows Media player and

requests an alias before the starting time specified in the broadcast-alias option, the HTTP connection closes after a short time period. When the specified time arrives, the player fails to reconnect to the stream and remains in waiting mode. Three scenarios can occur when a client requests the simulated live content: ❐

Clients connect before the scheduled start time of the simulated live content: clients are put into wait mode.

❐

Clients connect during the scheduled playback time of the simulated live content: clients receive cached content for playback.

❐

Clients connect after the scheduled playback time of the simulated live: the client receives an error message.

The SG Appliance computes the starting playtime of the broadcast stream based on the time difference between the client request time and the simulated live starting time.

67

Volume 3: Web Communication Proxies Section C: Additional Configuration Tasks—Windows Media (CLI)

Creating a Broadcast Alias for Simulated Live Content Syntax streaming windows-media broadcast-alias alias url loops date time

where: •

alias is the name of the simulated live content.

•

url is the URL for the video-on-demand stream. Up to 128 URLs can be specified for simulated live content.

•

loops is the number of times you want the content to be played back. Set to 0 (zero) to allow the content to be viewed an indefinite number of times.

•

date is the simulated live content starting date. Valid date strings are in the format yyyy-mm-dd or today. You can specify up to seven start dates by using the comma as a separator (no spaces).

•

time is the simulated live content starting time. Valid time strings are in the format hh:mm (on a 24-hour clock) or one of the following strings: — midnight, noon — 1am, 2am, ... — 1pm, 2pm, ...

Specify up to 24 different start times within a single date by using the comma as a separator (no spaces). Example 1 This example creates a playlist for simulated live content. The order of playback is dependent on the order you enter the URLs. Up to 128 URLs can be added. SGOS#(config) streaming windows-media broadcast-alias alias url

Example 2 This example demonstrates the following: ❐

creates a simulated live file called bca.

❐

plays back mms://ocs.bca.com/bca1.asf and mms://ocs.bca.com/bca2.asf.

❐

configures the SG appliance to play back the content twice.

❐

sets a starting date and time of today at 4 p.m., 6 p.m., and 8 p.m. SGOS#(config) streaming windows-media broadcast-alias bca mms:// ocs.bca.com/bca1.asf 2 today 4pm,6pm,8pm SGOS#(config) streaming windows-media broadcast-alias bca mms:// ocs.bca.com/bca2.asf

To delete simulated live content: SGOS#(config) streaming windows-media no broadcast-alias alias

68

Chapter 3: Managing Streaming Media

Section C: Additional Configuration Tasks—Windows Media (CLI)

ASX Rewriting (Windows Media) This section describes ASX rewriting and applies to Windows Media only.

About ASX Rewrite If your environment does not use a Layer 4 switch or the Cisco Web Cache Control Protocol (WCCP), the SG appliance can operate as a proxy for Windows Media Player clients by rewriting the Windows Media metafile (which contains entries with URL links to the actual location of the streaming content) to point to the appliance rather than the Windows Media server. The metadata files can have .asx, .wvx, or .wax extensions, but are commonly referred to as .asx files. The .asx file refers to the actual media files (with .asf, .wmv, and .wma extensions). An .asx file can refer to other .asx files, although this is not a recommended practice. If the file does not have one of the metafile extensions and the Web server that is serving the metadata file does not set the correct MIME type, it is not processed by the Windows Media module. Also, the .asx file with the appropriate syntax must be located on an HTTP (not Windows Media) server. The ASX rewrite module is triggered by either the appropriate file extension or the returned MIME type from the server (x-video-asf). Note: If an .asx file syntax does not follow the standard tag-based syntax, the

ASX rewrite module is not triggered. For the SG appliance to operate as a proxy for Windows Media Player requires the following: ❐

The client is explicitly proxied for HTTP content to the SG appliance that rewrites the .asx metafile.

❐

The streaming media SG appliance is configurable. Note: Windows Media Player automatically tries to roll over to different protocols according to its Windows Media property settings before trying the rollover URLs in the .asx metafile.

With the asx-rewrite command, you can implement redirection of the streaming media to a SG appliance by specifying the rewrite protocol, the rewrite IP address, and the rewrite port. The protocol specified in the ASX rewrite rule is the protocol the client uses to reach the SG. You can use forwarding and policy to change the default protocol specified in the original .asx file that connects to the origin media server. When creating ASX rewrite rules, you need to determine the number priority. It is likely you will create multiple ASX rewrite rules that affect the .asx file; for example, rule 100 could redirect the IP address from 10.25.36.01 to 10.25.36.47, while rule 300 could redirect the IP address from 10.25.36.01 to 10.25.36.58. In this case, you are saying that the original IP address is redirected to the IP address in rule 100. If that IP address is not available, the SG looks for another rule matching the incoming IP address.

69

Volume 3: Web Communication Proxies Section C: Additional Configuration Tasks—Windows Media (CLI) Notes and Interactivities Before creating rules, consider the following. ❐

Each rule you create must be checked for a match; therefore, performance might be affected if you create large amounts of rules.

❐

Lower numbers have a higher priority than high numbers. Note: Rules can only be created through the CLI.

❐

ASX rewrite rules configured for multiple SG appliances configured in an HTTP proxy-chaining configuration can produce unexpected URL entries in access logs for the downstream SG appliance (the SG appliance that the client proxies to). The combination of proxy-chained SG appliances in the HTTP path coupled with ASX rewrite configured for multiple SG appliances in the chain can create a rewritten URL requested by the client in the example form of: protocol1://downstream_SecApp/redirect?protocol2:///redirect?protocol3://origin_host/origin_path

In this scenario, the URL used by the downstream SG for caching and access logging can be different than what is expected. Specifically, the downstream SG appliance creates an access log entry with protocol2://upstream_SecApp/redirect as the requested URL. Content is also cached using this truncated URL. Blue Coat recommends that the ASX rewrite rule be configured for only the downstream SG appliance, along with a proxy route rule that can forward the Windows Media streaming requests from the downstream to upstream SG appliances. Syntax for the asx-rewrite Command: asx-rewrite rule # in-addr cache-proto cache-addr [cache-port]

where: •

in-addr—Specifies the hostname or IP address delivering the content

•

cache-proto—Specifies the rewrite protocol on the SG. Acceptable values for the rewrite protocol are:

•

mmsu specifies Microsoft Media Streaming UDP

•

mmst specifies Microsoft Media Streaming TCP

•

http specifies HTTP

•

mms specifies either MMS-UDP or MMS-TCP

•

* specifies the same protocol as in the .asx file

If the .asx file is referred from within another .asx file (not a recommended practice), use a * for the cache-proto value. This specifies that the protocol specified in the original URL is used. As a conservative, alternative approach, you could use HTTP for the cache-proto value. •

cache-addr—Specifies the rewrite address on the SG appliance.

•

cache-port—Specifies the port on the SG appliance. This value is optional.

70

Chapter 3: Managing Streaming Media

Section C: Additional Configuration Tasks—Windows Media (CLI) To set up the .asx rewrite rules: At the (config) command prompt, enter the following command: SGOS#(config) streaming windows-media asx-rewrite number in-addr cache-proto cache-addr cache-port

Note: To delete a specific rule, enter streaming windows-media no asx-rewrite number.

To ensure that an ASX rewrite rule has been modified immediately, clear the local browser cache. Example This example: ❐

Sets the priority rule to 200

❐

Sets the protocol to be whatever protocol was originally specified in the URL and directs the data stream to the appropriate default port.

❐

Provides the rewrite IP address of 10.9.44.53, the SG appliance. SGOS#(config) streaming windows-media asx-rewrite 200 * * 10.9.44.53

Note: ASX files must be fetched from HTTP servers. If you are not sure of the network topology or the content being served on the network, use the asterisks to assure the protocol set is that specified in the URL.

ASX Rewrite Incompatibility With Server-side IWA Authentication Server-side authentication (MMS only, not HTTP) is supported if the origin media server authentication type is BASIC or No Auth. However, if you know that a Windows Media server is configured for IWA authentication, the following procedure allows you to designate any virtual IP addresses to the IWA authentication type. If you know that all of the activity through the SG appliance requires IWA authentication, you can use the IP address of the appliance. To designate an IP address to an authentication type: 1.

If necessary, create a virtual IP address that is used to contact the Windows Media server.

2.

At the (config) prompt, enter the following command: SGOS#(config) streaming windows-media server-auth-type ntlm ip_address

3.

Configure the ASX rewrite rule to use the IP address. a.

To remove the authentication type designation: SGOS#(config) streaming windows-media no server-auth-type ip_address

b.

To return the authentication type to BASIC: SGOS#(config) streaming windows-media server-auth-type basic ip_address

71

Volume 3: Web Communication Proxies Section D: Windows Media Player

Section D: Windows Media Player This section describes how to configure the Windows Media Player to communicate through the SG appliance.

Configuring Windows Media Player To apply the SG appliance Windows Media streaming services, Windows Media Player must be installed and configured to use explicit proxy. MMS explicit proxy is defined with the asx-rewrite command (discussed earlier in this chapter) or with CPL (url_host_rewrite). Note: The example below uses Windows Media Player 9.0. Installation and setup varies

with different versions of Windows Media Player. To configure Windows Media Player: 1.

Start Windows Media Player.

2.

Select Tools > Options.

3a

4a

3b

4b

3c

72

Chapter 3: Managing Streaming Media

Section D: Windows Media Player 3.

4.

5.

Navigate to protocol configuration: a.

Select Network.

b.

Select MMS.

c.

Click Configure. The Configure Protocol Dialog appears.

Configure the proxy settings: a.

Select Use the following proxy server.

b.

Enter the SG appliance IP address and the port number used for the explicit proxy (the default MMS port is 1755). These settings must match the settings configured in the SG appliance. If you change the SG appliance explicit proxy configuration, you must also reconfigure the Windows Media Player.

Click OK in both dialogs. Result: the Windows Media Player now proxies through the SG appliance and content is susceptible to streaming configurations and access policies.

Windows Media Player Inter-activity Notes This section describes Windows Media Player interactivities that might affect performance.

Striding When you use the Windows Media Player, consider the following interactivities in regard to using fast forward and reverse (referred to as striding): ❐

If you request a cached file and repeatedly attempt play and fast forward, the file freezes.

❐

If you attempt a fast reverse of a cached file that is just about to play, you receive an error message, depending on whether you have a proxy:

❐

•

Without a proxy: A device attached to the system is not functioning.

•

With a proxy: The request is invalid in the current state.

If Windows Media Player is in pause mode for more than ten minutes and you press fast reverse or fast forward, an error message displays: The network connection has failed.

Other Notes ❐

Applies to Versions 9: if a url_host_rewrite rule is configured to rewrite a host name that is a domain name instead of an IP address, a request through the MMS protocol fails and the host is not rewritten. As the connect message sent by the player at the initial connection does not contain the host name, a rewrite cannot occur. HTTP requests are not affected by this limitation.

❐

If explicit proxy is configured and the access policy on the SG appliance is set to deny, a requested stream using HTTP from Windows Media Player 9 serves the stream directly from the origin server even after the request is denied. The player sends a request to the OCS and plays the stream from there.

73

Volume 3: Web Communication Proxies Section D: Windows Media Player Blue Coat recommends the following policy: streaming.content=yes deny -or streaming.content=windows_media deny

The above rules force the HTTP module to hand-off HTTP requests to the MMS module. MMS returns the error properly to the player, and does not go directly to the origin server to try to server the content. ❐

If you request an un-cached file using the HTTP protocol, the file is likely to stop playing if the authentication type is set to BASIC or NTLM/Kerberos and you initiate rapid seeks before the buffering begins for a previous seek. The Windows Media Player, however, displays that the file is still playing.

❐

If a stream is scheduled to be accessible at a future time (using a simulated live rule), and the stream is requested before that time, the Windows Media Player enters a waiting stage. This is normal. However, if HTTP is used as the protocol, after a minute or two the Windows Media Player closes the HTTP connection, but remains in the waiting stage, even when the stream is broadcasting.

Notes: For authentication-specific notes, see "Windows Media Server-Side Authentication" on page 47 and "Windows Media Proxy Authentication" on page 47.

74

Chapter 3: Managing Streaming Media

Section E: RealPlayer

Section E: RealPlayer This section describes how to configure the Windows Media Player to communicate through the SG appliance.

Configuring RealPlayer To use the SG appliance Real Media streaming services with an explicit proxy configuration, the client machine must have RealPlayer installed and configured to use RTSP streams. If you use transparent proxy, no changes need to be made to the RealPlayer. Note: This procedure features RealPlayer, version 10.5. Installation and setup menus vary with different versions of RealPlayer. Refer to the RealPlayer documentation to configure earlier versions of RealPlayer.

To configure RealPlayer: 1.

Start RealPlayer.

2.

Select Tools > Preferences.

75

Volume 3: Web Communication Proxies Section E: RealPlayer

3a

3b

4a

4b

3.

4.

Navigate to proxy settings: a.

Select Connection > Proxy.

b.

Click Change Settings. The Streaming Proxy Settings dialog appears.

Configure options: a.

In the PNA and RTSP proxies: field, select Use proxies.

b.

Enter the SG IP address and the port number used for the explicit proxy (the default RTSP port is 544). These settings must match the settings configured in the SG appliance. If you change the SG appliance explicit proxy configuration, you must also reconfigure the RealPlayer. If using transparent proxy, RTSP port 554 is set by default and cannot be changed.

76

Chapter 3: Managing Streaming Media

Note: For HTTP Proxy, if you have an HTTP proxy already configured in your browser, select Use system Internet Connection proxy settings.

c.

Optional: For HTTP Proxy, if you have an HTTP proxy already configured in your browser, select Use system Internet Connection proxy settings.

d. Optional: In the Do not use proxy for: section, you can enter specific hosts and bypass the SG appliance. Note: This can also be accomplished with policy, which is the method Blue Coat recommends.

e.

Click OK to close the Streaming Proxy Settings dialog.

5a 5b

5.

Configure RealPlayer transport settings: a.

Select Connection > Network Transports.

b.

Click RTSP Settings. The RTSP Transport Settings dialog appears.

6.

If required, deselect options, based on your network configuration. For example, if your firewall does not accept UDP, you can deselect Attempt to use UDP for all content, but leave the TCP option enabled. Blue Coat recommends using the default settings.

7.

Click OK. To allow the creation of access log entries, RealPlayer must be instructed to communicate with the RealServer.

77

Volume 3: Web Communication Proxies

8a

8.

8b

Perform the following: a. b.

Select View > Preferences > Internet/Privacy.

In the Privacy field, select Send connection-quality data to RealServers; click OK.

Result: the RealPlayer now proxies through the SG appliance and content is susceptible to streaming configurations and access policies. Notes: For authentication-specific issues, see “ Real Media Proxy Authentication” on page 48.

78

Chapter 3: Managing Streaming Media

Section F: QuickTime Player This section describes how to configure the QuickTime client.

Configuring QuickTime Player This section describes how to configure the QuickTime player for explicit proxy to the SG appliance. To configure QuickTime 1.

Select Edit > Preferences > QuickTime Preferences.

2a

2b 2c

2.

2d

Configure the protocol settings: a.

Click Advanced.

b.

Select RTSP Proxy Server;

c.

Enter the IP address of the SG appliance to connect to.

d. Enter the port number (554 is the default). These settings must match the settings configured in the SG appliance. If you change the SG appliance explicit proxy settings, set similar settings in RealPlayer. 3.

Close OK. Result: the QuickTime now proxies—in pass-through mode—through the SG appliance.

Notes: For authentication-specific issues, see “ QuickTime Proxy Authentication” on page 48.

79

Volume 3: Web Communication Proxies

80

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

81

Volume 3: Web Communication Proxies

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

82

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

83

Volume 3: Web Communication Proxies

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

84

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

85

Volume 3: Web Communication Proxies

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

86

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

87

Volume 3: Web Communication Proxies

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

88

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

89

Volume 3: Web Communication Proxies

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

90

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

91

Volume 3: Web Communication Proxies

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

92

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

93

Volume 3: Web Communication Proxies

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

94

Index

A

P

ASX rewrite command syntax 69 rules 69 setting up for Windows Media 68

port services instant messaging protocols 9 proxies definition 7

B

R

Blue Coat SG instant messaging configuring clients 20 proxy authentication 9 securing 9 Yahoo Messenger client configuration 23 instant messaging, IM clients tab statistics 31 instant messaging, IM data tab statistics 30

RealMedia proxy authentication 47 RTSP over Windows Media, about 43

D document conventions 7

H HTTP handoff, enabling 39

I instant messaging configuring clients 20 proxy authentication 9 securing 9 statistics, IM clients tab 31 statistics, IM data tab 30 Yahoo Messenger client configuration 23

M multicast defined 37 unicast, converting by Windows Media 38

S streaming WM over RTSP, about 43 streaming media delivery type 37 live content defined 38 multicast defined 37 prepopulating content, description 42 unicast defined 37

U unicast defined 37 multicast, converting from by Windows Media 38

W Windows Media .ASX-rewrite rules 69 .nsc file 64 ASX rewrite and NTLM incompatibility 70 authentication limitations 46 HTTP handoff enabling 39 multicast station monitoring 65 multicast to unicast 38 over RTSP 43 prepopulating content description 42 setting up ASX rewrite 68

95

Volume 3: Web Communication Proxies

96

Blue Coat® Systems SG™ Appliance

Volume 4: Securing the Blue Coat SG Appliance

SGOS Version 5.2.2

Volume 4: Securing the Blue Coat SG Appliance

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02841 Document Revision: SGOS 5.2.2—09/2007

ii

Contents Contact Information

Chapter 1: About Security Controlling SG Appliance Access ...................................................................................................................11 Controlling User Access with Identity-based Access Controls ..................................................................11 SSL Between the SG Appliance and the Authentication Server.................................................................12 About This Book ................................................................................................................................................12 Document Conventions....................................................................................................................................13 Chapter 2: Controlling Access to the SG Appliance Limiting Access to the SG Appliance .............................................................................................................15 Requiring a PIN for the Front Panel........................................................................................................15 Limiting Workstation Access ...................................................................................................................16 Securing the Serial Port .............................................................................................................................16 About Password Security.................................................................................................................................16 Limiting User Access to the SG Appliance—Overview ..............................................................................17 Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL) ..........................................................................................................................................................19 Maximum Security: Administrative Authentication and Authorization Policy......................................20 Defining Administrator Authentication and Authorization Policies.................................................20 Defining Policies Using the Visual Policy Manager .............................................................................20 Defining Policies Directly in Policy Files................................................................................................21 Admin Transactions and Layers............................................................................................21 Example Policy Using CPL Syntax ..........................................................................................................24 Chapter 3: Controlling Access to the Internet and Intranet Section A: Managing Users About User Login ..............................................................................................................................................26 Viewing Logged-In Users ................................................................................................................................26 Logging Out Users ............................................................................................................................................27 Inactivity Timeout......................................................................................................................................27 Administrator Action ................................................................................................................................28 Policy............................................................................................................................................................28 Refreshing User Data .......................................................................................................................................28 Credential Refresh Time............................................................................................................................29 Authorization Refresh Time ....................................................................................................................29 Surrogate Refresh Time.............................................................................................................................30 Policy............................................................................................................................................................30

iii

Volume 4: Securing the Blue Coat SG Appliance

Related CLI Syntax to Manage Users............................................................................................................. 30 Section B: Using Authentication and Proxies Understanding Authentication Modes................................................................................................... 32 Understanding Origin-Style Redirection ............................................................................................... 34 Selecting an Appropriate Surrogate Credential .................................................................................... 35 Configuring Transparent Proxy Authentication ................................................................................... 35 Permitting Users to Login with Authentication or Authorization Failures...................................... 37 Using Guest Authentication..................................................................................................................... 38 Using Default Groups ............................................................................................................................... 39 Section C: Using SSL with Authentication and Authorization Services Using SSL Between the Client and the SG Appliance .......................................................................... 41 Section D: Creating a Proxy Layer to Manage Proxy Operations Using CPL ................................................................................................................................................... 42 Chapter 4: Understanding and Managing X.509 Certificates Section A: Concepts Public Keys and Private Keys.......................................................................................................................... 52 Certificates.......................................................................................................................................................... 52 SSL Certificates........................................................................................................................................... 52 CA Certificates ........................................................................................................................................... 53 External Certificates................................................................................................................................... 53 Keyrings.............................................................................................................................................................. 53 Cipher Suites Supported by SGOS Software ................................................................................................ 53 Server-Gated Cryptography and International Step-Up............................................................................. 54 Section B: Using Keyrings and SSL Certificates Creating a Keyring ............................................................................................................................................ 56 Deleting an Existing Keyring and Certificate ........................................................................................ 58 Section C: Managing Certificates Managing Certificate Signing Requests......................................................................................................... 59 Creating a CSR ........................................................................................................................................... 59 Viewing a Certificate Signing Request ................................................................................................... 60 Managing SSL Certificates............................................................................................................................... 60 Creating Self-Signed SSL Certificates ..................................................................................................... 61 Importing a Server Certificate.................................................................................................................. 62 Using Certificate Revocation Lists ................................................................................................................. 62 Troubleshooting Certificate Problems ........................................................................................................... 64 Section D: Using External Certificates Importing and Deleting External Certificates............................................................................................... 65 Deleting an External Certificate............................................................................................................... 65 Digitally Signing Access Logs ......................................................................................................................... 66

iv

Contents

Section E: Advanced Configuration Importing an Existing Keypair and Certificate............................................................................................. 67 About Certificate Chains.................................................................................................................................. 69 Importing a CA Certificate .............................................................................................................................. 69 Creating CA Certificate Lists........................................................................................................................... 70 Chapter 5: Certificate Realm Authentication How Certificate Realm Works ........................................................................................................................ 73 Creating a Certificate Realm............................................................................................................................ 74 Defining a Certificate Realm ........................................................................................................................... 74 Defining Certificate Realm General Properties ............................................................................................ 75 Revoking User Certificates .............................................................................................................................. 76 Creating the Certificate Authorization Policy .............................................................................................. 77 Tips...................................................................................................................................................................... 78 Chapter 6: Oracle COREid Authentication Understanding COREid Interaction with Blue Coat ................................................................................... 79 Configuring the COREid Access System....................................................................................................... 79 Additional COREid Configuration Notes ..................................................................................................... 80 Configuring the SG Realm............................................................................................................................... 80 Participating in a Single Sign-On (SSO) Scheme .......................................................................................... 81 Avoiding SG Appliance Challenges........................................................................................................ 81 Creating a COREid Realm ............................................................................................................................... 82 Configuring Agents .......................................................................................................................................... 82 Configuring the COREid Access Server ........................................................................................................ 83 Configuring the General COREid Settings.................................................................................................... 84 Creating the CPL ............................................................................................................................................... 86 Chapter 7: Forms-Based Authentication Section A: Understanding Authentication Forms User/Realm CPL Substitutions for Authentication Forms......................................................................... 93 Tip........................................................................................................................................................................ 94 Section B: Creating and Editing a Form Section C: Setting Storage Options Section D: Using CPL with Forms-Based Authentication Tips.................................................................................................................................................................... 100 Chapter 8: IWA Realm Authentication and Authorization How Blue Coat Works with IWA ................................................................................................................. 101 Creating an IWA Realm ................................................................................................................................ 101 IWA Servers ..................................................................................................................................................... 102 Defining IWA Realm General Properties .................................................................................................... 103 Creating the CPL ............................................................................................................................................. 107 Notes ................................................................................................................................................................. 107

v

Volume 4: Securing the Blue Coat SG Appliance

Chapter 9: LDAP Realm Authentication and Authorization Overview .......................................................................................................................................................... 109 Creating an LDAP Realm .............................................................................................................................. 110 LDAP Servers .................................................................................................................................................. 111 Defining LDAP Base Distinguished Names ............................................................................................... 112 LDAP Search & Groups Tab (Authorization and Group Information) .................................................. 114 Customizing LDAP Objectclass Attribute Values...................................................................................... 116 Defining LDAP General Realm Properties.................................................................................................. 117 Creating the CPL ............................................................................................................................................. 119 Notes .......................................................................................................................................................... 120 Chapter 10: Local Realm Authentication and Authorization Creating a Local Realm .................................................................................................................................. 121 Changing Local Realm Properties ................................................................................................................ 121 Notes .......................................................................................................................................................... 123 Defining the Local User List .......................................................................................................................... 123 Creating a Local User List....................................................................................................................... 123 Populating a List using the .htpasswd File .......................................................................................... 125 Uploading the .htpasswd File ............................................................................................................... 125 Populating a Local User List through the SG Appliance ................................................................... 126 Enhancing Security Settings for the Local User List........................................................................... 128 Creating the CPL ............................................................................................................................................. 129 Chapter 11: Policy Substitution Realm How Policy Substitution Realms Work ....................................................................................................... 131 Creating a Policy Substitution Realm .......................................................................................................... 134 Configuring User Information ...................................................................................................................... 134 Creating a List of Users to Ignore ................................................................................................................. 136 Configuring Authorization............................................................................................................................ 137 Defining Policy Substitution Realm General Properties ........................................................................... 138 Notes .......................................................................................................................................................... 139 Creating the Policy Substitution Policy ....................................................................................................... 140 Using Single Sign-On Realms and Proxy Chains................................................................................ 141 Chapter 12: CA eTrust SiteMinder Authentication Understanding SiteMinder Interaction with Blue Coat ............................................................................ 143 Configuring the SiteMinder Policy Server ........................................................................................... 143 Additional SiteMinder Configuration Notes....................................................................................... 144 Configuring the SG Realm...................................................................................................................... 145 Participating in a Single Sign-On (SSO) Scheme ........................................................................................ 145 Avoiding SG Appliance Challenges...................................................................................................... 146 Creating a SiteMinder Realm ....................................................................................................................... 146 Configuring Agents ................................................................................................................................. 146 Configuring SiteMinder Servers ................................................................................................................... 147 Defining SiteMinder Server General Properties......................................................................................... 148

vi

Contents

Configuring General Settings for SiteMinder...................................................................................... 150 Creating the CPL ............................................................................................................................................. 153 Chapter 13: RADIUS Realm Authentication and Authorization Creating a RADIUS Realm............................................................................................................................. 156 Defining RADIUS Realm Properties ............................................................................................................ 156 Defining RADIUS Realm General Properties ............................................................................................. 158 Creating the Policy.......................................................................................................................................... 160 Fine-Tuning RADIUS Realms ................................................................................................................ 160 Creating RADIUS Groups ...................................................................................................................... 161 CPL Example ............................................................................................................................................ 162 Troubleshooting .............................................................................................................................................. 162 Notes ................................................................................................................................................................. 162 Chapter 14: Novell Single Sign-on Authentication and Authorization How Novell SSO Realms Work .................................................................................................................... 164 How Novell SSO Authorization Works ............................................................................................... 164 Creating a Novell SSO Realm ....................................................................................................................... 165 Novell SSO Agents.......................................................................................................................................... 165 Adding LDAP Servers to Search and Monitor ........................................................................................... 167 Querying the LDAP Search Realm ............................................................................................................... 168 Configuring Authorization............................................................................................................................ 169 Defining Novell SSO Realm General Properties ........................................................................................ 169 Modifying the sso.ini File for Novell SSO Realms ..................................................................................... 171 Creating the CPL ............................................................................................................................................. 172 Using Single Sign-On Realms and Proxy Chains................................................................................ 172 Notes ................................................................................................................................................................. 173 Chapter 15: Sequence Realm Authentication Adding Realms to a Sequence Realm........................................................................................................... 175 Creating a Sequence Realm ........................................................................................................................... 176 Adding Realms to a Sequence Realm........................................................................................................... 176 Defining Sequence Realm General Properties ........................................................................................... 178 Tips.................................................................................................................................................................... 179 Chapter 16: Windows Single Sign-on Authentication How Windows SSO Realms Work ............................................................................................................... 181 How Windows SSO Works with BCAAA............................................................................................ 182 BCAAA Synchronization........................................................................................................................ 182 How Windows SSO Authorization Works .......................................................................................... 183 Creating a Windows SSO Realm ................................................................................................................. 183 Windows SSO Agents..................................................................................................................................... 184 Configuring Authorization............................................................................................................................ 185 Defining Windows SSO Realm General Properties ................................................................................... 186 Modifying the sso.ini File for Windows SSO Realms ................................................................................ 188

vii

Volume 4: Securing the Blue Coat SG Appliance

Using Single Sign-On Realms and Proxy Chains................................................................................ 190 Notes ................................................................................................................................................................. 191 Chapter 17: Using XML Realms About XML Realms ........................................................................................................................................ 193 Before Creating an XML Realm .................................................................................................................... 194 Creating an XML Realm................................................................................................................................. 194 Configuring XML Servers.............................................................................................................................. 195 Configuring XML Options............................................................................................................................. 196 Configuring XML Realm Authorization...................................................................................................... 196 Configuring XML General Realm Properties.............................................................................................. 198 Creating the CPL ............................................................................................................................................. 200 Viewing Statistics ............................................................................................................................................ 200 Appendix A: Glossary Appendix B: Using the Authentication/Authorization Agent Using the BCAAA Service ............................................................................................................................. 215 Performance Notes .................................................................................................................................. 216 Installing the BCAAA Service on a Windows System............................................................................... 217 Notes on SSL and Systems Running pre-Windows 2003................................................................... 222 Notes on SSL and Systems Running Windows 2003 and Later ........................................................ 222 Installing the BCAAA Service on a Solaris System.................................................................................... 222 Creating Service Principal Names for IWA Realms................................................................................... 223 Troubleshooting Authentication Agent Problems ..................................................................................... 225 Common BCAAA Event Messages .............................................................................................................. 225 Appendix C: Managing the SSL Client Understanding the SSL Client....................................................................................................................... 233 Creating an SSL Client.................................................................................................................................... 233 Associating a Keyring and Protocol with the SSL Client .......................................................................... 233 Changing the Cipher Suites of the SSL Client ..................................................................................... 234 Troubleshooting Server Certificate Verification.................................................................................. 237 Setting the SSL Negotiation Timeout ........................................................................................................... 237 Appendix D: XML Protocol Section A: Authenticate Request GET Method (User Credentials in Request)................................................................................................ 240 GET Method (User Credentials in Headers) ............................................................................................... 240 POST Method (User Credentials in Request).............................................................................................. 240 POST Method (User Credentials in Headers)............................................................................................. 240 Section B: Authenticate Response Success .............................................................................................................................................................. 242 Failed/Denied ................................................................................................................................................. 242

viii

Contents

Section C: Authorize Request GET Method..................................................................................................................................................... 244 POST Method................................................................................................................................................... 244 Section D: Authorize Response Success .............................................................................................................................................................. 245 Failed................................................................................................................................................................. 245 Appendix E: Authentication and Authorization Errors Index

ix

Volume 4: Securing the Blue Coat SG Appliance

x

Chapter 1: About Security

Enterprise-wide security begins with security on the SG appliance, and continues with controlling user access to the Intranet and Internet. SSH and HTTPS are the recommended (and default) methods for managing access to the SG appliance. SSL is the recommended protocol for communication between the appliance and a realm's off-box authentication server.

Controlling SG Appliance Access You can control access to the SG appliance several ways: by limiting physical access to the system, by using passwords, restricting the use of console account, through peruser RSA public key authentication, and through Blue Coat Content Policy Language (CPL). How secure the system needs to be depends upon the environment. You can limit access to the SG 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 SG appliance CLI.

❐

Requiring a password to secure the Setup Console.

These methods are in addition to the restrictions placed on the console account (a console account user password) and the Enable password. For information on using the console account, refer to Volume 1: Getting Started. By using every possible method (physically limiting access, limiting workstation IP addresses, and using passwords), the SG appliance is very secure. Once the SG appliance 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.

Controlling User Access with Identity-based Access Controls The SG appliance 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 SG services using either explicit proxy or transparent proxy mode, discussed in Volume 2: Proxies and Proxy Services. Multiple authentication realms can be used on a single SG appliance. Multiple realms are essential if the enterprise is a managed 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.

11

Volume 4: Securing the Blue Coat SG Appliance

A realm configuration includes: ❐

Realm name.

❐

Authentication service—(IWA, LDAP, RADIUS, Local, Certificate, Sequences, CA eTrust SiteMinder®, Oracle COREid™, Policy Substitution, Windows SSO, Novell SSO).

❐

External server configuration—Backend server configuration information, such as host, port, and other relevant information based on the selected service.

❐

Authentication schema—The definition used to authenticate users.

❐

Authorization schema—The definition used to authorize users for membership in defined groups and check for attributes that trigger evaluation against any defined policy rules.

❐

One-time passwords are supported for RADIUS realms only.

You can view the list of realms already created by clicking Configuration > Authentication > Realms. Realms are created on the home page for each realm.

SSL Between the SG Appliance and the Authentication Server SSL communication between the SG appliance and LDAP and IWA authentication servers is supported. In addition, you can also use SSL between the client and the SG appliance. For more information on using SSL between the client and the appliance, see “Using SSL with Authentication and Authorization Services” on page 41. Configuring a realm to use SSL between the SG appliance 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 SG appliance trusts, and the common name in the server certificate must match the server host as specified in the realm configuration. The realms use the default SSL client defined on the SG appliance 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.

About This Book The first few chapters of Volume 4: Securing the Blue Coat SG Appliance deal with limiting access to the SG appliance . The remainder of the book discusses the various realms: ❐

Chapter 2: "Controlling Access to the SG Appliance"

❐

Chapter 3: "Controlling Access to the Internet and Intranet"

❐

Chapter 4: "Understanding and Managing X.509 Certificates"

❐

Chapter 5: "Certificate Realm Authentication"

❐

Chapter 6: "Oracle COREid Authentication"

❐

Chapter 7: "Forms-Based Authentication"

❐

Chapter 8: "IWA Realm Authentication and Authorization"

❐

Chapter 9: "LDAP Realm Authentication and Authorization"

12

Chapter 1: About Security

❐

Chapter 10: "Local Realm Authentication and Authorization"

❐

Chapter 11: "Policy Substitution Realm"

❐

Chapter 12: "CA eTrust SiteMinder Authentication"

❐

Chapter 13: "RADIUS Realm Authentication and Authorization"

❐

Chapter 14: "Novell Single Sign-on Authentication and Authorization"

❐

Chapter 15: "Sequence Realm Authentication"

❐

Chapter 16: "Windows Single Sign-on Authentication"

❐

Chapter 17: "Using XML Realms"

❐

Appendix A: "Glossary"

❐

Appendix D: "XML Protocol"

❐

Appendix C: "Managing the SSL Client"

❐

Appendix B: "Using the Authentication/Authorization Agent"

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

13

Volume 4: Securing the Blue Coat SG Appliance

14

Chapter 2: Controlling Access to the SG Appliance

You can control access to the SG appliance several ways: by limiting physical access to the system, by using passwords, restricting the use of console account, through peruser RSA public key authentication, and through Blue Coat Content Policy Language (CPL). How secure the system needs to be depends upon the environment. This section contains: ❐

“Limiting Access to the SG Appliance”

❐

“About Password Security” on page 16

❐

“Limiting User Access to the SG Appliance—Overview” on page 17

❐

“Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL)” on page 19

❐

“Maximum Security: Administrative Authentication and Authorization Policy” on page 20

Limiting Access to the SG Appliance You can limit access to the SG 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 SG appliance CLI.

❐

Requiring a password to secure the Setup Console.

These methods are in addition to the restrictions placed on the console account (a console account user password) and the Enable password. For information on using the console account, refer to Volume 1: Getting Started. By using every possible method (physically limiting access, limiting workstation IP addresses, and using passwords), the SG appliance is very secure. This section discusses: ❐

“Requiring a PIN for the Front Panel”

❐

“Limiting Workstation Access” on page 16

❐

“Securing the Serial Port” on page 16

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.

15

Volume 4: Securing the Blue Coat SG Appliance

To clear the front-panel PIN, enter: SGOS#(config) security front-panel-pin 0000

Limiting Workstation Access During initial configuration, you have the option of preventing workstations with unauthorized IP addresses from accessing the CLI. If this option is not enabled, all workstations are allowed to access the CLI. You can also add allowed workstations later to the access control list (ACL). (For more information on limiting workstation access, see “Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL)” on page 19.)

Securing the Serial Port If you choose to secure the serial sort, you must provide a Setup Console password that is required to access the Setup Console in the future. Once the secure serial port is enabled: ❐

The Setup Console password is required to access the Setup Console.

❐

An authentication challenge (username and password) is issued to access the CLI through the serial port.

To recover from a lost Setup Console password, you can: ❐

Use the Front Panel display to either disable the secure serial port or enter a new Setup Console password.

❐

Use the CLI restore-defaults factory-defaults command to delete all system settings. For information on using the restore-defaults factory-defaults command, refer to Volume 9: Managing the Blue Coat SG Appliance.

❐

Use the reset button (if the appliance has a reset button) to delete all system settings.

To enable the secure serial port, refer to the Installation Guide for your platform.

About Password Security In the SG appliance, the console administrator password, the Setup Console password, and Enable (privileged-mode) password are hashed and stored. It is not possible to reverse the hash to recover the plaintext passwords. In addition, the show config and show security CLI commands display these passwords in their hashed form. The length of the hashed password depends on the hash algorithm used so it is not a fixed length across the board. Passwords that the SG appliance 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 SG appliance using an encrypted-password command (which is available in several modes and described in those modes). If you use a third-party encryption application, verify it supports RSA encryption, OAEP padding, and Base64 encoded with no new lines. These passwords, set up during configuration of the external service, include: ❐

Access log FTP client passwords (primary, alternate)—For configuration information, refer to Volume 8: Access Logging.

16

Chapter 2: Controlling Access to the SG Appliance

❐

Archive configuration FTP password—For configuration information, refer to the archive configuration information in Volume 1: Getting Started.

❐

RADIUS primary and alternate secret—For configuration information, see Chapter 13: "RADIUS Realm Authentication and Authorization".

❐

LDAP search password—For configuration information, see “LDAP Search & Groups Tab (Authorization and Group Information)” on page 114.

❐

Content filter download passwords—For configuration information, refer to the content filtering information in Volume 7: Managing Content.

Limiting User Access to the SG Appliance—Overview When deciding how to give other users read-only or read-write access to the SG appliance, 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 SG appliance with behavior similar to SSH with password authentication.

SSL configuration is not allowed through Telnet, but is permissible through SSH. Behavior in the following sections that applies to SSH with password authentication also applies to Telnet. Use of Telnet is not recommended because it is not a secure protocol. ❐

Console account—minimum security The console account username and password are evaluated when the SG appliance is accessed from the Management Console through a browser and from the CLI through SSH with password authentication. The Enable (privileged-mode) password is evaluated when the console account is used through SSH with password authentication and when the CLI is accessed through the serial console and through SSH with RSA authentication. The simplest way to give access to others is sharing this basic console account information, but it is the least secure and is not recommended. To give read-only access to the CLI, do not give out the Enable (privileged-mode) password.

❐

Console access control list—moderate security Using the access control list (ACL) allows you to further restrict use of the console account and SSH with RSA authentication to workstations identified by their IP address and subnet mask. When the ACL is enforced, the console account can only be used by workstations defined in the console ACL. Also, SSH with RSA authentication connections are only valid from workstations specified in the console ACL (provided it is enabled). After setting the console account username, password, and Enable (privileged-mode) password, use the CLI or the Management Console to create a console ACL. See “Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL)” on page 19.

❐

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.

17

Volume 4: Securing the Blue Coat SG Appliance

This is a less flexible option than CPL because you cannot control level of access with policy, but it is a better choice than sharing the console credentials. ❐

Blue Coat Content Policy Language (CPL)—maximum security CPL allows you to control administrative access to the SG appliance through policy. If the credentials supplied are not the console account username and password, policy is evaluated when the SG appliance is accessed through SSH with password authentication or the Management Console. Policy is never evaluated on direct serial console connections or SSH connections using RSA authentication. •

Using the CLI or the Management Console GUI, create an authentication realm to be used for authorizing administrative access. For administrative access, the realm must support BASIC credentials—for example, LDAP, RADIUS, Local, or IWA with BASIC credentials enabled.

•

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 readonly 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, refer to Volume 6: VPM and Advanced Policy.

•

To prevent anyone from using the console credentials to manage the SG appliance, set the console ACL to deny all access (unless you plan to use SSH with RSA authentication). For more information, see “Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL)” on page 19. 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 SG console and the authentication and authorization methods that apply to each. Table 2-1. SG Console Access Methods/Available Security Measures Security Measures Available

Serial Console

SSH with Password Authentication

Username and password evaluated (console-level credentials)

3

Console Access List evaluated

3

CPL Layer evaluated

SSH with RSA Authentication

3 3

3(if console

(if console credentials are offered)

credentials are offered)

3(see Note 1 below)

3(see Note 2 below)

Enable password required to enter privileged mode (see Note 2 below)

3

3

3

CLI line-vty timeout command applies.

3

3

3

Management Console Login/Logout

Management Console

3

18

Chapter 2: Controlling Access to the SG Appliance

Note 1: When using SSH (with a password) and credentials other than the console account, the enable password is actually the same as the login password. The privileged mode password set during configuration is used only in the serial console, SSH with RSA authentication, or when logging in with the console account. Note 2: In this case, user credentials are evaluated against the policy before executing each CLI command. If you log in using the console account, user credentials are not evaluated against the policy.

Moderate Security: Restricting Management Console Access Through the Console Access Control List (ACL) The SG appliance allows you to limit access to the Management Console and CLI through the console ACL. An ACL, once set up, is enforced only when console credentials are used to access either the CLI or the Management Console, or when an SSH with RSA authentication connection is attempted. The following procedure specifies an ACL that lists the IP addresses permitted access. To create an ACL: 1.

Select Configuration > Authentication > Console Access > Console Access.

2.

(Optional) To add a new address to the ACL, click New.

a.

In the IP/Subnet fields, enter a static IP address.

b.

In the Mask fields, enter the subnet mask. To restrict access to an individual workstation, enter 255.255.255.255.

c.

Click OK to add the workstation to the ACL and return to the Console Access page.

d. Repeat 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 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: Before you enforce the ACL, verify the IP address for the workstation you are using is included in the list. If you forget, or you find that you mistyped the IP address, you must correct the problem using the serial console.

6.

Click Apply to commit the changes to the SG appliance.

19

Volume 4: Securing the Blue Coat SG Appliance

Related CLI Syntax to Create an ACL SGOS#(config) security allowed-access add ip_address [subnet_mask] SGOS#(config) security enforce-acl enable | disable SGOS#(config) security allowed-access remove ip_address [subnet_mask]

Maximum Security: Administrative Authentication and Authorization Policy The SG appliance permits you to define a rule-based administrative access policy. This policy is enforced when accessing: ❐

the Management Console through http or https

❐

the CLI through SSH when using password authentication

❐

the CLI through telnet

❐

the CLI through the serial port if the secure serial port is enabled

These policy rules can be specified either by using the VPM or by editing the Local policy file. Using policy rules, you can deny access, allow access without providing credentials, or require administrators to identify themselves by entering a username and password. If access is allowed, you can specify whether read-only or read-write access is given. You can make this policy contingent on IP address, time of day, group membership (if credentials were required), and many other conditions. Serial-console access is not controlled by policy rules. For maximum security to the serial console, physical access must be limited. SSH with RSA authentication also is not controlled by policy rules. You can configure several settings that control access: the enable password, the console ACL, and per-user keys configured through the Configuration > Services > SSH > SSH Client page. (If you use the CLI, SSH commands are under config > services > ssh-console.)

Defining Administrator Authentication and Authorization Policies The SG appliance 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 SG appliance: ❐

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

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, refer to Volume 6: VPM and Advanced Policy.

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 Volume 6: VPM and Advanced Policy.

20

Chapter 2: Controlling Access to the SG Appliance

Defining Policies Directly in Policy Files To define policies manually, type CPL rules directly in one of the two policy files, Central or Local. Important: For specific information on creating policies within the policy files, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide. Following are the CPL elements that can be used to define administrator policies for the SG appliance. 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 (refer to Volume 6: VPM and Advanced Policy).

Admin Transactions and Layers Admin transactions execute layers. Only a restricted set of conditions, properties, and actions are permitted in layers. The table below lists the conditions permitted in the layer. Table 2-2. Network Connection 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 SG 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

21

Volume 4: Securing the Blue Coat SG Appliance

Table 2-2. Network Connection 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 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

22

Chapter 2: Controlling Access to the SG Appliance

Table 2-2. Network Connection Conditions (Continued) 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 IWA-realm specific.) If authenticate=yes, the user_domain condition tests whether the realm type is IWA 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 SG console. write tests whether the source has read-write permission. When an Administrator logs into the CLI, the SG appliance 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 SG appliance 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.

The table below lists the properties permitted in the layer: Table 2-3. Properties in the Layer Properties deny

Refuse service to the source of the transaction.

authenticate(realm_name)

Requests authentication of the transaction source for the specified realm.

authenticate.force( )

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

allow

Permit further service to the source of the transaction.

log.suppress.field-id ( )

Controls suppression of the specified field-id in all facilities

log.suppress.field-id[log_list]( )

Controls suppression of the specified field-id in the specified facilities.

23

Volume 4: Securing the Blue Coat SG Appliance

Table 2-3. Properties in the Layer (Continued) 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.

The table below lists the actions permitted in the layer: Table 2-4. Actions permitted in the Layer Actions notify_email( )

Sends an e-mail notification to the list of recipients specified in the Event Log mail configuration when the transaction terminates.

notify_snmp( )

The SNMP trap is sent when the transaction terminates.

Example Policy Using CPL Syntax To authenticate users against an LDAP realm, use the following syntax in the Local Policy file: authenticate(LDAP_Realm) group="cn=Administrators,cn=Groups,dc=bluecoat,dc=com" allow

This authenticates users against the specified LDAP realm. If the users are successfully authenticated and belong to group Administrators, they are allowed to administer the SG appliance.

24

Chapter 3: Controlling Access to the Internet and Intranet

After you have physically secured the SG appliance and limited access to it through passwords, you can limit users’ access to the Internet and intranet. This chapter includes the following sections: ❐

Section A: "Managing Users" on page 26

❐

Section B: "Using Authentication and Proxies" on page 32

❐

Section C: "Using SSL with Authentication and Authorization Services" on page 41

❐

Section D: "Creating a Proxy Layer to Manage Proxy Operations" on page 42

25

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users

Section A: Managing Users When a user is first authenticated to an SG appliance, a user login is created. You can view users who are logged in and configure the SG appliance to log them out and refresh their data. This section includes the following topics: ❐

“About User Login” on page 26

❐

“Viewing Logged-In Users” on page 26

❐

“Logging Out Users” on page 27

❐

“Refreshing User Data” on page 28

❐

“Related CLI Syntax to Manage Users” on page 30

About User Login A user login is the combination of: ❐

An IP address

❐

A username

❐

A realm

For a specific realm, a user is only considered to be logged in once from a given workstation, even if using multiple user agents. However: ❐

If policy authenticates the user against multiple realms, the user is logged in once for each realm.

❐

If a user logs in from multiple workstations, the user is logged in once per workstation.

❐

If multiple users share an IP address (same server, terminal services, or are behind a NAT, which allows a local-area network to use one set of IP addresses), each user is logged in once.

❐

If a user logs in from multiple workstations behind a NAT, the user is logged in once.

Viewing Logged-In Users You can browse all users logged into the SG appliance. You can also filter the displayed users by Glob-username pattern, by IP address subnet, and by realm. The glob-based username pattern supports three operators: ❐

'*' : match zero or more characters

❐

'?' : match exactly one character

❐

'[x-y]': match any character in the character range from 'x' to 'y'

The IP address subnet notation is based on Classless Inter-Domain_Routing (CIDR), a way of interpreting IP addresses, as follows: ❐

1.2.3.4 : the IP address 1.2.3.4

❐

1.2.3.0/24: the subnet 1.2.3.0 with netmask 255.255.255.0

The realm selection allows an exact realm name or All realms to be selected.

26

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users You can use a combination of these filters to display only the users you are interested in. To browse users: 1.

Click Statistics > Authentication.

2.

Select a single realm or All realms from the Realm drop-down list.

3.

(Optional) Enter a regular expression in the User pattern field to display the usernames that match the pattern.

4.

(Optional) Enter an IP address or subnet in the IP prefix field to display the IP addresses that match the prefix.

5.

Click Display by user to display the statistic results by user, or Display by IP to display the results by IP address.

Logging Out Users A logged-in user can be logged out with one of three mechanisms: ❐

Inactivity timeout (see “Inactivity Timeout” on page 27)

❐

Explicit logout by the administrator (see “Administrator Action” on page 28)

❐

Policy (see “Policy” on page 28)

A logged-out user must re-authenticate with the proxy before logging back in. ❐

For single sign-on (SSO) realms (Windows SSO, Novell SSO, and IWA configured for SSO), reauthentication is transparent to the user.

❐

For non-SSO realms, the user is explicitly challenged for credentials after logout, depending on the Challenge user after logout setting in the SG’s realm. Note:

The Challenge user after logout option only works when cookie-surrogates are used. If this setting is enabled, the user is explicitly challenged for credentials after logging out.

Inactivity Timeout Each realm has a new inactivity-timeout setting, used in conjunction with the last activitytime value for a particular login. Each time that a login is completed, this activity time is updated. If the time since the last activity time for a specific login exceeds the inactivitytimeout value, the user is logged out.

27

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users

Administrator Action The administrator can explicitly log out a set of users using the Logout link at the bottom of the user login information pages. See “Viewing Logged-In Users” on page 26 for information about displaying user login information. For information about using the CLI to logout users, see “Related CLI Syntax to Manage Users” on page 30.

Policy Policy has three properties and three conditions to manage user logouts. These properties and conditions can be used to dynamically log out users. For example, you can create a logout link for users. For information about using policy, refer to Volume 6: VPM and Advanced Policy and Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

New Properties Policy has three properties for logging out users. ❐

user.login.log_out(yes)

This property logs out the user referenced by the current transaction. ❐

user.login.log_out_other(yes)

If a user is logged in at more than one IP address, this property logs the user out from all IP addresses except the current IP address. ❐

client.address.login.log_out_other(yes)

If more than one user is logged in at the IP address of the current transaction, this property logs out all users from the current IP address except the current user.

New Conditions Several conditions support different logout policies. ❐

user.login.count

This condition matches the number of times that a specific user is logged in with the current realm. You can use this condition to ensure that a user can be logged in only at one workstation. If the condition is combined with the user.login.log_out_other property, old login sessions on other workstations are automatically logged out. ❐

client.address.login.count

This condition matches the number of different users who are logged into the current IP address, and you can use it to limit the user number. ❐

user.login.time

This condition matches the number of seconds since the current login started, and you can use it to limit the length of a login session.

Refreshing User Data You can refreshing user data with the following refresh-time options on the SG appliance: ❐

Credential refresh time: This option specifies how long a cached username and password is trusted (do not require revalidation).

28

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users ❐

Surrogate refresh time: This option specifies how long surrogate credentials are trusted in a particular realm.

❐

Authorization refresh time: This option specifies how long authorization data, such as groups and attributes, are trusted.

While the realms have the baseline settings for the different refresh times, policy and administrator actions can override the realm settings. Using the same interface and filters as used for viewing logins, the administrator can select logins and refresh the authorization data, the credentials, or the surrogates using the links available on the user login information page. Refreshing user data might be necessary if users are added to new groups or there is concern about the actual identity of the user on a long-lived IP surrogate.

Credential Refresh Time You can set the credential refresh time with realms that can cache the username and password on the SG appliance. This is limited to realms that use Basic username and password credentials, including LDAP, RADIUS, XML, IWA (with Basic credentials), SiteMinder, and COREid. Note:

The local realm uses Basic credentials but does not need to cache them since they are stored already on the appliance.

Cached Usernames and Passwords You can use a cached username and password to verify a user's credentials without having to verify the credentials with the offbox authentication server. Essentially, this reduces the load on the authentication server. For authentication modes that do not use surrogate credentials (that is, proxy or origin modes), this can greatly reduce the traffic to the authentication server. The credential refresh time value determines how long a cached username and password is trusted. After that time has expired, the next transaction that needs credential authentication sends a request to the authentication server. A password different than the cached password also results in a request to the authentication server.

One-Time Passwords One-time passwords are trusted for the credential refresh time. Only when the credential refresh time expires is the user challenged again.

Authorization Refresh Time Realms (Local, LDAP, Windows SSO, Novell SSO, Certificate, XML, and Policy Substitution) that can do authorization and authentication separately can use the authorization refresh time value to manage the load on the authorization server. These realms determine authorization data (group membership and attribute values) separately from authentication, allowing the time the authorization data is trusted to be increased or decreased For realms that must authenticate the user to determine authorization data, the authorization data is updated only when the user credentials are verified by the authentication server.

29

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users

Surrogate Refresh Time This value manages how long surrogate credentials are trusted in a particular realm. The authentication mode determines the type of surrogate that is used. ❐

Cookie surrogates are used with one of the cookie authentication modes; IP address surrogates are used with one of the IP authentications modes; and the Auto authentication mode attempts to select the best surrogate for the current transaction.

❐

IP address surrogates work with all user agents, but require that each workstation has a unique IP address; they do not work with users behind a NAT. An IP surrogate authenticates all transactions from a given IP address as belonging to the user who was last authenticated at that IP address.

When a user is logged out, all surrogates are discarded, along with the cached credentials and authorization data. For more information about using cookie and IP address surrogates, see “Understanding Authentication Modes” on page 32.

Policy Policy has three properties for setting the refresh times for individual transactions. ❐

authenticate.authorization_refresh_time(x)

where x is the number of seconds to use for the authorization refresh time during this transaction. The refresh time cannot exceed the time configured in the realm; policy can be used only to reduce the authorization refresh time. You can use this property to dynamically force the user's authorization data to be refreshed. ❐

authenticate.credential_refresh_time(x)

where x is the number of seconds to use for the credential refresh time during this transaction. The refresh time cannot exceed the time configured in the realm; policy can be used only to reduce the credential refresh time. You can use this property to dynamically force the user's credentials to be refreshed. ❐

authenticate.surrogate_refresh_time(x)

where x is the number of seconds to use for the surrogate refresh time during this transaction. The refresh time cannot exceed the time configured in the realm; policy can be used only to reduce the surrogate refresh time. You can use this property to dynamically force the user's surrogate to be refreshed. For information about using policy, refer to Volume 6: VPM and Advanced Policy and Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

Related CLI Syntax to Manage Users ❐

To enter the manage users submode, use the following commands: SGOS#(config) security users SGOS#(config users)

❐

The following commands are available: (config users) authorization-refresh {ip-addresses prefix [realm_name] | realms [realm_name]| users glob_user_name [realm_name]} (config users) credentials-refresh {ip-addresses prefix [realm_name] | realms [realm_name]| users glob_user_name [realm_name]}

30

Chapter 3: Controlling Access to the Internet and Intranet

Section A: Managing Users (config users) log-out {ip-addresses prefix [realm_name] | realms [realm_name]| users glob_user_name [realm_name]} (config users) surrogates-refresh {ip-addresses prefix [realm_name] | realms [realm_name]| users glob_user_name [realm_name]} (config users) view {detailed {ip-addresses prefix [realm_name] | realms [realm_name]| users glob_user_name [realm_name]} | ip-addresses prefix [realm_name] | realms [realm_name] | users glob_user_name [realm_name]}

31

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

Section B: Using Authentication and Proxies Authentication means that the SG appliance 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/ProxyAuthenticate) 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 SG appliance uses the OCS authentication challenge (HTTP 401 and WWW-Authenticate)—acting as though it is the location from which the user initially requested a page. A transparent proxy, including a reverse proxy, must not use a proxy challenge, because the client might not be expecting it.

Once the browser supplies the credentials, the SG appliance authenticates them.

Understanding Authentication Modes You can control the way the SG appliance interacts with the client for authentication by controlling the authentication mode. The mode specifies the challenge type and the accepted surrogate credential. Note: Challenge type is the kind of challenge (for example, proxy or origin-ip-redirect)

issued. Surrogate credentials are credentials accepted in place of the user’s real credentials. ❐

Auto: The default; the mode is automatically selected, based on the request. Auto can choose any of proxy, origin, origin-ip, or origin-cookie-redirect, depending on the kind

of connection (explicit or transparent) and the transparent authentication cookie configuration. ❐

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

If you have many requests consulting the back-end authentication authority (such as LDAP, RADIUS, or the BCAAA service), you can configure the SG appliance (and possibly the client) to use persistent connections. This dramatically reduces load on the back-end authentication authority and improves the all-around performance of the network.

32

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

Important: Windows supports Kerberos authentication only to origin servers; proxy servers cannot participate. Therefore, explicit authentication modes are not compatible with Kerberos. However, because Internet Explorer automatically selects NTLM for an explicit challenge (where the browser is configured with the proxy as a proxy server), no special processing is required for explicit authentication. An origin redirect authentication mode, such as authenticate.mode (origin-cookieredirect), can be used to obtain Kerberos authentication when using an explicit proxy if the browser is configured to bypass the proxy for the virtual URL. ❐

Proxy-IP: The SG appliance uses an explicit proxy challenge and the client's IP address

as a surrogate credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs of single-user workstations. In some situations proxy challenges do not work; origin challenges are then issued. ❐

Origin: The SG appliance acts like an OCS and issues OCS challenges. The

authenticated connection serves as the surrogate credential. ❐

Origin-IP: The SG appliance acts like an OCS and issues OCS challenges. The client IP address is used as a surrogate credential. Origin-IP is used to support IWA

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 SG appliance acts like an origin server and issues origin server challenges. A cookie is used as the surrogate credential. Origin-cookie is used in forward proxies to support pass-through authentication more securely than origin-ip

if the client understands cookies. Only the HTTP and HTTPS protocols support cookies; other protocols are automatically downgraded to origin-ip. This mode could also be used in reverse proxy situations if impersonation is not possible and the origin server requires authentication. ❐

Origin-cookie-redirect: The client is redirected to a virtual URL to be authenticated, and cookies are used as the surrogate credential. The SG appliance does not support origin-redirects with the CONNECT method. For forward proxies, only origin-*redirect modes are supported for Kerberos/IWA authentication. (Any other mode uses NTLM authentication.) Note: During cookie-based authentication, the redirect to strip the authentication cookie from the URL is logged as a 307 (or 302) TCP_DENIED.

❐

Origin-IP-redirect: The client is redirected to a virtual URL to be authenticated, and the client IP address is used as a surrogate credential. The SG appliance does not support origin-redirects with the CONNECT method. For forward proxies, only origin-*redirect modes are supported for Kerberos/IWA authentication. (Any other mode uses NTLM authentication.)

❐

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

defined rules. ❐

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

33

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies ❐

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 about using authentication modes, refer to Volume 10: Blue Coat SG Appliance 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 IWA uses connection surrogate credentials. In sg2 mode, explicit IWA uses IP surrogate credentials. To configure the IWA default authenticate mode settings: SGOS#(config) security default-authenticate-mode {auto | sg2}

Understanding Origin-Style Redirection Some authentication modes redirect the browser to a virtual authentication site before issuing the origin-style challenge. This gives the user feedback as to which credentials are required, and makes it possible to (but does not require) send the credentials over a secure connection. Since browser requests are transparently redirected to the SG appliance, 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 SG credentials are requested. If authentication is successful, the SG appliance establishes a surrogate credential and redirects the browser back to the original request, possibly with an encoded surrogate credential attached. This allows the SG appliance to see that the request has been authenticated, and so the request proceeds. The response to that request can also carry a surrogate credential. To provide maximum flexibility, the virtual site is defined by a URL. Requests to that URL (only) are intercepted and cause authentication challenges; other URLs on the same host are treated normally. Thus, the challenge appears to come from a host that in all other respects behaves normally.

34

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

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 35 to set up a virtual URL for transparent proxy.

Tip: Using CONNECT and Origin-Style Redirection You cannot use the CONNECT method with origin-style redirection or form redirect modes. An error message similar to the following is displayed: Cannot use origin-redirect for CONNECT method (explicit proxy of https URL)

Instead, you can add policy to either bypass authentication on the CONNECT method, or use proxy authentication. For example: allow http.method=CONNECT authenticate.mode(proxy) authenticate(ldap) allow authenticate(cert) authenticate.mode(origin-cookie-redirect)

Selecting an Appropriate Surrogate Credential IP surrogate credentials are less secure than cookie surrogate credentials and should be avoided if possible. If multiple clients share an IP address (such as when they are behind a NAT firewall or on a multi-user system), the IP surrogate mechanism cannot distinguish between those users.

Configuring Transparent Proxy Authentication The following sections provide general instructions on configuring for transparent proxy authentication. In addition to configuring transparent proxy authentication, you must also enable a transparent proxy port before the transparent proxy is functional. To enable a transparent proxy port, refer to Volume 2: Proxies and Proxy Services. To set transparent proxy options: 1.

Select Configuration > Authentication > Transparent Proxy.

35

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

2.

Select the transparent proxy method—Cookie-based or IP address-based. The default is Cookie. If you select Cookie, the Cookie Type radio buttons are available. Click either: Session, for cookies that are deleted at the end of a session, or Persistent, for cookies that remain on a client machine until the cookie TTL (Time To Live) is reached or the credentials cache is flushed. The default is Session. If you select Persistent Cookies, enter the Cookie TTL. If you choose IP address-based, enter the IP address TTL. The default for each is 15 minutes. Note: A value of 0 (zero) for the IP address TTL re-prompts the user for credentials

once the specified cache duration for the particular realm has expired. For authentication modes that make use of IP surrogate credentials, once the IP address TTL expires the proxy re-challenges all client requests that do not contain credentials for which an IP surrogate credential cache entry previously existed. If at this point the client supplied a different set of credentials than previously used to authenticate—for which an entry in the user credential cache still exists—the proxy fails authentication. This is to prevent any another client to potentially gain network access by impersonating another user by supplying his or her credentials. However, once the user credential cache entry's TTL has expired, you can supply a different set of credentials than previously used for authentication. 3.

Select the Virtual URL. The default is www.cfauth.com. Blue Coat recommends you change the virtual hostname to something meaningful to you, preferably the IP address of the SG appliance, unless you are doing secure credentials over SSL. Using the IP address of the SG appliance enables you to be sure that the correct SG appliance is addressed in a cluster configuration.

4.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Set Transparent Proxy Options SGOS#(config) security transparent-proxy-auth method {cookie | ip}

36

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

Permitting Users to Login with Authentication or Authorization Failures You can configure policy (VPM or CPL) to attempt user authentication while permitting specific authentication or authorization errors. The policy can specify that, after certain authentication or authorization failures, the user transaction should be allowed to proceed and not be terminated. Note:

For a list of permitted authentication and authorization errors, see Appendix E: "Authentication and Authorization Errors" on page 247.

Permitted Errors Authentication and authorization can be permitted to fail if policy has been written to allow specific failures. The behavior is as follows: ❐

❐

Authentication Failures: After an authentication failure occurs, the authentication error is checked against the list of errors that policy specifies as permitted. •

If the error is not on the list, the transaction is terminated.

•

If the error is on the list, the transaction is allowed to proceed although the user is unauthenticated. Because the transaction is not considered authenticated, the authenticated=yes policy condition evaluates to false and the user has no username, group information, or surrogate credentials. Policy that uses the user, group, domain, or attribute conditions does not match.

Authorization Failures: After an authorization failure occurs, the authorization error is checked against the list of errors that policy specifies as permitted. •

If the error is not on the list, the transaction is terminated.

•

If the error is on the list, the transaction is allowed to proceed and the user is marked as not having authorization data.

•

If a user is successfully authenticated but does not have authorization data, the authenticated=yes condition evaluates to true and the user has valid

authentication credentials. •

The user.authorization_error=any is evaluate to true if user authorization failed, the user object contains username and domain information, but not group or attribute information. As a result, policy using user or domain actions still match, but policy using group or attribute conditions do not.

To view all authentication and authorization errors, use the SGOS# show security authentication-errors CLI command.

Policy Used with Permitted Errors Before creating policy to permit errors, you must: ❐

Identify the type of access the transactions should be permitted.

❐

Identify under which circumstances transactions can proceed even if authentication or authorization fails.

❐

Identify which errors correspond to those circumstances.

37

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies You can use the advanced authentication URL (Statistics > Advanced > Show Authentication Error Statistics as a troubleshooting guide. The policy substitutions $(xsc-authentication-error) and $(x-sc-authorization-error) can also be used to log the errors on a per-transaction basis. Policy conditions and properties that are available include: ❐

authenticate.tolerate_error( )

❐

authorize.tolerate_error( )

❐

user.authentication_error=

❐

user.authorization_error=

❐

has_authorization_data= Note: You are not limited to these conditions and properties in creating policy. For a discussion and a complete list of policy conditions and properties you can use, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

You can also use the following policy substitutions: ❐

x-sc-authentication-error: If authentication has failed, this is the error

corresponding to the failure. If authentication has not been attempted, the value is not_attempted. If authentication has succeeded, the value is none. ❐

x-sc-authorization-error: If authorization has failed, this is the error corresponding to the failure. If authorization has not been attempted, the value is not_attempted. If authorization has succeeded, the value is none.

Using Guest Authentication Using policy (VPM or CPL), you can allow a user to log in as a guest user. Guest authentication allows you to assign a username to a user who would have otherwise been considered unauthenticated. Note: You can use guest authentication with or without default groups. If you use default groups, you can assign guest users to groups for tracking and statistics purposes. For more information about default groups, see “Using Default Groups” on page 39.

In the case of guest authentication, a user is not actually authenticated against the realm, but is: ❐

Assigned the specified guest username

❐

Marked as authenticated in the specified realm

❐

Marked as a guest user

❐

Tracked in access logs

Since the user is not actually authenticated, the username does not have to be valid in that realm.

38

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

Using Policy with Guest Authentication Before creating policy for guest authentication: ❐

Determine the circumstances in which guest access is permitted. Guest users are typically allowed in circumstances where no authentication is needed.

❐

Determine authentication policy. Will the realms attempt to authenticate users first and fallback to guest authentication or authenticate users as guest users without attempting authentication? Note: If a transaction matches both a regular authentication action and guest authentication action, regular authentication is attempted first. This can result in a user challenge before dropping back to guest authentication. If you inadvertently enter invalid credentials and so drop back to guest access, you must log out as guest or close and reopen the browser if using session cookies or connection surrogates. You then can enter the correct credentials to obtain regular access.

Write the corresponding policy. Policy available for guest authentication includes: ❐

authenticate.guest

❐

user.is_guest

❐

authenticated Note: You are not limited to these conditions and properties in creating policy. For a complete list of policy conditions and properties you can use, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

Using Policy Substitutions with Guest Authentication The following policy substitution was created for use with guest authentication. ❐

x-cs-user-type: If the user is an authenticated guest user, the value is guest. If the user is an authenticated non-guest user, the value is authenticated. If the user is not authenticated, the value is unauthenticated.

You are not limited to this substitution, and you can use the substitution in other circumstances. For a complete list of policy substitutions, refer to access log substitutions in Volume 8: Access Logging.

Using Default Groups You can use default groups with any realm, and they can be used when authorization succeeds, fails or wasn't attempted at all. Default groups allow you to assign users to groups and use those groups in reporting and subsequent authorization decisions. Note:

You can use default groups in conjunction with guest users (see “Using Guest Authentication” on page 38) or it can be used with regular user authentication.

39

Chapter 3: Controlling Access to the Internet and Intranet

Section B: Using Authentication and Proxies

Using Policy with Default Groups Before creating policy for default groups, you must determine which set of groups are assigned as default. You can specify a single or multiple groups here. In most cases, only a single group will be required, but occasionally you might need to assign the user to multiple groups: ❐

For extra reporting abilities.

❐

If the policy is structured in a way that users should receive the same access as if they belonged in multiple different groups.

Policy available for default groups includes: ❐

group

❐

authorize.add_group Note: You are not limited to these conditions and properties in creating policy. For a complete list of policy conditions and properties you can use, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

40

Chapter 3: Controlling Access to the Internet and Intranet

Section C: Using SSL with Authentication and Authorization Services

Section C: Using SSL with Authentication and Authorization Services Blue Coat recommends that you use SSL during authentication to secure your user credentials. Blue Coat supports SSL between the client and the SG appliance and between the SG appliance and LDAP and IWA authentication servers.

Using SSL Between the Client and the SG Appliance To configure SSL to use origin-cookie-redirect or origin-ip-redirect challenges, you must: ❐

Specify a virtual URL with the HTTPS protocol (for example, https://virtual_address).

❐

Create a keyring and certificate on the SG appliance.

❐

Create an HTTPS service to run on the port specified in the virtual URL and to use the keyring you just created.

Note: You can use SSL between the client and the SG appliance for origin-style challenges on transparent and explicit connections (SSL for explicit proxy authentication is not supported).

In addition, if you use a forward proxy, the challenge type must use redirection; it cannot be an origin or origin-ip challenge type. When redirected to the virtual URL, the user is prompted to accept the certificate offered by the SG appliance (unless the certificate is signed by a trusted certificate authority). If accepted, the authentication conversation between the SG appliance and the user is encrypted using the certificate. Note: If the hostname does not resolve to the IP address of the SG appliance, then the network configuration must redirect traffic for that port to the appliance. Also, if you use the IP address as the virtual hostname, you might have trouble getting a certificate signed by a CA-Certificate authority (which might not be important).

For information about creating a keyring and a certificate, refer to Volume 2: Proxies and Proxy Services. You can use SSL between the SG appliance and IWA and LDAP authentication servers. For more information, see “SSL Between the SG Appliance and the Authentication Server” on page 12.

41

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations

Section D: 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 about creating effective CPL, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide. Table 3-1. CPL Commands Available in the Layer Layer Conditions

Meaning

admin.access=

Tests the administrative access requested by the current transaction. Can also be used in layers.

attribute.name=

Tests if the current transaction is authenticated in a RADIUS or LDAP realm, and if the authenticated user has the specified attribute with the specified value. Can also be used in layers.

authenticated=

Tests if authentication was requested and the credentials could be verified; otherwise, false. Can also be used in layers.

bitrate=

Tests if a streaming transaction requests bandwidth within the specified range or an exact match. Can also be used in layers.

category=

Tests if the content categories of the requested URL match the specified category, or if the URL has not been categorized. Can also be used in layers.

client_address=

Tests the IP address of the client. Can also be used in layers.

client.connection. negotiated_cipher=

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

client.connection. negotiated_cipher. strength=

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

client.host=

Test the hostname of the client (obtained through RDNS). Can also be used in , , and layers.

client.host.has_name=

Test the status of the RDNS performed to determine 'client.host'. Can also be used in , , and layers.

client_protocol=

Tests true if the client transport protocol matches the specification. Can also be used in layers.

condition=

Tests if the specified defined condition is true. Can be used in all layers.

console_access=

(This trigger was formerly admin=yes|no.) Tests if the current request is destined for the admin layer. Can also be used in and layers.

42

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-1. CPL Commands Available in the Layer (Continued) 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.

ftp.method=

Tests ftp request methods against any of a well-known set of FTP methods. Can also be used in and layers.

group=

Tests if the authenticated condition is set to yes, the client is authenticated, and the client belongs to the specified group. Can also be used in layers.

has_attribute.name=

Tests if the current transaction is authenticated in an LDAP realm and if the authenticated user has the specified LDAP attribute. Can also be used in layers.

hour=

Tests if the time of day is in the specified range or an exact match. Can be used in all layers.

http.method=

Tests HTTP request methods against any of a well known set of HTTP methods. Can also be used in and layers.

http.method.regex=

Test the HTTP method using a regular expression. Can also be used in layers.

http.request_line.regex=

Test the HTTP protocol request line. Can also be used in layers.

http.request.version=

Tests the version of HTTP used by the client in making the request to the SG appliance. 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 SG appliance. 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.

43

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-1. CPL Commands Available in the Layer (Continued) im.chat_room.type=

Tests whether the chat room associated with the transaction is public or private. Can also be used in layers.

im.chat_room.member=

Tests whether the chat room associated with the transaction has a member matching the specified criterion. Can also be used in layers.

im.chat_room.voice_ enabled=

Tests whether the chat room associated with the transaction is voice enabled. Can also be used in layers.

im.client=

Test the type of IM client in use. Can also be used in , , and layers.

im.file.extension=

Tests the file extension. Can also be used in layers.

im.file.name=

Tests the file name (the last component of the path), including the extension. Can also be used in layers.

im.file.path=

Tests the file path against the specified criterion. Can also be used in layers.

im.file.size=

Performs a signed 64-bit range test. Can also be used in layers.

im.message.reflected

Test whether IM reflection occurred. Can also be used in and layers.

im.message.route=

Tests how the IM message reaches its recipients. Can also be used in layers.

im.message.size=

Performs a signed 64-bit range test. Can also be used in layers.

im.message.text. substring=

Performs a signed 64-bit range test. Can also be used in layers.

im.message.opcode=

Tests the value of an opcode associated with an im.method of unknown_send or unknown_receive.

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.

44

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-1. CPL Commands Available in the Layer (Continued) raw_url

Test the value of the raw request URL. Can also be used in layers.

raw_url.host

Test the value of the 'host' component of the raw request URL. Can also be used in layers.

raw_url.path

Test the value of the 'path' component of the raw request URL. Can also be used in layers.

raw_url.pathquery

Test the value of the 'path and query' component of the raw request URL. Can also be used in layers.

raw_url.port

Test the value of the 'port' component of the raw request URL. Can also be used in layers.

raw_url.query

Test the value of the 'query' component of the raw request URL. Can also be used in layers.

realm=

Tests if the authenticated condition is set to yes, the client is authenticated, and the client has logged into the specified realm. an also be used in layers.

release.id=

Tests the SG release ID. Can be used in all layers.

request.header_address. header_name=

Tests if the specified request header can be parsed as an IP address. Can also be used in layers.

request.header.header_ name=

Tests the specified request header (header_name) against a regular expression. Can also be used in layers.

request.header.header_ name.count

Test the number of header values in the request for the given header_name. Can also be used in layers.

request.header.header_ name.length

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

request.header.Referer. url.host.has_name=

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

request.header.Referer. url.is_absolute

Test whether the Referer URL is expressed in absolute form. Can also be used in layers.

request.raw_headers. count

Test the total number of HTTP request headers. Can also be used in layers.

request.raw_headers. length

Test the total length of all HTTP request headers. Can also be used in layers.

request.raw_headers. regex

Test the value of all HTTP request headers with a regular expression. Can also be used in layers.

request.x_header.header_ name.count

Test the number of header values in the request for the given header_name. Can also be used in layers.

request.x_header.header_ name.length

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

response.header.header_ name=

Tests the specified response header (header_name) against a regular expression. Can also be used in layers.

45

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-1. CPL Commands Available in the Layer (Continued) response.x_header. header_name=

Tests the specified response header (header_name) against a regular expression. Can also be used in layers.

server_url[.case_ sensitive|.no_lookup]=

Tests if a portion of the requested URL exactly matches the specified pattern. Can also be used in layers.

socks.accelerated=

Controls the SOCKS proxy handoff to other protocol agents.

socks.method=

Tests the protocol method name associated with the transaction. Can also be used in and layers.

socks.version=

Switches between SOCKS 4/4a and 5. Can also be used in and layers.

streaming.content=

(This trigger has been renamed from streaming.) Can also be used in , , and layers.

time=

Tests if the time of day is in the specified range or an exact match. Can be used in all layers.

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

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.

46

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-1. CPL Commands Available in the Layer (Continued) 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 IWA 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 3-2. Properties Available in the Layer 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 IWA uses connection surrogate credentials. In sg2.mode, explicit IWA uses IP surrogate credentials.

authenticate.redirect_ stored_requests

Sets whether requests stored during forms-based authentication can be redirected if the upstream host issues a redirecting response.

bypass_cache( )

Determines whether the cache is bypassed for a request.

check_authorization( )

In connection with CAD (Caching Authenticated Data) and CPAD (Caching Proxy Authenticated Data) support, check_authorization( ) is used when you know that the upstream device will sometimes (not always or never) require the user to authenticate and be authorized for this object. Can also be used in layers.

47

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-2. Properties Available in the Layer (Continued) delete_on_abandonment( )

If set to yes, then if all clients requesting an object close their connections prior to the object being delivered, the object fetch from the origin server is abandoned. Can also be used in layers.

deny

Denies service. Can be used in all layers except and layers.

dynamic_bypass( )

Used to indicate that a particular transparent request should not be handled by the proxy, but instead be subjected to our dynamic bypass methodology.

exception( )

Indicates not to serve the requested object, but instead serve this specific exception page. Can be used in all layers except layers.

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.

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.

48

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations Table 3-2. Properties Available in the Layer (Continued) 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 3-3. Actions Available in the Layer Layer Actions

Meaning

log_message( )

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

notify_email( )

Sends an e-mail notification to the list of recipients specified in the Event Log mail configuration. Can be used in all layers.

notify_snmp( )

The SNMP trap is sent when the transaction terminates. Can be used in all layers.

redirect( )

Ends the current HTTP transaction and returns an HTTP redirect response to the client.

transform

Invokes the active content or URL rewrite transformer.

49

Chapter 3: Controlling Access to the Internet and Intranet

Section D: Creating a Proxy Layer to Manage Proxy Operations

50

Chapter 4: Understanding and Managing X.509 Certificates

Blue Coat uses certificates for various applications, including: ❐

authenticating the identity of a server

❐

authenticating an SG appliance

❐

securing an intranet

❐

encrypting data

The certificates Blue Coat uses are X.509 certificates. X.509 is a cryptographic standard for public key infrastructure (PKI) that specifies standard formats for public key certificates. Several RFCs and books exist on the public key cryptographic system (PKCS). This discussion of the elements of PKCS is relevant to their implementation in SGOS. ❐

Section A: "Concepts" on page 52

❐

"Section B: Using Keyrings and SSL Certificates" on page 55

❐

Section C: "Managing Certificates" on page 59

❐

Section D: "Using External Certificates" on page 65

❐

"Section E: Advanced Configuration" on page 67

51

Volume 4: Securing the Blue Coat SG Appliance Section A: Concepts

Section A: Concepts This section discusses concepts surrounding certificates and SGOS.

Public Keys and Private Keys In PKCS systems, the intended recipient of encrypted data generates a private/public keypair, and publishes the public key, keeping the private key secret. The sender encrypts the data with the recipient's public key, and sends the encrypted data to the recipient. The recipient uses the corresponding private key to decrypt the data. For two-way encrypted communication, the endpoints can exchange public keys, or one endpoint can choose a symmetric encryption key, encrypt it with the other endpoint's public key, and send it.

Certificates The SGOS software uses: ❐

SSL Certificates.

❐

CA Certificates.

❐

External Certificates.

You can also use wildcard certificates during HTTPS termination. 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. Any SSL certificate can contain a common name with wildcard characters.

SSL Certificates SSL certificates are used to authenticate the identity of a server or a client. A certificate is confirmation of the association between an identity (expressed as a string of characters) and a public key. If a party can prove they hold the corresponding private key, you can conclude that the party is who the certificate says it is. The certificate contains other information, such as its expiration date. The association between a public key and a particular server is done by generating a certificate signing request using the server's or client’s public key. A certificate signing authority (CA) verifies the identity of the server or client and generates a signed certificate. The resulting certificate can then be offered by the server to clients (or from clients to servers) who can recognize the CA's signature. Such use of certificates issued by CAs has become the primary infrastructure for authentication of communications over the Internet. The SG trusts all root CA certificates trusted by Internet Explorer and Firefox. The list is updated periodically to be in sync with the latest versions of IE and Firefox. CA certificates installed on the SG are used to verify the certificates presented by HTTPS servers and the client certificates presented by browsers. Browsers offer a certificate if the server is configured to ask for one and an appropriate certificate is available to the browser.

52

Chapter 4: Understanding and Managing X.509 Certificates

Section A: Concepts

CA Certificates CA certificates are certificates that belong to certificate authorities. CA certificates are used by SGdevices to verify X.509 certificates presented by a client or a server during secure communication. SG appliances are pre-installed with the most common CA certificates. SG appliances come with many popular CA certificates already installed. You can review these certificates using the Management Console or the CLI. You can also add certificates for your own internal certificate authorities.

External Certificates An external certificate is any X509 certificate for which the SG appliance does not have the private key. The certificate can be used to encrypt data, such as access logs, with a public key so that it can only be decrypted by someone who has the corresponding private key. Refer to Volume 8: Access Logging for information about encrypting access logs.

Keyrings A keyring contains a public/private keypair. It can also contain a certificate signing request or a signed certificate. Keyrings are named, can be created, deleted and viewed; there are built-in keyrings for specified purposes. For information on managing keyrings, see Section B: "Using Keyrings and SSL Certificates" on page 55.

Cipher Suites Supported by SGOS Software A cipher suite specifies the algorithms used to secure an SSL connection. When a client makes an SSL connection to a server, it sends a list of the cipher suites that it supports. The server compares this list with its own supported cipher suites and chooses the first cipher suite proposed by the client that they both support. Both the client and server then use this cipher suite to secure the connection. Note:

You can delete cipher suites that you do not trust. However, SGOS does not provide any mechanism to change the ordering of the ciphers used. All cipher suites supported by the SG appliance 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 SG appliance is configured to allow SSLv2 and v3 as well as TLSv1 traffic. The cipher suites available for use differ depending on whether you configure SSL for version 2, version 3, TLS, or a combination of these. Table 4-1. Cipher Suites Shipped with the SG Appliance 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.

53

Volume 4: Securing the Blue Coat SG Appliance Section A: Concepts Table 4-1. Cipher Suites Shipped with the SG Appliance (Continued) SGOS Cipher #

Cipher Name

Strength

Exportable

Description

4

DES-CBC3-MD5

High

No

168-bit key size.

5

RC2-CBC-MD5

Medium

No

128-bit key size.

6

RC4-64-MD5

Low

No

64-bit key size.

7

DES-CBC-SHA

Low

No

56-bit key size.

8

DES-CBC-MD5

Low

No

56-bit key size.

9

EXP1024-RC4-MD5

Export

Yes

56-bit key size.

10

EXP1024-RC4-SHA

Export

Yes

56-bit key size.

11

EXP1024-RC2-CBC-MD5

Export

Yes

56-bit key size.

12

EXP1024-DES-CBC-SHA

Export

Yes

56-bit key size.

13

EXP-RC4-MD5

Export

Yes

40-bit key size.

14

EXP-RC2-CBC-MD5

Export

Yes

40-bit key size.

15

EXP-DES-CBC-SHA

Export

Yes

40-bit key size.

16

AES128-SHA

Medium

No

128-bit key size.

17

AES256-SHA

High

No

256-bit key size.

Cipher Suite configuration is discussed in “Changing the Cipher Suites of the SSL Client” on page 234.

Server-Gated Cryptography and International Step-Up Due to US export restrictions, international access to a secure site requires that the site negotiates 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. SGOS 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, SGOS supports VeriSign's Global ID Certificate product. The Global ID certificate contains the extra information necessary to implement SGC and International Step-up.

54

Chapter 4: Understanding and Managing X.509 Certificates

Section B: Using Keyrings and SSL Certificates

Section B: Using Keyrings and SSL Certificates Keyrings are virtual containers, holding a public/private keypair with a customized keylength and a certificate or certificate signing request. Certificates can be meant for internal use (self-signed) or they can be meant for external use. In general, SSL certificates involve three parties: ❐

The subject of the certificate.

❐

The Certificate Authority (CA), which signs the certificate, attesting to the binding between the public key in the certificate and the subject.

❐

The "relying party,” which is the entity that trusts the CA and relies on the certificate to authenticate the subject.

Keyrings and certificates are used in: ❐

Encrypting data.

❐

Digitally Signing Access Logs.

❐

Authenticating end users.

❐

Authenticating an SG appliance.

The steps in creating keyrings and certificates include: ❐

Create a keyring. A default keyring is shipped with the system and is used for accessing the Management Console, although you can use others. You can also use the default keyring for other purposes. You can create other keyrings for each SSL service. (See “Creating a Keyring” on page 56.) Note: You can also import keyrings. For information on importing keyrings, see “Importing an Existing Keypair and Certificate” on page 67.

❐

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

❐

Import X.509 certificates issued by trusted CA authorities for external use and associate them with the keyring. (See “Managing SSL Certificates” on page 60.) -orCreate certificates and associate them with the keyring. (See “Creating Self-Signed SSL Certificates” on page 61.)

❐

(Optional, if using SSL Certificates from CAs) Import Certificate Revocation Lists (CRLs) so the SG appliance can verify that certificates are still valid.

❐

Creating an HTTP Reverse Proxy Service and associating the keyring with the service. (Refer to Volume 2: Proxies and Proxy Services.)

Note: These steps must be done using a secure connection such as HTTPS, SSH, or a

serial console.

55

Volume 4: Securing the Blue Coat SG Appliance Section B: Using Keyrings and SSL Certificates

Creating a Keyring The SG appliance ships with three keyrings already created: ❐

default: The default keyring contains a certificate and an automatically-generated keypair. The default keyring is intended for securely accessing the SG appliance Management Console. Create an additional keyring for each HTTPS service defined.

❐

configuration-passwords-key: The configuration-passwords-key keyring contains a keypair but does not contain a certificate. This keyring is used to encrypt passwords in the show config command and should not be used for other purposes.

❐

appliance-key: The appliance-key keyring contains an internally-generated keypair. If the SG appliance is authenticated (has obtained a certificate from the Blue Coat CA appliance-certificate server), that certificate is associated with this keyring, which is used to authenticate the device. (For more information on authenticating the SG appliance, refer to Volume 5: Advanced Networking.) Note:

The appliance-key keyring is used by the system. It is not available for other purposes. If an origin content server requires a client certificate and no keyring is associated with the SG appliance SSL client, the HTTPS connections fails. For information on using the SSL client, see Appendix C: "Managing the SSL Client" on page 233. To create a keyring: 1.

Select Configuration > SSL > Keyrings > SSL Keyrings.

2.

Click Create; the Create Keyring dialog appears.

56

Chapter 4: Understanding and Managing X.509 Certificates

Section B: Using Keyrings and SSL Certificates

3.

Fill in the pane: •

Keyring Name: Give the keyring a meaningful name. Note: Spaces in keyring names are not supported. Including a space can cause unexpected errors while using such keyrings.

•

Select the show option you need: •

Show keypair allows the keys to be viewed and exported.

•

Do not show keypair prevents the keypair from being viewed or exported.

•

Show keypair to director is a keyring viewable only if Director is issuing the

command using a SSH-RSA connection. Note: The choice among show, do not show keypair, and show keypair to director has implications for whether keyrings are included in profiles and

backups created by Director. For more information, refer to the Blue Coat Director User Guide. •

Select the key length in the Create a new ______ -bit keyring field. A length of 1024 bits is the maximum (and default). For deployments reaching outside the U.S., determine the maximum key length allowed for export. Click OK. The keyring is created with the name you chose. It does not have a certificate associated with it yet. To associate a certificate, see “Importing a Server Certificate” on page 62. -or-

•

Select the Import keyring radio button.

57

Volume 4: Securing the Blue Coat SG Appliance Section B: Using Keyrings and SSL Certificates The grayed-out Keyring field becomes enabled, allowing you to paste in an already existing private key. Any certificate or certificate request associated with this private key must be imported separately. For information on importing a certificate, see “Importing a Server Certificate” on page 62. If the private key that is being imported has been encrypted with a password, select Keyring Password and enter the password into the field. Note: The only way to retrieve a keyring's private key from the SG appliance is by using Director or the command line —it cannot be exported through the Management Console.

4.

Click OK.

To view or edit a keyring: 1.

Select Configuration > SSL > Keyrings > SSL Keyrings.

2.

Click View/Edit.

Related CLI Syntax to Create an SSL Keyring SGOS#(config) ssl SGOS#(config ssl) create keyring {show | show-director | no-show} keyring_id [key_length]

Notes ❐

To view the keypair in an encrypted format, you can optionally specify des or des3 before the keyring_id, along with an optional password. If the optional password is provided on the command line, the CLI does not prompt for a password.

❐

If the optional password is not provided on the command line, the CLI asks for the password (interactive). If you specify either des or des3, you are prompted.

❐

To view the keypair in unencrypted format, select either the optional keyring_id or use the unencrypted command option.

❐

You cannot view a keypair over a Telnet connection because of the risk that it could be intercepted.

Deleting an Existing Keyring and Certificate To delete a keyring and the associated certificate: 1.

Select Configuration > SSL > Keyrings > SSL Keyrings.

2.

Highlight the name of the keyring to delete.

3.

Click Delete. The Confirm delete dialog appears.

4.

Click OK in the Confirm delete dialog.

Related CLI Syntax to Delete a Keyring and the Associated Certificate SGOS#(config) ssl SGOS#(config ssl) delete keyring keyring_id

58

Chapter 4: Understanding and Managing X.509 Certificates

Section C: Managing Certificates

Section C: Managing Certificates This section discusses how to manage certificates, from obtaining certificate signing requests to using certificate revocation lists. In this section are: ❐

“Managing Certificate Signing Requests”

❐

“Managing SSL Certificates” on page 60

❐

“Using Certificate Revocation Lists” on page 62

❐

“Troubleshooting Certificate Problems” on page 64

Managing Certificate Signing Requests Certificate signing requests (CSRs) are used to obtain a certificate signed by a Certificate Authority. You can also create CSRs off box.

Creating a CSR To create a CSR: 1.

Select Configuration > SSL > SSL Keyrings; click Edit/View.

2.

From the drop-down list, select the keyring for which you need a signed certificate.

3.

From the Certificate Signing Request tab, click the Create button.

4.

Fill in the fields: •

State/Province—Enter the state or province where the machine is located.

•

Country Code—Enter the two-character ISO code of the country.

•

City/Locality—Enter the city.

•

Organization—Enter the name of the company.

•

Unit—Enter the name of the group that is managing the machine.

•

Common Name—Enter the URL of the company.

•

Challenge—Enter a 4-16 character alphanumeric challenge.

59

Volume 4: Securing the Blue Coat SG Appliance Section C: Managing Certificates •

E-mail Address—The e-mail address you enter must be 40 characters or less. A longer e-mail address generates an error.

•

Company—Enter the name of the company.

5.

The Create tab displays the message: Creating....

6.

Click OK.

Related CLI Syntax to Create a CSR SGOS#(config) ssl SGOS#(config ssl) create signing-request keyring_id SGOS#(config ssl) create signing-request keyring_id [attribute_value] [attribute_value]

Viewing a Certificate Signing Request Once a CSR is created, you must submit it to a CA in the format the CA requires. You can view the output of a certificate signing request either through the Management Console or the CLI. To view the output of a certificate signing request: 1.

Select Configuration > SSL > SSL Keyrings.

2.

Click Edit/View.

3.

From the drop-down list, select the keyring for which you have created a certificate signing request. The certificate signing request displays in the Certificate Signing Request window and can be copied for submission to a CA.

Managing SSL Certificates SSL certificates can be obtained two ways: ❐

Created on the SG appliance as a self-signed certificate To create a SSL self-signed certificate on the SG appliance using a Certificate Signing Request, continue with the next section.

❐

Imported after receiving the certificate from the signing authority If you plan to use SSL certificates issued by Certificate Authorities, the procedure is: •

Obtain the keypair and Certificate Signing Requests (CSRs), either off box or on box, and send them to the Certificate Authority for signing.

•

After the signed request is returned to you from the CA, you can import the certificate into the SG appliance. To import a certificate, see “Importing a Server Certificate” on page 62.

60

Chapter 4: Understanding and Managing X.509 Certificates

Section C: Managing Certificates

Note: If a Website presents a certificate that is signed by a CA not on Blue Coat default

CA list, you might see the following message: Network Error (ssl_failed) A secure SSL session could not be established with the Web Site:

You must import the CA Certificate onto the SG appliance before the device can trust the site.

To import an SSL Certificate, skip to “Importing a Server Certificate” on page 62.

Creating Self-Signed SSL Certificates The SG appliance ships with a self-signed certificate, associated with the default keyring. Only one certificate can be associated with a keyring. If you have multiple uses, use a different keyring and associated certificate for each one.

Adding a Self-Signed SSL Certificate Self-signed certificates are generally meant for intranet use, not Internet. To create a self-signed certificate: 1.

Select Configuration > SSL > Keyrings > SSL Keyrings.

2.

Highlight the keyring for which you want to add a certificate.

3.

Click Edit/View in the Keyring tab.

4.

Click Create.

5.

Fill in the fields: •

State/Province—Enter the state or province where the machine is located.

•

Country Code—Enter the two-character ISO code of the country.

•

City/Locality—Enter the city.

•

Organization—Enter the name of the company.

61

Volume 4: Securing the Blue Coat SG Appliance Section C: Managing Certificates •

Unit—Enter the name of the group that is managing the machine.

•

Common Name—A common name should be the one that contains the URL with

client access to that particular origin server. •

Challenge—Enter a 4-16 character alphanumeric challenge.

•

E-mail Address—The e-mail address you enter must be 40 characters or less. A

longer e-mail address generates an error. • 6.

Company—Enter the name of the company.

The Create tab displays the message: Creating.....

Related CLI Syntax to Create a Self-Signed SSL Certificate SGOS#(config ssl) create certificate keyring_id SGOS#(config ssl) create certificate keyring-id [attribute_value] [attribute_value]

Example: SGOS#(config ssl) create certificate keyring-id cn bluecoat challenge test c US state CA company bluecoat

Importing a Server Certificate After the CA signs the server certificate and returns it to you, you can import the certificate onto the SG appliance. To import a server certificate: 1.

Copy the certificate to your clipboard. Be sure to include the “Begin Certificate” and “End Certificate” statements.

2.

Select Configuration > SSL > Keyrings.

3.

Highlight the keyring for which you want to import a certificate.

4.

Click Edit/View in the Keyrings tab.

5.

In the Certificate panel, click Import.

6.

Paste the certificate you copied into the dialog box. Click OK. The certificate should display in the SSL Certificates Pane, associated with the keyring you selected earlier.

Using Certificate Revocation Lists Certificate Revocation Lists (CRLs) enable checking server and client certificates against lists provided and maintained by CAs that show certificates that are no longer valid. Only CRLs that are issued by a trusted issuer can be successfully verified by the SG appliance. The CRL can be imported only when the CRL issuer certificate exists as a CA certificate on the SG appliance. You can determine if the SG appliance SSL certificates are still valid by checking Certificate Revocation Lists (CRLs) that are created and issued by trusted Certificate Signing Authorities. A certificate on the list is no longer valid.

62

Chapter 4: Understanding and Managing X.509 Certificates

Section C: Managing Certificates Only CRLs that are issued by a trusted issuer can be verified by the SG appliance successfully. The CRL can be imported only when the CRL issuer certificate exists as a CA certificate on the SG appliance. SGOS allows: ❐

One local CRL list per certificate issuing authority.

❐

An import of a CRL that is expired; a warning is displayed in the log.

❐

An import of a CRL that is effective in the future; a warning is displayed in the log.

CRLs can be used for the following purposes: ❐

Checking revocation status of client or server certificates with HTTPS Reverse Proxy.

❐

Checking revocation status of client or server certificates with SSL proxy. (For more information on using CRLS with the SSL proxy, refer to Volume 2: Proxies and Proxy Services.)

❐

SG appliance-originated HTTPS downloads (secure image download, content filter database download, and the like).

❐

PEM-encoded CRLs, if cut and pasted through the inline command.

❐

DER-format (binary) CRLs, if downloaded from a URL.

To import a CRL: You can choose from among four methods to install a CRL on the SG appliance: ❐

Use the Text Editor, which allows you to enter the installable list (or copy and paste the contents of an already-created file) directly onto the SG appliance.

❐

Create a local file on your local system.

❐

Enter a remote URL, where you placed an already-created file on an FTP or HTTP server to be downloaded to the SG appliance.

❐

Use the CLI inline command.

To update a CRL: 1.

Select Configuration > SSL > CRLs.

2.

Click New or highlight an existing CRL and click Edit.

3.

Give the CRL a name.

4.

From the drop-down list, select the method to use to install the CRL; click Install. •

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

•

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

63

Volume 4: Securing the Blue Coat SG Appliance Section C: Managing Certificates •

Text Editor:

Copy a new CRL file into the window, and click Install. When the installation is complete, a results window opens. View the results, close the window, click Close. Note: The Management Console text editor can be used to enter a CRL file. You

cannot use it to enter CLI commands. 5.

Click OK; click Apply

Related CLI Syntax to Create a CRL At the (config) command prompt, enter the following commands: SGOS#(config) ssl SGOS#(config ssl) create crl list_name or SGOS#(config) ssl SGOS#(config ssl) inline crl CRL_list_name eof Paste CRL here eof

Troubleshooting Certificate Problems Two common certificate problems are discussed below. ❐

If the client does not trust the Certificate Signing Authority that has signed the appliance’s certificate, an error message similar to the following appears in the event log: 2004-02-13 07:29:28-05:00EST "CFSSL:SSL_accept error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown" 0 310000:1 ../cf_ssl.cpp:1398

This commonly occurs when you use the HTTPS-Console service on port 8082, which uses a self-signed certificate by default. When you access the Management Console over HTTPS, the browser displays a pop-up that says that the security certificate is not trusted and asks if you want to proceed. If you select No instead of proceeding, the browser sends an unknown CA alert to the SG appliance. You can eliminate the error message one of two ways:

❐

•

If this was caused by the Blue Coat self-signed certificate (the certificate associated with the default keyring), import the certificate as a trusted Certificate Signing Authority certificate . See “Importing a Server Certificate” on page 62 for more information.

•

Import a certificate on the SG appliance for use with HTTPS-Console that is signed by a CA that a browser already trusts.

If the SG appliance’s certificate is not accepted because of a host name mismatch or it is an invalid certificate, you can correct the problem by creating a new certificate and editing the HTTPS-Console service to use it. For information on editing the HTTPSConsole service, refer to Volume 2: Proxies and Proxy Services.

64

Chapter 4: Understanding and Managing X.509 Certificates

Section D: Using External Certificates

Section D: Using External Certificates External certificates are certificates for which Blue Coat does not have the private key. The first step in using external certificates is to import the certificates onto the SG appliance.

Importing and Deleting External Certificates To Import an external certificate: 1.

Copy the certificate onto the clipboard.

2.

Select Configuration > SSL > External Certificates.

3.

Click Import.

4.

Enter the name of the external certificate into the External Cert Name field and paste the certificate into the External Certificate field. Be sure to include the ----BEGIN CERTIFICATE---- and -----END CERTIFICATE---- statements.

5.

Click OK.

Deleting an External Certificate To delete an external certificate: 1.

Select Configuration>SSL>External Certificates.

2.

Highlight the name of the external certificate to be deleted.

3.

Click Delete.

4.

Click OK in the Confirm delete dialog that appears;

5.

Click Apply to commit the changes to the SG appliance.

65

Volume 4: Securing the Blue Coat SG Appliance Section D: Using External Certificates

Digitally Signing Access Logs You can digitally sign access logs to certify that a particular SG appliance wrote and uploaded a specific log file. Signing is supported for both content types—text and gzip— and for both upload types—continuous and periodic. Each log file has a signature file associated with it that contains the certificate and the digital signature used for verifying the log file. When you create a signing keyring (which must be done before you enable digital signing), keep in mind the following: ❐

The keyring must include a certificate. .

❐

The certificate purpose must be set for smime signing. If the certificate purpose is set to anything else, you cannot use the certificate for signing.

❐

Add the %c parameter in the filenames format string to identify the keyring used for signing. If encryption is enabled along with signing, the %c parameter expands to keyringName_Certname.

For more information about digitally signing access logs, refer to Volume 8: Access Logging.

66

Chapter 4: Understanding and Managing X.509 Certificates

Section E: Advanced Configuration

Section E: Advanced Configuration This section includes the following topics: ❐

“Importing an Existing Keypair and Certificate”

❐

“About Certificate Chains” on page 69

❐

“Importing a CA Certificate” on page 69

❐

“Creating CA Certificate Lists” on page 70

Importing an Existing Keypair and Certificate If you have a keypair and certificate used on one system, you can import the keypair and certificate for use on a different system. You can also import a certificate chain containing multiple certificates. Use the inline certificate command to import multiple certificates through the CLI. If you are importing a keyring and one or more certificates onto an SG appliance, first import the keyring, followed by the related certificates. The certificates contain the public key from the keyring, and the keyring and certificates are related. To Import a keyring: 1.

Copy the already-created keypair onto the clipboard.

2.

Select Configuration > SSL > Keyrings > SSL Keyrings.

3.

Click Create.

67

Volume 4: Securing the Blue Coat SG Appliance Section E: Advanced Configuration 4.

Fill in the dialog window as follows: a.

Show keypair allows the keys to be exported.

b.

Do not show keypair prevents the keypair from being exported.

c.

Show keypair to director is a keyring viewable only if Director is issuing the

command using a SSH-RSA connection. Note: The choice among show, do not show and show keypair to director has implications for whether keyrings are included in profiles and backups created by Director. For more information, refer to the Blue Coat Director Configuration and Management Guide.

d. Select the Import keyring radio button. The grayed-out Keyring field becomes enabled, allowing you to paste in the already existing keypair. The certificate associated with this keypair must be imported separately. If the keypair that is being imported has been encrypted with a password, select Keyring Password and enter the password into the field. 5.

Click OK.

To import a certificate and associate it with a keyring: 1.

Copy the certificate onto the clipboard.

2.

Select Configuration > SSL > Keyrings and click Edit/View.

3.

From the drop-down list, select the keyring that you just imported.

4.

Click Import in the Certificate field.

5.

Paste the certificate into the Import Certificate dialog that appears. Be sure to include the ----BEGIN CERTIFICATE---- and -----END CERTIFICATE---- statements.

6.

Click OK.

Related CLI Syntax to Import a Keyring SGOS#(config ssl) inline {keyring show | show-director | no-show} keyring_id eof Paste keypair here eof

Related CLI Syntax to Import a Certificate and Associate it with a Keyring SGOS#(config) ssl SGOS#(config ssl) inline certificate keyring_id eof Paste certificate here eof

68

Chapter 4: Understanding and Managing X.509 Certificates

Section E: Advanced Configuration

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 trusted CA. Expiration is done at the single certificate level and is checked independently of the chain verification. Each certificate in the chain must be valid for the entire chain to be valid. You can import a certificate chain containing multiple certificates. The valid certificate chain can be presented to a browser. To get the SG appliance to present a valid certificate chain, the keyring for the HTTPS service must be updated. The appliance's CA-certificate list must also be updated if the SG appliance uses HTTPS to communicate with the origin server and if the SG appliance is configured, through the ssl-verify-server option, to verify the certificate (chain) presented by HTTPS server. If the SG appliance uses HTTP to communicate with the origin server, updating the CAcertificate list has no effect.

Importing a CA Certificate A CA Certificate is a certificate that verifies the identity of a Certificate Authority. The certificate is used by the SG appliance to verify server and client certificates. To import an approved CA certificate: 1.

Copy the certificate to the clipboard.

2.

Select Configuration > SSL > CA Certificates > CA Certificates.

3.

Click Import.

4.

Give the certificate a name.

.

Note: Spaces in CA Certificate names are not supported. Including a space can cause unexpected errors while using such certificates.

5.

Paste the signed CA Certificate into the Import CA Certificate field.

6.

Click OK.

69

Volume 4: Securing the Blue Coat SG Appliance Section E: Advanced Configuration To view a CA certificate: 1.

Select Configuration > SSL > CA Certificates > CA Certificates.

2.

Select the certificate you want to view.

3.

Click View.Examine the contents and click Close.

To delete a CA certificate: 1.

Select Configuration > SSL > CA Certificates > CA Certificates.

2.

Select the certificate to delete.

3.

Click Delete.

4.

Click OK.

Related CLI Syntax to Import a CA Certificate SGOS#(config) ssl SGOS#(config ssl) inline ca-certificate ca_certificate_name eof Paste certificate here eof

Creating CA Certificate Lists A CA certificate list can refer to any subset of the available CA Certificates on the SG appliance. When configuring an HTTPS service to do HTTPS Reverse Proxy, this list can be specified to restrict the set of certificate authorities that are trusted to validate client certificates presented to that service. The default is that no list is configured; all certificates are used in authentication. To create a CA-Certificate list: 1.

Select Configuration > SSL > CA Certificates > CA Certificate Lists.

2.

Click New to create a new list.

3.

Enter a meaningful name for the list in the CA-Certificate List Name field.

4.

To add CA Certificates to the list, highlight the certificate and click Add. You cannot add a certificate to a certificate list if it is not already present.

70

Chapter 4: Understanding and Managing X.509 Certificates

Section E: Advanced Configuration 5.

To remove CA Certificates from the list, highlight the certificate in the Add list and click Remove.

6.

Click OK

Related CLI Syntax to Manage CA-Certificate Lists ❐

To enter configuration mode: SGOS#(config ssl) create ccl list_name SGOS#(config ssl) edit ccl list_name

❐

The following subcommands are available: SGOS#(config ssl ccl list_name) add ca_cert_name SGOS#(config ssl) delete ca-certificate ca_certificate_name

To import a CA certificate: 1.

Copy the certificate to your clipboard. Be sure to include the “Begin Certificate” and “End Certificate” statements.

2.

Select Configuration > SSL > Keyrings.

3.

Highlight the keyring for which you want to import a certificate.

4.

Click Edit/View in the Keyrings tab.

5.

In the Certificate panel, click Import.

6.

Paste the certificate you copied into the dialog box. Click OK. The certificate should display in the SSL Certificates Pane, associated with the keyring you selected earlier.

7.

Click Apply to commit the changes to the SG appliance.

71

Volume 4: Securing the Blue Coat SG Appliance Section E: Advanced Configuration

72

Chapter 5: Certificate Realm Authentication

Certificate realms are useful for companies that have a Public Key Infrastructure (PKI) in place and would like to have the SG appliance authenticate their end-users using the client's X.509 certificates. 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” on page 74

❐

“Defining a Certificate Realm” on page 74

❐

“Defining Certificate Realm General Properties” on page 75

❐

“Revoking User Certificates” on page 76

How Certificate Realm Works Once an SSL session has been established, the user is asked to select the certificate to send to the SG appliance. If the certificate was signed by a Certificate Signing Authority that the SG appliance trusts, including itself, then the user is considered authenticated. The username for the user is the one extracted from the certificate during authentication. At this point the user is authenticated. If an authorization realm has been specified, such as LDAP or Local, the certificate realm then passes the username to the specified authorization realm, which figures out which groups the user belongs to. Note:

If you authenticate with a certificate realm, you cannot also challenge for a password. Certificate realms do not require an authorization realm. If no authorization realm is configured, the user cannot be a member of any group. You do not need to specify an authorization realm if: ❐

The policy does not make any decisions based on groups

❐

The policy works as desired when all certificate realm-authenticated users are not in any group

To use a Certificate Realm, you must: ❐

Configure SSL between the client and SG appliance (for more information, see “Using SSL with Authentication and Authorization Services” on page 41).

❐

Enable verify-client on the HTTPS service to be used (for more information, refer to Volume 2: Proxies and Proxy Services).

❐

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

73

Volume 4: Securing the Blue Coat SG Appliance

Creating a Certificate Realm To create a certificate realm: 1.

Select Configuration > Authentication > Certificate > Certificate Realms.

2.

Click New.

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Defining a Certificate Realm To define certificate authentication properties: 1.

Select Configuration > Authentication > Certificate > Certificate Main.

2.

From the Realm name drop-down list, select the Certificate realm for which you want to change realm properties.

3.

(Optional) From the Authorization Realm Name drop-down list, select the LDAP or Local realm you want to use to authorize users.

4.

From the username attribute field, enter the attribute that specifies the common name in the subject of the certificate. CN is the default.

5.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the list of attributes (the container attribute field) that should be used to construct the user's distinguished name. For example, $(OU) $(O) substitutes the OU and O fields from the certificate.

6.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Select or deselect Append Base DN.

74

Chapter 5: Certificate Realm Authentication

7.

(Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the Base DN where the search starts. If no BASE DN is specified and Append Base DN is enabled, the first Base DN defined in the LDAP realm used for authorization is appended.

Defining Certificate Realm General Properties The Certificate General tab allows you to specify the display name, the refresh times, an inactivity timeout value, cookies, and a virtual URL. To configure certificate realm general settings: 1.

Select Configuration > Authentication > Certificate > Certificate General.

2.

From the Realm name drop-down list, select the Certificate realm for which to change properties.

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 greater than 128 characters and it cannot be null.

4.

Select the Use the same refresh time for all check box if you would like to use the same refresh time for all.

5.

Enter the number of seconds in the Surrogate refresh time field. The Surrogate Refresh Time allows you to set a realm default for how often a user’s surrogate credentials are refreshed. Surrogate credentials are credentials accepted in place of a user’s actual credentials. The default setting is 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, if a surrogate (IP address or cookie) is available and it matches the expected surrogate, the SG appliance authenticates the transaction. After the refresh time expires, the SG appliance will verify the user’s certificate.

6.

Enter the number of seconds in the Authorization refresh time field. The Authorization Refresh Time allows you to manage how often the authorization data is verified with the authentication realm. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here.

75

Volume 4: Securing the Blue Coat SG Appliance

7.

Type the number of seconds in the Inactivity timeout field to specify the amount of time a session can be inactive before being logged out.

8.

Select the Use persistent cookies check box to use persistent browser cookies instead of session browser cookies.

9.

Select the Verify the IP address in the cookie check box if you would like the cookies surrogates to only be accepted for the IP address that the cookie was authenticated. Disabling this will allow cookies to be accepted from other IP addresses.

10. You can specify a virtual URL. For more information on the virtual URL, see “Understanding Origin-Style Redirection” on page 34. 11. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Configure a Certificate Realm ❐

To enter configuration mode: SGOS#(config) security certificate create-realm realm_name SGOS#(config) security certificate edit-realm realm_name

❐

The following commands are available: SGOS#(config certificate realm_name) inactivity-timeout seconds SGOS#(config certificate realm_name) refresh-time surrogate-refresh seconds SGOS#(config certificate realm_name) refresh-time authorizationrefresh seconds SGOS#(config certificate realm_name) cookie {persistent {enable | disable} | verify-ip {enable | disable}} SGOS#(config certificate realm_name) virtual-url url

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 SG appliance; it is not updated automatically. Note: This method of revoking user certificates is meant for those with a small number of

certificates to manage. For information on using automatically updated lists, refer to Volume 2: Proxies and Proxy Services. 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.

76

Chapter 5: Certificate Realm Authentication

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

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 Volume 10: Blue Coat SG Appliance 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 SGOS 5.x systems, the default policy condition is deny. ❐

Every Certificate realm authenticated user is allowed access the SG appliance. 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

77

Volume 4: Securing the Blue Coat SG Appliance

Tips If you use a certificate realm and see an error message similar to the following Realm configuration error for realm "cert": connection is not SSL.

This means that certificate authentication was requested for a transaction, but the transaction was not done on an SSL connection, so no certificate was available. This can happen in three ways: ❐

The authenticate mode is either origin-IP-redirect/origin-cookie-redirect or origin-IP/origin-cookie, but the virtual URL does not have an https: scheme. This is likely if authentication through a certificate realm is selected with no other configuration, because the default configuration does not use SSL for the virtual URL.

❐

In a server accelerator deployment, the authenticate mode is origin and the transaction is on a non-SSL port.

❐

The authenticate mode is origin-IP-redirect/origin-cookie-redirect, the user has authenticated, the credential cache entry has expired, and the next operation is a POST or PUT from a browser that does not handle 307 redirects (that is, from a browser other than Internet Explorer). The workaround is to visit another URL to refresh the credential cache entry and then try the POST again.

❐

Forms authentication modes cannot be used with a Certificate realm. If a form mode is in use and the authentication realm is a Certificate realm, a Policy Substitution realm, or an IWA realm, you receive a configuration error.

78

Chapter 6: Oracle COREid Authentication

The SG appliance can be configured to consult an Oracle COREid (formerly known as Oracle NetPoint) Access Server for authentication and session management decisions. This requires that a COREid realm be configured on the SG appliance and policy written to use that realm for authentication. The SG appliance supports authentication with Oracle COREid v6.5 and v7.0. Access to the COREid Access System is done through the Blue Coat Authentication and Authorization Agent (BCAAA), which must be installed on a Windows 2000 system or higher with access to the COREid Access Servers.

Understanding COREid Interaction with Blue Coat Within the COREid Access System, BCAAA acts as a custom AccessGate. It communicates with the COREid Access Servers to authenticate the user and to obtain a COREid session token, authorization actions, and group membership information. HTTP header variables and cookies specified as authorization actions are returned to BCAAA and forwarded to the SG appliance. They can (as an option) be included in requests forwarded by the appliance. Within the SG system, BCAAA acts as its agent to communicate with the COREid Access Servers. The SG appliance provides the user information to be validated to BCAAA, and receives the session token and other information from BCAAA. Each SG COREid realm used causes the creation of a BCAAA process on the Windows host computer running BCAAA. When a process is created, a temporary working directory containing the Oracle COREid files needed for configuration is created for that process. A single host computer can support multiple SG realms (from the same or different SG appliances); the number depends on the capacity of the BCAAA host computer and the amount of activity in the realms. Configuration of the SG COREid realm must be coordinated with configuration of the Access System. Each must be aware of the AccessGate. In addition, certain authorization actions must be configured in the Access System so that BCAAA gets the information the SG appliance needs.

Configuring the COREid Access System Note: Blue Coat assumes you are familiar with the configuration of the COREid Access System and WebGates.

Since BCAAA is an AccessGate in the COREid Access System, it must be configured in the Access System just like any other AccessGate. BCAAA obtains its configuration from the SG appliance so configuration of BCAAA on the host computer is not required. If the Cert Transport Security Mode is used by the Access System, then the certificate files for the BCAAA AccessGate must reside on BCAAA’s host computer.

79

Volume 4: Securing the Blue Coat SG Appliance

COREid protects resources identified by URLs in policy domains. A SG COREid realm is associated with a single protected resource. This could be an already existing resource in the Access System, (typical for a reverse proxy arrangement) or it could be a resource created specifically to protect access to SG services (typical for a forward proxy). Important: The request URL is not sent to the Access System as the requested resource; the requested resource is the entire SG realm. Access control of individual URLs is done on the SG appliance using policy. The COREid policy domain that controls the protected resource must use one of the challenge methods supported by the SG appliance. Supported challenge methods are Basic, X.509 Certificates and Forms. Acquiring the credentials over SSL is supported as well as challenge redirects to another server. The SG appliance requires information about the authenticated user to be returned as COREid authorization actions for the associated protected resource. Since authentication actions are not returned when a session token is simply validated, the actions must be authorization and not authentication actions. The following authorization actions should be set for all three authorization types (Success, Failure, and Inconclusive): ❐

A HeaderVar action with the name BCSI_USERNAME and with the value corresponding to the simple username of the authenticated user. For example, with an LDAP directory this might be the value of the cn attribute or the uid attribute.

❐

A HeaderVar action with the name BCSI_GROUPS and the value corresponding to the list of groups to which the authenticated user belongs. For example, with an LDAP directory this might be the value of the memberOf attribute.

Once the COREid AccessGate, authentication scheme, policy domain, rules, and actions have been defined, the SG appliance can be configured.

Additional COREid Configuration Notes The SG appliance's credential cache only caches the user's authentication information for the lesser of the two values of the time-to-live (TTL) configured on the SG appliance and the session TTL configured in the Access System for the AccessGate.

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

Communicate with the Blue Coat agent(s) that act on its behalf (hostname or IP address, port, SSL options, and the like).

❐

Provide BCAAA with the information necessary to allow it to identify itself as an AccessGate (AccessGate id, shared secret).

❐

Provide BCAAA with the information that allows it to contact the primary COREid Access Server (IP address, port, connection information).

❐

Provide BCAAA with the information that it needs to do authentication and collect authorization information (protected resource name), and general options (off-box redirection).

For more information on configuring the SG COREid realm, see “Creating a COREid Realm” on page 82.

80

Chapter 6: Oracle COREid Authentication

Note: All SG appliance and agent configuration is done on the appliance. The appliance sends the necessary information to BCAAA when it establishes communication.

Participating in a Single Sign-On (SSO) Scheme The SG appliance can participate in SSO using the encrypted ObSSOCookie cookie. This cookie is set in the browser by the first system in the domain that authenticates the user; other systems in the domain obtain authentication information from the cookie and so do not have to challenge the user for credentials. The SG appliance sets the ObSSOCookie cookie if it is the first system to authenticate a user, and authenticates the user based on the cookie if the cookie is present. Since the SSO information is carried in a cookie, the SG appliance must be in the same cookie domain as the servers participating in SSO. This imposes restrictions on the authenticate.mode() used on the SG appliance. ❐

A reverse proxy can use any origin mode.

❐

A forward proxy must use one of the origin-redirect modes (such as origincookie-redirect). When using origin-*-redirect modes, the virtual URL's hostname must be in the same cookie domain as the other systems. It cannot be an IP address; the default www.cfauth.com does not work either.

When using origin-*-redirect, the SSO cookie is automatically set in an appropriate response after the SG appliance authenticates the user. When using origin mode (in a reverse proxy), setting this cookie must be explicitly specified by the administrator using the policy substitution variable $(x-agent-sso-cookie). The variable $(x-agent-ssocookie) expands to the appropriate value of the set-cookie: header.

Avoiding SG Appliance Challenges In some COREid deployments all credential challenges are issued by a central authentication service. Protected services do not challenge and process request credentials; instead, they work entirely with the SSO token. If the request does not include an SSO token, or if the SSO token is not acceptable, the request is redirected to the central service, where authentication occurs. Once authentication is complete, the request is redirected to the original resource with a response that sets the SSO token. If the COREid authentication scheme is configured to use a forms-based authentication, the SG appliance redirects authentication requests to the form URL automatically. If the authentication scheme is not using forms authentication but has specified a challenge redirect URL, the SG appliance only redirects the request to the central service if alwaysredirect-offbox is enabled for the realm on the SG. If the always-redirect-offbox option is enabled, the authentication scheme must use forms authentication or have a challenge redirect URL specified. Note: The SG appliance 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.

81

Volume 4: Securing the Blue Coat SG Appliance

Creating a COREid Realm To create a COREid realm: 1.

Select Configuration > Authentication > Oracle COREid > COREid Realms.

2.

Click New.

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter. The name should be meaningful to you, but it does not have to be the name of the COREid AccessGate.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Configuring Agents You must configure the COREid realm so that it can find the Blue Coat Authentication and Authorization Agent (BCAAA). To configure the BCAAA agent: 1.

Select Configuration > Authentication > Oracle COREid > Agents.

2.

Select the realm name to edit from the drop-down list.

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.

82

Chapter 6: Oracle COREid Authentication

5.

Enter the AccessGate ID in the AccessGate id field. The AccessGate ID is the ID of the AccessGate as configured in the Access System.

6.

If an AccessGate password has been configured in the Access System, you must specify the password on the SG appliance. Click Change Secret and enter the password. The passwords can be up to 64 characters long and are always case sensitive.

7.

(Optional) Enter an alternate agent host and AccessGate ID in the Alternate agent section.

8.

(Optional) Select Enable SSL to enable SSL between the SG appliance and the BCAAA agent.

9.

(Optional) By default, if SSL is enabled, the COREid BCAAA certificate is verified. If you do not want to verify the agent certificate, disable this setting.

10. Specify the length of time in the Timeout Request field, in seconds, to elapse before timeout if a response from BCAAA is not received. (The default request timeout is 60 seconds.) 11. If you want username and group comparisons on the SG appliance to be case sensitive, select Case sensitive.

Configuring the COREid Access Server Once you create a COREid realm, use the COREid Access Server page to specify the primary Access Server information. To configure the COREid Access Server: 1.

Select Configuration > Authentication > Oracle COREid > COREid Access Server.

2.

Select the realm name to edit from the drop-down list.

3.

Enter the protected resource name. The protected resource name is the same as the resource name defined in the Access System policy domain.

4.

Select the Security Transport Mode for the AccessGate to use when communicating with the Access System.

5.

If Simple or Cert mode is used, specify the Transport Pass Phrase configured in the Access System. Click Change Transport Pass Phrase to set the pass phrase.

6.

If Cert mode is used, specify the location on the BCAAA host machine where the key, server and CA chain certificates reside. The certificate files must be named aaa_key.pem, aaa_cert.pem, and aaa_chain.pem, respectively.

83

Volume 4: Securing the Blue Coat SG Appliance

7.

To force authentication challenges to always be redirected to an off-box URL, select Always redirect off-box.

8.

To enable validation of the client IP address in SSO cookies, select Validate client IP address. If the client IP address in the SSO cookie can be valid yet different from the current request client IP address because of downstream proxies or other devices, then deselect the Validate client IP address in the realm. Also modify the WebGates participating in SSO with the SG appliance. Modify the WebGateStatic.lst file to either set the ipvalidation parameter to false or to add the downstream proxy/device to the IPValidationExceptions lists.

9.

If your Web applications need information from the Authorization Actions, select Add Header Responses. Authorization actions from the policy domain obtained during

authentication are added to each request forwarded by the SG appliance. Header responses replace any existing header of the same name; if no such header exists, the header is added. Cookie responses replace a cookie header with the same cookie name, if no such cookie header exists, one is added. 10. Specify the ID of the AccessGate’s primary Access Server. 11. Specify the hostname of the AccessGate’s primary Access Server. 12. Specify the port of the AccessGate’s primary Access Server. 13. Click Apply to commit the changes to the SG appliance.

Configuring the General COREid Settings The COREid General tab allows you to specify a display name, the refresh times, an inactivity timeout value, cookies, and a virtual URL. To configure the general COREid settings: 1.

Select Authentication > Oracle COREid > COREid General.

84

Chapter 6: Oracle COREid Authentication

2.

From the Realm name drop-down list, select the COREid realm for which you want to change properties.

3.

If needed, change the COREid realm display name. The default value for the display name is the realm name. The display name cannot be greater than 128 characters and it cannot be null.

4.

Select the Use the same refresh time for all check box if you would like to use the same refresh time for all.

5.

Enter the number of seconds in the Credential refresh time field. The Credential Refresh Time is the amount of time basic credentials (username and password) are kept on the SG appliance. This feature allows the SG appliance to reduce the load on the authentication server and enables credential spoofing. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, the SG appliance will authenticate the user supplied credentials against the cached credentials. If the credentials received do not match the cached credentials, they are forwarded to the authentication server in case the user password changed. After the refresh time expires, the credentials are forwarded to the authentication server for verification.

6.

Enter the number of seconds in the Surrogate refresh time field. The Surrogate Refresh Time allows you to set a realm default for how often a user’s surrogate credentials are refreshed. Surrogate credentials are credentials accepted in place of a user’s actual credentials. The default setting is 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, if a surrogate (IP address or cookie) is available and it matches the expected surrogate, the SG appliance authenticates the transaction. After the refresh time expires, the SG appliance will verify the user’s credentials. Depending upon the authentication mode and the user-agent, this may result in challenging the end user for credentials. The main goal of this feature is to verify that the user-agent still has the appropriate credentials.

7.

Type the number of seconds in the Inactivity timeout field to specify the amount of time a session can be inactive before being logged out.

8.

If you use Basic credentials and want to cache failed authentication attempts (to reduce the load on the authentication service), enter the number of seconds in the Rejected Credentials time field. This setting, enabled by default and set to one second, allows failed authentication attempts to be automatically rejected for up to 10 seconds. Any Basic credentials that match a failed result before its cache time expires are rejected without consulting the back-end authentication service. The original failed authentication result is returned for the new request. All failed authentication attempts can be cached: Bad password, expired account, disabled account, old password, server down. To disable caching for failed authentication attempts, set the Rejected Credentials time field to 0.

9.

Select the Use persistent cookies check box to use persistent browser cookies instead of session browser cookies.

85

Volume 4: Securing the Blue Coat SG Appliance

10. Select the Verify the IP address in the cookie check box if you would like the cookies surrogates to only be accepted for the IP address that the cookie was authenticated. Disabling this will allow cookies to be accepted from other IP addresses. 11. Specify the virtual URL to redirect the user to when they need to be challenged by the SG appliance. If the appliance is participating in SSO, the virtual hostname must be in the same cookie domain as the other servers participating in the SSO. It cannot be an IP address or the default, www.cfauth.com. 12. Select the Challenge user after logout check box if the realm requires the users to enter their credentials after they have logged out. 13. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Configure a COREid Realm ❐

To enter configuration mode: SGOS#(config) security coreid create-realm realm_name SGOS#(config) security coreid edit-realm realm_name

❐

The following subcommands are available: SGOS#(config coreid realm_name) primary-agent {host hostname | port port_number} SGOS#(config coreid realm_name) alternate-agent {host hostname | port port_number} SGOS#(config coreid realm_name) ssl enable SGOS#(config coreid realm_name) ssl-verify-agent enable SGOS#(config coreid realm_name) sso-type {query-client | query-dc | query-dc-client} SGOS#(config coreid realm_name) inactivity-timeout seconds SGOS#(config coreid seconds SGOS#(config coreid refresh seconds SGOS#(config coreid SGOS#(config coreid | verify-ip {enable

realm_name) refresh-time credential-refresh realm_name) refresh-time rejected-credentialsrealm_name) refresh-time surrogate-refresh seconds realm_name) cookie {persistent {enable | disable} | disable}}

SGOS#(config coreid realm_name) virtual-url url

Creating the CPL You can create CPL policies now that you have completed COREid realm configuration. Be aware that the examples below are just part of a comprehensive authentication policy. By themselves, they are not adequate for your purposes. The examples below assume the default policy condition is allow. On new SGOS 5.x systems, the default policy condition is deny. Note: Refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide for details

about CPL and how transactions trigger the evaluation of policy file and other layers. ❐

Every COREid-authenticated user is allowed access the SG appliance. authenticate(COREidRealm)

86

Chapter 6: Oracle COREid Authentication

❐

Group membership is the determining factor in granting access to the SG appliance. authenticate(COREidRealm) group=”cn=proxyusers, ou=groups, o=myco” deny

87

Volume 4: Securing the Blue Coat SG Appliance

88

Chapter 7: 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 SG appliance. 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 SG appliance, the appliance redirects the user back to the original request. If the user does not successfully authenticate against the SG appliance and the error is user-correctable, the user is presented with the authentication form again. Note: You can configure and install an 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 one of the existing authentication form exceptions

❐

Set storage options

❐

Set policies

89

Volume 4: Securing the Blue Coat SG Appliance Section A: Understanding Authentication Forms

Section A: Understanding Authentication Forms Three authentication forms are created initially: ❐

authentication_form: Enter Proxy Credentials for Realm $(cs-realm). This is the standard authentication form that is used for authentication with the SG appliance.

❐

new_pin_form: Create New PIN for Realm $(cs-realm). This form is used if you created a RADIUS realm using RSA SecurID tokens. This form prompts the user to enter a new PIN. The user must enter the PIN twice in order to verify that it was entered correctly.

❐

query_form: Query for Realm $(cs-realm). This form is used if you created a RADIUS realm using RSA SecurID tokens. The form is used to display the series of yes/no questions asked by the SecurID new PIN process.

You can customize any of the three initial authentication form exceptions or you can 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.) Each authentication form can contain the following: ❐

Title and sentence instructing the user to enter SG 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-authdomain) 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 IWA realm. If it is used, the value is prepended to the username value with a backslash.

❐

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 $(csusername)

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 SG appliance 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. ❐

Challenge State: The challenge state should be of type HIDDEN. If a RADIUS realm is using a response/challenge, this field is used to cache identification information needed to correctly respond to the challenge. The input name must be PROXY_SG_PRIVATE_CHALLENGE_STATE, and the value must be $(x-auth-private-challenge-state).

❐

Submit button. The submit button is required to submit the form to the SG appliance.

❐

Clear form button.The clear button is optional and resets all form values to their original values.

90

Chapter 7: Forms-Based Authentication

Section A: Understanding Authentication Forms ❐

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 SG appliance does not process forms submitted with GET.

The SG appliance only parses the following input fields during form submission: ❐

PROXY_SG_USERNAME

(required)

❐

PROXY_SG_PASSWORD

(required)

❐

PROXY_SG_REQUEST_ID

❐

PROXY_SG_PRIVATE_CHALLENGE_STATE (required)

❐

PROXY_SG_DOMAIN (optional) If specified, its value is prepended to the username and separated with a backslash.

(required)

Authentication_form The initial form, 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-auth-challenge-string) $(x-cs-auth-form-domain-field) Username: Password: $(exception.contact)

If the realm is an IWA 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. For comparison, the new_pin_form and query_form look similar to the following:

91

Volume 4: Securing the Blue Coat SG Appliance Section A: Understanding Authentication Forms

New_pin_form Create New PIN for Realm $(cs-realm) Create New PIN for Realm $(cs-realm) $(x-auth-challenge-string) $(x-cs-auth-form-domain-field) Enter New Pin: Retype New Pin: $(exception.contact)

92

Chapter 7: Forms-Based Authentication

Section A: Understanding Authentication Forms

Query_form Query for Realm $(cs-realm) Query for Realm $(cs-realm) $(x-auth-challenge-string) $(x-cs-auth-form-domain-field) Authentication > Novell SSO > Novell SSO Realms tab allows you to create a new Novell SSO realm. Up to 40 Novell SSO realms can be created. To Create a Novell SSO Realm through the Management Console 1.

Select Configuration > Authentication > Novell SSO > Novell SSO Realms.

2.

Click New.

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Novell SSO Agents You must configure the Novell realm so that it can find the Blue Coat Authentication and Authorization Agent (BCAAA). 1.

Select Configuration > Authentication > Novell SSO>Agents.

2.

Select the realm name to edit from the drop-down list.

165

Volume 4: Securing the Blue Coat SG Appliance

Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) before attempting to configure the BCAAA agent. If the message Realms must be added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Novell SSO realms defined.

3.

In the Primary agent section, enter the hostname or IP address where the BCAAA agent resides.

4.

Change the port from the default of 16101 if necessary.

5.

(Optional) You can change the encrypted passwords for the private key and public certificate on the BCAAA machine that are to be used for SSL communication between the BCAAA service and the Novell eDirectory server by clicking Change Private Key Password or Change Public Certificate Password. The location of the private key and public certificate are specified in the sso.ini file on the BCAAA machine. (For information on changing the location of the private key and public certificate, see “Modifying the sso.ini File for Novell SSO Realms” on page 171.)

6.

(Optional) Enter an alternate agent host and agent name in the Alternate agent section. Note that you can also change the passwords for the private key and public certificate for the alternate agent, as well. The primary and alternate BCAAA server must work together to support fail-over. If the primary BCAAA server fails, the alternate server should be able to search and monitor the same set of eDirectory servers.

7.

(Optional) Click Enable SSL to enable SSL between the SG appliance and the BCAAA.

8.

(Optional) By default, if SSL is enabled, the BCAAA service’s certificate is verified. To not verify the agent certificate, disable this setting. Note: The Enable SSL setting only enables SSL between the SG appliance and BCAAA. To enable SSL between BCAAA and the eDirectory server, the Enable SSL setting must be set in the LDAP search realm.

9.

In the Timeout Request field, type the number of seconds the SG appliance allows for each request attempt before timing out. (The default request timeout is 60 seconds.)

10. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Create and Define a Novell SSO Realm 1.

At the (config) prompt: SGOS#(config) security novell-sso create-realm realm_name SGOS#(config) security novell-sso edit-realm realm_name SGOS#(config novell-sso realm_name) primary-agent {host hostname | port port_number} SGOS#(config novell-sso realm_name) alternate-agent {host hostname | port port_number} SGOS#(config novell-sso realm_name) ssl enable SGOS#(config novell-sso realm_name) ssl-verify-agent enable SGOS#(config novell-sso realm_name) sso-type {query-client | query-dc | query-dc-client}

166

Chapter 14: Novell Single Sign-on Authentication and Authorization

Adding LDAP Servers to Search and Monitor The BCAAA service searches and monitors specified eDirectory servers to determine which users are logged in and their Network Address attribute value. Those attribute values are converted into IP addresses, and BCAAA maintains a map of IP addresses to LDAP FQDNs. If the eDirectory tree is partitioned across multiple servers, the realm must monitor every eDirectory server that has unique user information. To specify the eDirectory servers: 1.

Select Configuration > Authentication > Novell SSO > LDAP Servers.

2.

Select the realm name to edit from the drop-down list. Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) before attempting to specify LDAP server configuration. If the message Realms must be added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Novell SSO realms defined.

3.

Select an LDAP realm from the drop-down list. The servers configured in this LDAP realm are used to do the full searches of the eDirectory tree.

4.

If you have a deployment with multiple servers holding partitions that are not fully replicated to the master server, you can monitor each LDAP server individually. To add an LDAP server to monitor, click New.

5.

Add the IP address and port of the LDAP server and click OK.

6.

Repeat for additional LDAP servers you need to monitor.

7.

Click Apply to commit the changes to the SG appliance.

167

Volume 4: Securing the Blue Coat SG Appliance

Related CLI Syntax to specify the LDAP search realm and LDAP servers to monitor: SGOS#(config) security novell-sso edit-realm realm_name SGOS#(config novell-sso realm_name) ldap search-realm ldap_realm SGOS#(config novell-sso realm_name) ldap monitor-servers {add host [port] | clear | remove host [port]}

Querying the LDAP Search Realm You can specify the time and days that a full search of the eDirectory tree is repeated in order to ensure that the mappings maintained by BCAAA are up to date. To specify search criteria: 1.

Select Configuration > Authentication > Novell SSO > LDAP Queries.

2.

Select the realm name to edit from the drop-down list. Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) before attempting to configure LDAP queries. If the message Realms must be added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Novell SSO realms defined.

3.

In the full search pane, specify the time of day you want the search to take place from the drop-down list.

4.

Select or de-select checkboxes to specify days to search.

5.

If you have changed the Novell eDirectory Network Address or Login Time LDAP attribute name, you can enter those changed names in the Network Address LDAP name and the Login Time LDAP name fields. The names must match the LDAP names configured on the eDirectory server for authentication to succeed.

6.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Specify Search Criteria SGOS#(config) security novell-sso edit-realm realm_name SGOS#(config novell-sso realm_name) full-search day-of-week {all | friday | monday | no | none | saturday | sunday | thursday | tuesday | wednesday} SGOS#(config novell-sso realm_name) full-search time-of-day 0-23 SGOS#(config novell-sso realm_name) ldap-name {login-time ldap_name | network-address ldap_name}

168

Chapter 14: Novell Single Sign-on Authentication and Authorization

Configuring Authorization Novell SSO realm can be configured to do no authorization, authorize against itself (the default), or authorize against another valid authorization realm (either LDAP or Local). To specify an authorization realm: 1.

Select Configuration > Authentication > Novell SSO > Authorization.

2.

Select the realm name to edit from the drop-down list. Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) before attempting to configure authorization. If the message Realms must be added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Novell SSO realms defined.

3.

The Novell SSO realm is selected to authorize against itself by default. To choose another realm, de-select the Self checkbox and choose an authorization realm from the drop-down list.

4.

The LDAP FQDN is selected as the Authorization user name, by default. You might want to change this if the user's authorization information resides in a different root DN. To choose a different authorization name, de-select the Use FQDN checkbox and enter a different name, for example: cn=$(user.name),ou=partition,o=company

5.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Authorization Settings SGOS#(config novell-sso realm_name) authorization realm-name authorization-realm-name SGOS#(config novell-sso realm-name) authorization username authorization-username SGOS#(config-novell-sso realm-name) authorization self {enable | disable}

Defining Novell SSO Realm General Properties The Novell SSO General tab allows you to specify the refresh times, an inactivity timeout value, and cookies, and a virtual URL.

169

Volume 4: Securing the Blue Coat SG Appliance

Note: Novell SSO realms default to the origin-ip authentication mode when no

authentication mode or the auto authentication mode is specified in policy. After a user has first successfully authenticated to the SG appliance, all subsequent requests from that same IP address for the length of the surrogate refresh time are authenticated as that user. If the first user is allowed or denied access, subsequent users during that same time coming from the same IP address are allowed or denied as that first user. This is true even if policy would have treated them differently if they were authenticated as themselves. If multiple users often log in from the same IP address, it is recommended to use a shorter surrogate refresh timeout than the default or an authentication mode that does not use IP surrogates. To configure Novell SSO general settings: 1.

Select Configuration > Authentication > Novell SSO > Novell SSO General.

2.

From the Realm name drop-down list, select the Novell SSO realm for which you want to change properties. Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) before attempting to set Novell SSO general properties. If the message Realms must be added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Novell SSO realms defined.

3.

Select the Use the same refresh time for all check box if you would like to use the same refresh time for all.

4.

Enter the number of seconds in the Surrogate refresh time field. The Surrogate Refresh Time allows you to set a realm default for how often a user’s surrogate credentials are refreshed. Surrogate credentials are credentials accepted in place of a user’s actual credentials. The default setting is 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here.

170

Chapter 14: Novell Single Sign-on Authentication and Authorization

Before the refresh time expires, if a surrogate (IP address or cookie) is available and it matches the expected surrogate, the SG appliance authenticates the transaction. After the refresh time expires, the SG appliance will determine which user is using the current IP address, and update the surrogate to authenticate with that user. 5.

Enter the number of seconds in the Authorization refresh time field. The Authorization Refresh Time allows you to manage how often the authorization data is verified with the authentication realm. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here.

6.

Type the number of seconds in the Inactivity timeout field to specify the amount of time a session can be inactive before being logged out.

7.

Select the Use persistent cookies check box to use persistent browser cookies instead of session browser cookies.

8.

Select the Verify the IP address in the cookie check box if you would like the cookies surrogates to only be accepted for the IP address that the cookie was authenticated. Disabling this will allow cookies to be accepted from other IP addresses.

9.

You can specify a virtual URL. For more information on the virtual URL, see “Understanding Origin-Style Redirection” on page 34.

10. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Configure General Settings SGOS#(config novell-sso realm_name) inactivity-timeout seconds SGOS#(config novell-sso realm_name) refresh-time surrogate-refresh seconds SGOS#(config novell-sso realm_name) refresh-time authorization-refresh seconds SGOS#(config novell-sso realm_name) cookie {persistent {enable | disable} | verify-ip {enable | disable}} SGOS#(config novell-sso realm_name) virtual-url url

Modifying the sso.ini File for Novell SSO Realms The Novell SSO realm uses the sso.ini file for configuration parameters required by the BCAAA service to manage communication with the Novell eDirectory server. Three sections in the sso.ini file are related to the Novell SSO realm: NovellSetup, NovellTrustedRoot Certificates, and SSOServiceUsers. You only need to modify settings in the NovellTrustedRoot Certificates section if the LDAP realm used by the Novell SSO realm requires that the identity of the server be verified. The sso.ini file is located in the BCAAA installation directory. Note:

The changes to the sso.ini file have no effect until the BCAAA service is restarted. To modify Novell SSO realms parameters: 1.

Open the file in a text editor.

2.

In the Novell Setup section, modify the parameters as needed (the default values are as follows): •

MonitorRetryTime=30

171

Volume 4: Securing the Blue Coat SG Appliance

•

SearchRetryTime=30

•

TrustedRootCertificateEncoding=der

•

PublicCertificateEncoding=der

•

PrivateKeyFile=

•

PrivateKeyEncoding=der

3.

If the LDAP realm used by the Novell SSO realm requires that the identity of the server be verified, add the paths to the Trusted root certificate files in the NovellTrustedRootCertificates section.

4.

In the section SSOServiceUsers, list the names of users who can log in with eDirectory credentials on behalf of the service and mask the identity of the logged-on user. Listing these users here forces the BCAAA service to ignore them for authentication purposes.

5.

Save the sso.ini file.

Creating the CPL You can create CPL policies now that you have completed Novell SSO 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. Note:

The examples below assume the default policy condition is allow.

Refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide for details about CPL and how transactions trigger the evaluation of policy file layers. ❐

Every Novell SSO-authenticated user is allowed access the SG appliance. authenticate(NSSORealm)

❐

Group membership is the determining factor in granting access to the SG appliance. authenticate(NSSORealm) group=”cn=proxyusers, ou=groups, o=myco” ALLOW deny

Using Single Sign-On Realms and Proxy Chains Some Application Delivery Network (ADN) configurations mask the source IP address of the request. For example, if the path for a request is: client workstation > branch proxy > data center proxy > gateway proxy

policy running on the gateway might see the IP address of the data center proxy rather than the IP address of the client workstation. Note:

The source IP address is not masked if you use the reflect client ip attribute.

In this ADN configuration, policy needs to be configured so that Windows SSO, Novell SSO, and policy substitution realms can authenticate users correctly.

172

Chapter 14: Novell Single Sign-on Authentication and Authorization

Use the user.login.address and authenticate.credentials.address policy gestures to override the IP address of the credentials used for authentication and match the IP address of the authenticated user. Note: The user.login.address condition only works correctly if you use the authenticate.credentials.address property to set the address.

You can also use the x-cs-user-login-address substitution to log this event. Examples In the following example, the address to use for authenticating with myrealm is set to the address received from the HTTP Client-IP header. authenticate(myrealm)\ authenticate.credentials.address($(request.header.Client-IP))

In the following example, the user is authenticated if logged in from the 1.2.3.0/24 subnet. user.login.address=1.2.3.0/24 allow

Notes ❐

The Novell SSO realm works reliably only in environments where one IP address maps to one user. NAT environments are not supported.

❐

Novell SSO realms are not supported in IPX environments.

❐

Event monitoring of eDirectory is only compatible with eDirectory 8.7+.

❐

Upgrade to Novell client 4.91 SP1 or later if you experience issues with the Network Address attribute not being updated during login.

❐

Novell SSO realms do not use user credentials so they cannot spoof authentication information to an upstream server.

❐

If an upstream proxy is doing Novell SSO authentication, all downstream proxies must send the client IP address.

❐

There can be response time issues between the BCAAA service and the eDirectory servers during searches; configure the timeout for LDAP searches to allow the eDirectory server adequate time to reply.

173

Volume 4: Securing the Blue Coat SG Appliance

174

Chapter 15: 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. For example, if a company has one set of end-users authenticating against an LDAP server and another using NTLM, a sequence realm can specify to attempt NTLM authentication first; if that fails due to a user-correctable error (such as credentials mismatch or a user not in database) then LDAP authentication can be specified to try next. You can also use sequences to fall through to a policy substitution realm if the user did not successfully authenticate against one of the earlier realms in the sequence. Note:

Errors such as server down do not fall through to the next realm in the sequence. Those errors result in an exception returned to the user. Only errors that are end-user correctable result in the next realm in the sequence being attempted. This section discusses the following topics: ❐

“Adding Realms to a Sequence Realm”

❐

“Creating a Sequence Realm” on page 176

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 IWA, 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 IWA realm is allowed in a realm sequence.

❐

If an IWA realm is in a realm sequence, it must be either the first or last realm in the list.

❐

If an IWA realm is in a realm sequence and the IWA realm does not support Basic credentials, the realm must be the first realm in the sequence and try IWA authentication once must be enabled.

❐

Multiple Basic realms are allowed.

❐

Multiple Windows SSO 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.

175

Volume 4: Securing the Blue Coat SG Appliance

❐

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

Select Configuration > Authentication > Sequences > Sequence Realms.

2.

Click New.

3.

In the Realm name, enter a realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Adding Realms to a Sequence Realm To add realms to a sequence realm: 1.

Select Configuration > Authentication > Sequences > Sequence Main.

176

Chapter 15: Sequence Realm Authentication

2.

Click New to add an existing realm to the realm sequence from the drop-down list. Remember that each realm can be used only once in a realm sequence.

3.

From the drop-down list, select the Sequence realm you wanted added to the realm sequence.

4.

Click OK. You are returned to the main Sequences menu.

5.

Click Apply to commit the changes to the SG appliance.

6.

Repeat from Step 2 until you have added all necessary realms.

7.

To change the order that the realms are checked, use the promote/demote buttons. When you add an IWA realm, it is placed first in the list and you can allow the realm sequence to try IWA authentication only once. If you demote the IWA entry, it becomes last in the sequence and the default of checking IWA multiple times is enabled.

177

Volume 4: Securing the Blue Coat SG Appliance

8.

If you permit authentication or authorization errors, you can select the Try next realm on tolerated error checkbox to specify that the next realm on the list should be attempted if authentication in the previous realm has failed with a permitted error. The default value is to not attempt the next realm and fall out of the sequence. (For information on using permitted errors and guest authentication, see “Permitting Users to Login with Authentication or Authorization Failures” on page 37.)

9.

Click Apply to commit the changes to the SG appliance.

Defining Sequence Realm General Properties The Sequence General tab allows you to specify the display name and a virtual URL. 1.

Select Configuration > Authentication > Sequences > Sequence General.

2.

From the Realm name drop-down list, select the Sequence realm for which you want to change properties.

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 3: "Controlling Access to the Internet and Intranet" on page 25.

5.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure a Sequence Realm ❐

To enter configuration mode: SGOS#(config) security sequence create-realm realm_sequence_name (config) security sequence edit-realm realm_sequence_name

❐

The following subcommands are available: #(config sequence realm_sequence_name) #(config sequence realm_sequence_name) display-name display_name #(config sequence realm_sequence_name) exit #(config sequence realm_sequence_name) IWA-only-once {disable | enable} #(config sequence realm_sequence_name) realm {add | demote | promote | remove} {realm_name | clear} #(config sequence realm_sequence_name) try-next-realm-on-error {disable | enable} #(config sequence realm_sequence_name) rename new_realm_name #(config sequence realm_sequence_name) view #(config sequence realm_sequence_name) virtual-url url

178

Chapter 15: Sequence Realm Authentication

Tips ❐

Explicit Proxy involving a sequence realm configured with an NTLM/IWA realm and a substitution realm. Internet Explorer (IE) automatically sends Windows credentials in the ProxyAuthorization: header when the SG appliance issues a challenge for NTLM/IWA. The prompt for username/password appears only if NTLM authentication fails. However, in the case of a sequence realm configured with an NTLM/IWA realm and a substitution realm, the client is authenticated as a guest in the policy substitution realm, and the prompt allowing the user to correct the NTLM credentials never appears.

❐

Transparent Proxy setup involving a sequence realm configured with an NTLM/IWA realm and a substitution realm. The only way the SG appliance can differentiate between a domain and non-domain user is though the NTLM/IWA credentials provided during the authentication challenge. IE does not offer Windows credentials in the Proxy-Authorization: header when the Proxy issues a challenge for NTLM/IWA unless the browser is configured to do so. In this case, the behavior is the same as for explicit proxy. If IE is not configured to offer Windows credentials, the browser issues a prompt for username/password, allowing non-domain users to be authenticated as guests in the policy substitution realm by entering worthless credentials.

179

Volume 4: Securing the Blue Coat SG Appliance

180

Chapter 16: Windows Single Sign-on Authentication

The Windows Single Sign-on (SSO) realm is an authentication mechanism available on Windows networks. This section discusses the following topics: ❐

“How Windows SSO Realms Work” on page 181

❐

“Creating a Windows SSO Realm” on page 183

❐

“Windows SSO Agents” on page 184

❐

“Configuring Authorization” on page 185

❐

“Defining Windows SSO Realm General Properties” on page 186

❐

“Creating the CPL” on page 190

How Windows SSO Realms Work In a Windows SSO realm, the client is never challenged for authentication. Instead, the BCAAA agent collects information about the current logged on user from the domain controller and/or by querying the client machine. Then the IP address of an incoming client request is mapped to a user identity in the domain. If authorization information is also needed, then another realm (LDAP or local) must be created. For more information, see “How Windows SSO Authorization Works” on page 183. Note: The Windows SSO realm works reliably only in environments where one IP address maps to one user. If an IP address cannot be mapped to a single user, authentication fails. Those with NAT systems, which uses one set of IP addresses for intranet traffic and a different set for Internet traffic, should use a different realm for authentication.

To authenticate a user, the Windows SSO realm uses two methods, either separately or together: ❐

Domain Controller Querying: The domain controller is queried to identify which users are connecting to, or authenticating with, the domain controller. This can be used to infer the identity of the user at a particular workstation.

❐

Client Querying: The client workstation is queried to determine who the client workstation thinks is logged in.

❐

When Domain Controller Querying and Client Querying are both used, the Domain Controller Query result is used if it exists and is still within the valid timeto-live as configured in the sso.ini file. If the Domain Controller Query result is older than the configured time-to-live, the client workstation is queried. Note: Before Domain Controller Querying or Client Querying can be used, the sso.ini file, located in the same directory as the BCAAA service, must be modified. For information on modifying this file, see “Modifying the sso.ini File for Windows SSO Realms” on page 188.

181

Volume 4: Securing the Blue Coat SG Appliance

For the most complete solution, an IWA realm could be configured at the same time as the Windows SSO realm and both realms added to a realm sequence. Then, if the Windows SSO realm failed to authenticate the user, the IWA realm could be used. For information on using a sequence realm, see Chapter 15: "Sequence Realm Authentication" on page 175.

How Windows SSO Works with BCAAA The server side of the authentication exchange is handled by the Blue Coat Authentication and Authorization Agent (BCAAA). Windows SSO uses a single BCAAA process for all realms and proxies that use SSO. BCAAA must be installed on a domain controller or member server. By default, the BCAAA service authenticates users in all domains trusted by the computer on which it is running. When using Domain Controller Querying, the BCAAA service can be configured to only query certain domain controllers in those trusted domains. By default the BCAAA service is installed to run as LocalSystem. For a Windows SSO realm to have correct permissions to query domain controllers and clients, the user who BCAAA runs under must be an authenticated user of the domain. When the Windows SSO realm is configured to do Client Querying, the user that BCAAA runs under must be an authenticated user of the domain. For failover purposes, a second BCAAA can be installed and configured to act as an alternate BCAAA in the Windows SSO realm. The alternate BCAAA service is used in the event of a failure with the primary BCAAA service configured in the realm.

BCAAA Synchronization Optionally, when using Domain Controller Querying, you can configure a BCAAA service to use another BCAAA service as a synchronization server. Whenever a BCAAA service restarts it will contact its synchronization server and update its logon state. Two given BCAAA services can use each other as their synchronization server. Thus, each BCAAA service can act as a synchronization server to provide logon state to other BCAAA services, as well as acting as a synchronization client to update its logon state from another BCAAA service. Each BCAAA service has a synchronization priority that determines synchronization behavior. If the client BCAAA has the same or higher priority than the server BCAAA, synchronization is done once at restart to update the client state. Once synchronization is complete the client BCAAA drops the synchronization connection and begins querying the domain controllers. However, if the server BCAAA has higher priority, then the client BCAAA keeps the synchronization link open and continuously updates its logon state from the higher priority BCAAA. The client BCAAA does not query the domain controllers itself unless the synchronization link fails. This makes it possible to manage the query load on the domain controllers. If there is no issue with load, then the default configuration (without synchronization), with all BCAAA agents querying the domain controllers is acceptable. However, if load on the domain controllers is an issue, synchronization can be used to minimize this load while still providing fail-over capabilities. By default, all BCAAA agents have the same synchronization priority, meaning that they synchronize on startup and then do their own domain controller querying. To change the synchronization settings, see “To configure the sso.ini file for synchronization:” on page 189.

182

Chapter 16: Windows Single Sign-on Authentication

Note: For information on configuring the BCAAA service as an authenticated user of the domain, see Appendix B: "Using the Authentication/Authorization Agent" on page 215.

How Windows SSO Authorization Works The Windows SSO realm, in addition to allowing you to create and manipulate realm properties, such as the query type and the number of seconds that credential cache entries from this realm are valid, also contains the authorization username and the name of the realm that will do authorization for the Windows SSO realm. The authorization username is a string containing policy substitutions that describes how to construct the username for authorization lookups. This can either be an LDAP FQDN when the authorization realm is an LDAP realm, or a simple name when local realms are being used for authorization. Note:

Windows SSO realms never challenge for credentials. If the authorization username cannot be determined from the configured substitutions, authorization in the Windows SSO realm fails. Keep in mind that Windows SSO realms do not require an authorization realm. If no authorization realm is configured, the user is not considered a member of any group. The effect this has on the user depends on the authorization policy. If the policy does not make any decisions based on groups, you do not need to specify an authorization realm. Also, if your policy is such that it works as desired when all Windows SSO realm users are not in any group, you do not have to specify an authorization realm.

Creating a Windows SSO Realm The Configuration > Authentication > Windows SSO > Windows SSO Realms tab allows you to create a new Windows SSO realm. To create a Windows SSO realm: 1.

Select Configuration > Authentication > Windows SSO > Windows SSO Realms.

2.

Click New.

3.

In the Realm name field, enter a realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

183

Volume 4: Securing the Blue Coat SG Appliance

Windows SSO Agents You must configure the Windows realm so that it can find the Blue Coat Authentication and Authorization Agent (BCAAA). 1.

Select Configuration > Authentication > Windows SSO > Agents.

2.

Select the realm name to edit from the drop-down list. Note:

You must have defined at least one Windows SSO realm (using the Windows SSO Realms tab) before attempting to configure the BCAAA agent. If the message Realms must be added in the Windows SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not have any Windows SSO realms defined. 3.

In the Primary agent section, enter the hostname or IP address where the BCAAA agent resides.

4.

Change the port from the default of 16101 if necessary.

5.

(Optional) Enter an alternate agent host and agent name in the Alternate agent section. The primary and alternate BCAAA server must work together to support fail-over. If the primary BCAAA server fails, the alternate server should be able to provide the same mappings for the IP addresses.

6.

(Optional) Click Enable SSL to enable SSL between the SG appliance and the BCAAA.

7.

(Optional) By default, if SSL is enabled, the Windows SSO BCAAA certificate is verified. To not verify the agent certificate, disable this setting.

8.

In the Timeout Request field, type the number of seconds the SG appliance allows for each request attempt before timing out. (The default request timeout is 60 seconds.)

9.

In the Query Type field, select the method you want to use from the drop-down menu. By default the Windows SSO realm is configured for Domain Controller Querying only. Note:

If all of the client computers can be queried directly, then the most accurate results can be provided by the Query Clients option.

184

Chapter 16: Windows Single Sign-on Authentication

Client Querying is blocked by the Windows XP SP2 firewall. This can be overridden through domain policy. If the firewall setting "Allow remote administration exception" or "Allow file and printer sharing exception" or "Define port exceptions" (with port 445) is enabled, then the query will work. If an authentication mode without surrogates is being used (Proxy or Origin authenticate mode), then the Query Domain Controller and Client and Query Client options can cause too much traffic when querying the clients, as each authentication request results in a request to the BCAAA service, which can result in a client workstation query depending on the client query time-to-live. If the client workstation querying traffic is a concern, the Query Domain Controllers option should be used instead. 10. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Create and Define a Windows SSO Realm 1.

At the (config) prompt, enter the following command to create a Windows SSO realm: SGOS#(config) security windows-sso create-realm realm_name

where realm_name is the name of the Windows SSO realm. 2.

To redefine the Windows SSO realm configuration for the realm you just created, enter the following commands: SGOS#(config) security windows-sso edit-realm realm_name SGOS#(config windows-sso realm_name) primary-agent {host hostname | port port_number} SGOS#(config windows-sso realm_name) alternate-agent {host hostname | port port_number} SGOS#(config windows-sso realm_name) ssl enable SGOS#(config windows-sso realm_name) ssl-verify-agent enable SGOS#(config windows-sso realm_name) sso-type {query-client | query-dc | query-dc-client}

Configuring Authorization After the Windows SSO realm is created, you can use the Windows SSO Authorization tab to configure authorization for the realm. Note: Windows SSO realms do not require an authorization realm. If the policy does not make any decisions based on groups, you do not need to specify an authorization realm.

1.

Select Configuration > Authentication > Windows SSO > Authorization.

2.

From the Realm name drop-down list, select the Windows SSO realm for which you want to change realm properties.

185

Volume 4: Securing the Blue Coat SG Appliance

Note:

You must have defined at least one Windows SSO realm (using the Windows SSO Realms tab) before attempting to set Windows SSO realm properties. If the message Realms must be added in the Windows SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Windows SSO realms defined. 3.

(Optional) From the Authorization realm name drop-down list, select the realm you want to use to authorize users.

4.

To construct usernames, keep in mind that the authorization username attributes is a string. that contains policy substitutions. When authorization is required for the transaction, the character string is processed by the policy substitution mechanism, using the current transaction as input. The resulting string becomes the user's authorization name for the current transaction.

5.

The LDAP FQDN is selected as the Authorization user name, by default. You might want to change this if the user's authorization information resides in a different root DN. To choose a different authorization name, de-select the Use FQDN checkbox and enter a different name, for example: cn=$(user.name),ou=partition,o=company

6.

Click Apply to commit the changes to the SG appliance.

Table 16-1. Common Substitutions Used in the Authorization username Field ELFF Substitution

CPL Equivalent

Description

x-cs-auth-domain

$(user.domain)

The Windows domain of the authenticated user.

cs-username

$(user.name)

The relative username of the authenticated user.

Related CLI Syntax to Configure Authorization Settings SGOS#(config windows-sso realm_name) authorization realm-name authorization-realm-name SGOS#(config windows-sso realm_name) authorization username authorization-username

Defining Windows SSO Realm General Properties The Windows SSO General tab allows you to specify the display name, the refresh times, an inactivity timeout value, cookies, and a virtual URL.

186

Chapter 16: Windows Single Sign-on Authentication

Note: Windows SSO realms default to the origin-ip authentication mode when either no authentication mode or the auto authentication mode is specified in policy. After a user has first successfully authenticated to the SG appliance, all subsequent requests from that same IP address for the length of the surrogate refresh time are authenticated as that user. If the first user is allowed or denied access, subsequent users during that same time coming from the same IP address are allowed or denied as that first user. This is true even if policy would have treated them differently if they were authenticated as themselves.

If multiple users often log in from the same IP address, it is recommended to use a shorter surrogate refresh timeout than the default or an authentication mode that uses cookie surrogates. To configure general settings: 1.

Select Configuration > Authentication > Windows SSO > Windows SSO General.

2.

From the Realm name drop-down list, select the Windows SSO realm for which you want to change properties. Note:

You must have defined at least one Windows SSO realm (using the Windows SSO Realms tab) before attempting to set Windows SSO general properties. If the message Realms must be added in the Windows SSO Realms tab before editing this tab is displayed in red at the bottom of this page, you do not currently have any Windows SSO realms defined. 3.

Select the Use the same refresh time for all check box if you would like to use the same refresh time for all.

4.

Enter the number of seconds in the Surrogate refresh time field. The Surrogate Refresh Time allows you to set a realm default for how often a user’s surrogate credentials are refreshed. Surrogate credentials are credentials accepted in place of a user’s actual credentials. The default setting is 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, if a surrogate (IP address or cookie) is available and it matches the expected surrogate, the SG appliance authenticates the transaction. After the refresh time expires, the SG appliance will determine which user is using the current IP address, and update the surrogate to authenticate with that user.

187

Volume 4: Securing the Blue Coat SG Appliance

5.

Enter the number of seconds in the Authorization refresh time field. The Authorization Refresh Time allows you to manage how often the authorization data is verified with the authentication realm. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here.

6.

Type the number of seconds in the Inactivity timeout field to specify the amount of time a session can be inactive before being logged out.

7.

Select the Use persistent cookies check box to use persistent browser cookies instead of session browser cookies.

8.

Select the Verify the IP address in the cookie check box if you would like the cookies surrogates to only be accepted for the IP address that the cookie was authenticated. Disabling this will allow cookies to be accepted from other IP addresses.

9.

You can specify a virtual URL. For more information on the virtual URL, see “Understanding Origin-Style Redirection” on page 34.

10. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Configure General Settings I SGOS#(config windows-sso realm_name) inactivity-timeout seconds SGOS#(config windows-sso realm_name) refresh-time surrogate-refresh seconds SGOS#(config windows-sso realm_name) refresh-time authorizationrefresh seconds SGOS#(config windows-sso realm_name) cookie {persistent {enable | disable} | verify-ip {enable | disable}} SGOS#(config windows-sso realm_name) virtual-url url

Modifying the sso.ini File for Windows SSO Realms To enable the method of authentication querying you choose, you must modify the sso.ini file by adding domain controllers you want to query and user accounts you want to ignore. The sso.ini file is located in the BCAAA installation directory. If you are only using one method of querying, you only need configure the specific settings for that method. If you plan to use both methods to query, you must configure all the settings. Note:

The changes to the sso.ini file have no effect until the BCAAA service is restarted. To configure the sso.ini file for Domain Controller Querying 1.

Open the file in a text editor.

2.

In the section DCQSetup, uncomment the line: DCQEnabled=1.

3.

In the section DCQDomainControllers, list the domain controllers you want to query or the IP address ranges of interest.

188

Chapter 16: Windows Single Sign-on Authentication

By default all domain controllers that are in the forest or are trusted are queried. In large organizations, domain controllers that are not of interest for the SG appliance installation might be queried. The sso.ini file can be used to list the domain controllers of interest or IP address ranges of interest. 4.

In the section SSOServiceUsers, list the domain names of users who can access the domain controller on behalf of the service and mask the identity of the logged-on user. Listing these users here forces the BCAAA service to ignore them for authentication purposes.

5.

Save the sso.ini file.

To configure the sso.ini file for client querying: Note: Before you use the Windows SSO realm, you must change the BCAAA service to run as a domain user, and, if using XP clients, update the domain policy to allow the client query to pass through the firewall.

For information on installing and configuring the BCAAA service, see Appendix B: "Using the Authentication/Authorization Agent" on page 215. 1.

Open the file in a text editor.

2.

Review the TTL times in the section ClientQuerySetup to be sure they are appropriate for your network environment.

3.

Update the section SSOServiceUsers to ignore domain users used for services.

4.

Save the sso.ini file.

To configure the sso.ini file for synchronization: 1.

Open the file in a text editor.

2.

Update the section SSOSyncSetup (the defaults are listed below). Note that explanations of each setting are provided in the sso.ini file. •

ServerPriority=100

•

EnableSyncServer=1

•

SyncPortNumber=16102

•

UseSSL=0

•

VerifyCertificate=0

•

QueryDelta=10

•

RetrySyncTime=60

3.

Update the section SSOSyncServer with the IP address or hostname of the BCAAA service to use a synchronization server.

4.

In the section SSOSyncClients, list the IP addresses or hostnames of the BCAAA services that will use this BCAAA service as their synchronization service.

5.

Save the sso.ini file.

189

Volume 4: Securing the Blue Coat SG Appliance

Creating the CPL You can create CPL policies now that you have completed Windows SSO 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 systems, the default policy condition is deny. Note:

Refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide for details about CPL and how transactions trigger the evaluation of policy file layers. ❐

Every Windows SSO-authenticated user is allowed access the SG appliance. authenticate(WSSORealm)

❐

Group membership is the determining factor in granting access to the SG appliance. authenticate(WSSORealm) group=”cn=proxyusers, ou=groups, o=myco” ALLOW deny

Using Single Sign-On Realms and Proxy Chains Some Application Delivery Network (ADN) configurations mask the source IP address of the request. For example, if the path for a request is: client workstation > branch proxy > data center proxy > gateway proxy

policy running on the gateway might see the IP address of the data center proxy rather than the IP address of the client workstation. Note:

The source IP address is not masked if you use the reflect client ip attribute.

In this ADN configuration, policy needs to be configured so that Windows SSO, Novell SSO, and policy substitution realms can authenticate users correctly. Use the user.login.address and authenticate.credentials.address policy gestures to override the IP address of the credentials used for authentication and match the IP address of the authenticated user. Note: The user.login.address condition only works correctly if you use the authenticate.credentials.address property to set the address.

You can also use the x-cs-user-login-address substitution to log this event. Examples In the following example, the address to use for authenticating with myrealm is set to the address received from the HTTP Client-IP header. authenticate(myrealm)\ authenticate.credentials.address($(request.header.Client-IP))

190

Chapter 16: Windows Single Sign-on Authentication

In the following example, the user is authenticated if logged in from the 1.2.3.0/24 subnet. user.login.address=1.2.3.0/24 allow

Notes ❐

The Windows SSO realm works reliably only in environments where one IP address maps to one user.

❐

This realm never uses a password.

❐

When doing domain controller querying, the Windows SSO realm can lose the logon if the NetBIOS computer name cannot by determined through a DNS query or a NetBIOS query. The DNS query can fail if the NetBIOS name is different than the DNS host name or if the computer is in a different DNS domain than the BCAAA computer and the BCAAA computer is not set up to impute different DNS domains. The NetBIOS query can fail because the NetBIOS broadcast does not reach the target computer. This can happen if the computer is behind a firewall that is not forwarding NetBIOS requests or if the computer is on a subnet that is not considered to be local to the BCAAA server. To prevent this issue, the BCAAA machine must be configured to be able to query the NetBIOS name of any computer of interest and get the correct IP address. One workaround is to use a WINS server. This works like a DNS server but handles NetBIOS lookups.

191

Volume 4: Securing the Blue Coat SG Appliance

192

Chapter 17: Using XML Realms

If you use an authentication or authorization protocol that is not natively supported by Blue Coat, you can use the XML realm to integrate SGOS with the authentication/ authorization protocol. This section includes the following topics: ❐

“About XML Realms”

❐

“Before Creating an XML Realm” on page 194

❐

“Creating an XML Realm” on page 194

❐

“Configuring XML Servers” on page 195

❐

“Configuring XML Options” on page 196

❐

“Configuring XML Realm Authorization” on page 196

❐

“Configuring XML General Realm Properties” on page 198

❐

“Creating the CPL” on page 200

❐

“Viewing Statistics” on page 200

About XML Realms An XML realm uses XML messages to request authentication and authorization information from an HTTP XML service (the XML responder that runs on an external server). The XML realm (the XML requestor) supports both HTTP GET and HTTP POST methods to request an XML response. The XML messages are based on SOAP 1.2. The XML responder service accepts XML requests from the SG, communicates with an authentication or authorization server, and responds with the result. When the realm is used to authenticate users, it challenges for Basic credentials. The username and password are then sent to the XML responder to authenticate and authorize the user. The XML realm can place the username and password in the HTTP headers of the request or in the body of the XML POST request. If the credentials are placed in the HTTP headers, the Web server must do the authentication and the XML service just handles authorization. If credentials are placed in the XML request body, the XML service handles both authentication and authorization. XML messages must conform to the Blue Coat XML realm schema. This is an XML schema based on SOAP 1.2. The schema can be found at http://www.bluecoat.com/ xmlns/xml-realm/1.0. An authenticate request sends the credentials to the XML responder and optionally sends the groups and attributes referenced in policy. The XML responder can then authenticate the credentials. The response indicates if the user was successfully authenticated and also includes the user’s groups and attributes if the XML responder is doing authorization. An authorize request sends the authenticated username to the XML responder and optionally sends the groups and attributes referenced in policy. The response includes the user’s groups and attributes.

193

Volume 4: Securing the Blue Coat SG Appliance

Before Creating an XML Realm The following list describes the tasks you must complete before creating an XML realm. ❐

Create an appropriate XML realm responder (one that is designed to talk to the Blue Coat XML realm protocol) and install it on an HTTP Web server. You can either create the responder yourself or have a third party create it, such as Blue Coat Professional Services. To create the XML realm responder, see Appendix D: "XML Protocol" on page 239 for a description of the SOAP protocol. The XML responder must correctly conform to the protocol. The XML realm performance is dependent on the response time of the XML responder.

❐

Configure an HTTP server with appropriate authentication controls. The authentication service can either depend on the HTTP server to authenticate the credentials, or the service can authenticate them directly. If the HTTP server is used to authenticate the credentials, it must be set up to protect the service with HTTP Basic authentication.

❐

(Optional) Configure an alternate HTTP server for redundancy. The XML responder service must be installed on the alternate server.

Creating an XML Realm To create an XML realm: Before you create an XML realm, be sure to complete the tasks in “Before Creating an XML Realm” above. 1.

In the Management Console, select Configuration > Authentication > XML > XML Realms.

2.

Click New.

3.

In the Realm name field, enter a realm name. The name can be 32 characters long, composed of alphanumeric characters and underscores. The name must start with a letter.

194

Chapter 17: Using XML Realms

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Configuring XML Servers Note:

You do not need to change these values if the default settings are acceptable.

After you have created an XML realm, go to the XML Servers page to change current default settings. To configure XML server properties: 1.

In the Management Console, select Configuration > Authentication > XML > XML Servers.

2. 3.

From the Realm Name drop-down list, select the XML realm. Select the Responder options, as follows: a.

Responder: Select the XML responder service to configure—Primary or Alternate—from the drop-down list. Primary is the default. You can configure both responder services before clicking Apply.

b.

Host: This is the hostname or IP address of the HTTP server that has the XML service. You must specify a host. The port defaults to port 80.

c.

Authenticate request path: Enter the XML responder path for authentication

requests. d. Authorize request path: Enter the XML responder path for authorization requests. 4.

In the timeout request field, enter the number of seconds for the system to wait for a request.

5.

Enter the number of times for the system to retry a request. The default is not to retry a request.

6.

Specify the maximum number of connections to the responder. The default is five connections.

7.

Select the One-time passwords check box to use one-time passwords. This allows you to integrate with a non-Blue Coat supported authentication service that uses one-time passwords.

195

Volume 4: Securing the Blue Coat SG Appliance

Note: One-time passwords are passwords that become invalid as soon as they are used. The passwords are often generated by a token or program, although preprinted lists are also used. Using one-time passwords ensures that the password cannot be used in a replay attack.

8.

Click Apply to commit the changes to the SG appliance.

9.

Repeat the above steps for additional XML realms, up to a total of 40.

Configuring XML Options Note:

You do not need to change these values if the default settings are acceptable.

With XML realms, you can place the username and password in the HTTP headers of the request or in the body of the XML POST request. If the credentials are placed in the HTTP headers, the Web server can do the authentication and the XML service can just handle authorization. If the credentials are placed in the XML request body, the XML service handles both authentication and authorization. To configure XML options: 1.

In the Management Console, select Configuration > Authentication > XML > XML Options.

2.

From the Realm name drop-down list, select the XML realm.

3.

Select one of the radio buttons to determine where to place the user credentials.

4.

•

If the HTTP server is integrated with the authentication system, the HTTP server can authenticate the credentials. Select the Put user credentials for authentication in the HTTP header radio button. However, if this does not provide enough flexibility, the XML responder can do authentication.

•

To have the XML responder service handle both authentication and authorization, select the Put user credentials for authentication in the request radio button.

Enter the username parameter in the Username parameter field. The default is username.

5.

Click Apply to commit the changes to the SG appliance.

Configuring XML Realm Authorization Note:

You do not need to change these values if the default settings are acceptable.

196

Chapter 17: Using XML Realms

After you have created the XML realm, you still must take into consideration how you will use authentication and authorization: ❐

Use an XML realm for both authorization and authentication. The realm is used for authentication and uses itself for authorization.

❐

Use an XML realm for authentication another realm for authorization. An XML realm can be used for authentication and use another realm for authorization. The authorization realm can be a Local realm, an LDAP realm or another XML realm.

❐

Use an XML realm as an authorization realm for another realm. An XML realm can be used as an authorization realm for another realm that is doing authentication. The authentication realm can be a Certificate realm, a Policy Substitution realm, a Novell SSO realm, a Windows SSO realm or another XML realm.

In all cases, you must write policy to authenticate and authorize the users. For information on writing policy for an XML realm, see “Creating the CPL” on page 200. To configure XML authorization properties: 1.

In the Management Console, select Configuration > Authentication > XML > Authorization.

2.

From the Realm name drop-down list, select the XML realm. a.

Authorization realm name: If the XML realm is not doing authorization, select

an authorization realm from the drop-down list. By default, the authorization realm name is Self. Note: If Self is selected, the Authorization realm name drop-down list is unavailable. To make the Authorization realm name drop-down list active, clear the Self check box.

b.

Authorization username: The default is Use full username. Clear the Use full username check box to use a different name or to use a policy substitution that

generates a username. c.

Default group: The default is no groups are selected.

d. The send the groups and attributes of interest in the request check box is selected by default. These are the groups and attributes that are used in policy. 3.

Click Apply to commit the changes to the SG appliance.

197

Volume 4: Securing the Blue Coat SG Appliance

Configuring XML General Realm Properties The XML General page allows you to indicate the realm’s display name, the refresh times, an inactivity timeout value, cookies, and a virtual URL for this realm. To configure general XML settings: 1.

In the Management Console, select Configuration > Authentication > XML > XML General.

2.

From the Realm name drop-down list, select the XML realm for which you want to change properties.

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 greater than 128 characters and it cannot be null.

4.

Select the Use the same refresh time for all check box if you would like to use the same refresh time for all.

5.

Enter the number of seconds in the Credential refresh time field. The Credential Refresh Time is the amount of time basic credentials (username and password) are kept on the SG appliance. This feature allows the SG appliance to reduce the load on the authentication server and enables credential spoofing. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, the SG appliance will authenticate the user supplied credentials against the cached credentials. If the credentials received do not match the cached credentials, they are forwarded to the authentication server in case the user password changed. After the refresh time expires, the credentials are forwarded to the authentication server for verification.

198

Chapter 17: Using XML Realms

6.

Enter the number of seconds in the Surrogate refresh time field. The Surrogate Refresh Time allows you to set a realm default for how often a user’s surrogate credentials are refreshed. Surrogate credentials are credentials accepted in place of a user’s actual credentials. The default setting is 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here. Before the refresh time expires, if a surrogate (IP address or cookie) is available and it matches the expected surrogate, the SG appliance authenticates the transaction. After the refresh time expires, the SG appliance will verify the user’s credentials. Depending upon the authentication mode and the user-agent, this may result in challenging the end user for credentials. The main goal of this feature is to verify that the user-agent still has the appropriate credentials.

7.

Enter the number of seconds in the Authorization refresh time field. The Authorization Refresh Time allows you to manage how often the authorization data is verified with the authentication realm. It has a default setting of 900 seconds (15 minutes). You can configure this in policy for better control over the resources as policy overrides any settings made here.

8.

Type the number of seconds in the Inactivity timeout field to specify the amount of time a session can be inactive before being logged out.

9.

If you use Basic credentials and want to cache failed authentication attempts (to reduce the load on the authentication service), enter the number of seconds in the Rejected Credentials time field. This setting, enabled by default and set to one second, allows failed authentication attempts to be automatically rejected for up to 10 seconds. Any Basic credentials that match a failed result before its cache time expires are rejected without consulting the back-end authentication service. The original failed authentication result is returned for the new request. All failed authentication attempts can be cached: Bad password, expired account, disabled account, old password, server down. To disable caching for failed authentication attempts, set the Rejected Credentials time field to 0.

10. Select the Use persistent cookies check box to use persistent browser cookies instead of session browser cookies. 11. Select the Verify the IP address in the cookie check box if you would like the cookies surrogates to only be accepted for the IP address that the cookie was authenticated. Disabling this will allow cookies to be accepted from other IP addresses. 12. You can specify a virtual URL. For more information on the virtual URL, see “Understanding Origin-Style Redirection” on page 34. 13. Click Apply to commit the changes to the SG appliance. Related CLI Syntax to Configure an XML Realm ❐

To enter configuration mode for the service: SGOS#(config) security create xml realm_name SGOS#(config) security edit xml realm_name

The following subcommands are available: SGOS#(config realm_name)?

199

Volume 4: Securing the Blue Coat SG Appliance

SGOS#(config realm_name) alternate-responder {host host | path {authenticate authenticate-path | authorize authorize-path}| port port} SGOS#(config realm_name) authorization {default-group-name group_name | realm {none | realm-name realm_name | self} | username {use-fullusername | username}} SGOS#(config realm_name) cache-duration seconds SGOS#(config realm_name) connections number SGOS#(config realm_name) display-name display_name SGOS#(config realm_name) exit SGOS#(config realm_name) no {alternate-responder | default-group-name} SGOS#(config realm_name) one-time-passwords {enable | disable} SGOS#(config realm_name) primary-responder {host host | path {authenticate authenticate-path | authorize authorize-path}| port port} SGOS#(config realm_name) rename new_realm_name SGOS#(config realm_name) timeout seconds SGOS#(config realm_name) retry number SGOS#(config realm_name) view SGOS#(config SGOS#(config seconds SGOS#(config SGOS#(config SGOS#(config

realm_name) refresh-time credential-refresh seconds realm_name) refresh-time rejected-credentials-refresh realm_name) refresh-time surrogate-refresh seconds realm_name) refresh-time authorization-refresh seconds realm_name) inactivity-timeout seconds

SGOS#(config realm_name) cookie {persistent {enable | disable} | verify-ip {enable | disable}} SGOS#(config realm_name) virtual-url virtual_url

Creating the CPL This CPL example gives access to users who are authenticated in the XML realm called eng_users and who are in the group waterloo. You also can create policy for XML realms through VPM. Note:

For information on using policy, refer to Volume 6: VPM and Advanced Policy or Volume 10: Blue Coat SG Appliance Content Policy Language Guide. authenticate(eng_users) realm=eng_users group=waterloo allow

Viewing Statistics To view statistics for XML realms, click Statistics > Advanced. Select one of the advanced links.

200

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

201

Volume 4: Securing the Blue Coat SG Appliance

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

202

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

203

Volume 4: Securing the Blue Coat SG Appliance

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

204

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

205

Volume 4: Securing the Blue Coat SG Appliance

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

206

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

207

Volume 4: Securing the Blue Coat SG Appliance

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

208

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

209

Volume 4: Securing the Blue Coat SG Appliance

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

210

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

211

Volume 4: Securing the Blue Coat SG Appliance

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

212

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

213

Volume 4: Securing the Blue Coat SG Appliance

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

214

Appendix B: Using the Authentication/Authorization Agent

The Blue Coat Systems Authentication and Authorization Agent (BCAAA) allows SGOS 5.x to manage authentication and authorization for several different realms. The agent is installed and configured separately from SGOS 5.x and is available at the Blue Coat Website. The BCAAA service must be installed on a domain controller or member server, allowing the SG to access domain controllers. The BCAAA service authenticates users in all domains trusted by the computer on which it is running. A single installation of the BCAAA service can support multiple appliances. Multiple versions of BCAAA can run on the same machine. This allows you to use the same machine to support versions of the SG that have different BCAAA version requirements. The BCAAA install directory can include multiple executable programs. ❐

The program bcaaa.exe (bcaaa on Solaris) handles connections from SG appliances and hands them off to the correct version of the processor.

❐

The program bcaaa-99.exe (bcaaa-99 on Solaris) handles communication with versions of the SG prior to SGOS 4.2.

❐

The program bcaaa-100.exe (bcaaa-100 on Solaris) handles communication with SGOS 4.2.1, SGOS 5.1.1, and SGOS 5.1.2.

❐

The program bcaaa-110.exe (bcaaa-110 on Solaris) handles communication with SGOS 4.2.2 , SGOS 5.1.3, and SGOS 5.1.4.

❐

The program bcaaa-120.exe (bcaaa-120 on Solaris) handles communication with SGOS 4.2.3, SGOS 4.2.4, and SGOS 5.2.1 and later.

When a new version of BCAAA is installed in the same installation directory as earlier versions, the earlier versions are not removed. This allows SG appliances that were communicating with the old version to continue to operate.

Using the BCAAA Service Several realms use the BCAAA service: ❐

IWA: The BCAAA service uses an Integrated Windows Authentication (IWA) to authenticate a user with Active Directory. When using IWA, the network typically chooses automatically whether to use NTLM or Kerberos (IWA). •

NTLM: NTLM is a subset of IWA, meant to be used with Windows NT systems.

•

Kerberos: If using Kerberos, the BCAAA service must share a secret with a Kerberos server (called a KDC) and register an appropriate Service Principal Name (SPN). For information on sharing a secret and registering an SPN, see “Creating Service Principal Names for IWA Realms” on page 223.

215

Volume 4: Securing the Blue Coat SG Appliance

❐

SiteMinder and COREid: When a SiteMinder or COREid realm is referenced in policy, a BCAAA process is created. The SG appliance then sends a configuration request that describes the servers to use. The BCAAA service logs in to the appropriate servers and determines configuration information to be passed back to the SG appliance (such as the kind of credentials required). Responses from the SiteMinder and COREid policy servers are translated into appropriate BCAAA protocol responses and returned to the SG appliance . Before you can use the BCAAA service with SiteMinder or COREid, you must configure the appropriate SG realm to work with the SiteMinder or COREid servers. The realm can be configured from the SiteMinder or COREid configuration tabs in the Management Console or from the CLI. Note:

Each (active) SiteMinder realm on the SG should reference a different agent on the Policy Server. For specific information about configuring the SiteMinder realm to work with the CA eTrust policy servers, see Chapter 12: "CA eTrust SiteMinder Authentication" on page 143. For specific information about configuring the COREid realm to work with Oracle COREid Access Servers, see Chapter 6: "Oracle COREid Authentication" on page 79. ❐

Windows Single Sign-on (SSO): The BCAAA service is used to supply mappings for IP addresses to logged on users. The Windows SSO realm can use domain controller querying, or client querying, or both domain controller and client querying to determine the logged-on user. To use domain controller querying, you must configure the sso.ini file to enable it and to add the domain controllers you want to query. For information on configuring the sso.ini file, see “Modifying the sso.ini File for Windows SSO Realms” on page 188.

❐

Novell SSO: The BCAAA service manages communication with the Novell eDirectory server. This realm also requires that the sso.ini file be configured. For information on configuring the sso.ini file, see “Modifying the sso.ini File for Novell SSO Realms” on page 171.

Performance Notes Blue Coat recommends that the Windows BCAAA service be installed on a dedicated Windows machine. Installation of any other non-essential software might degrade the BCAAA service performance, which in turn degrades the user experience. This is because the BCAAA server is in the client data path for accessing protected resources. Users make client requests to the SG appliance, which in turn proxies authentication requests to the BCAAA service. The user must wait for the authentication request to complete before the SG appliance responds to the user with a protected resource. Operating system requirements are: ❐

IWA and COREid: Windows® 2000 or later.

❐

SiteMinder: Windows 2000 or later or Solaris™ 5.8 or 5.9.

❐

Novell SSO: Windows 2000 or later

❐

Windows SSO: Windows 2000 or later

216

Appendix B: Using the Authentication/Authorization Agent

The appendix discusses: ❐

“Installing the BCAAA Service on a Windows System”

❐

“Installing the BCAAA Service on a Solaris System” on page 222

❐

“Creating Service Principal Names for IWA Realms” on page 223

❐

“Troubleshooting Authentication Agent Problems” on page 225

❐

“Common BCAAA Event Messages” on page 225

Installing the BCAAA Service on a Windows System All images in this section are from a Windows 2000 system. For information on SSL issues with systems running pre-Windows 2003, skip to “Notes on SSL and Systems Running pre-Windows 2003” on page 222 after installation is complete; for information on specific issues with systems running Windows 2003 or later, skip to “Notes on SSL and Systems Running Windows 2003 and Later” on page 222 after installation is complete. Note: The firewall on Windows machine should be disabled for BCAAA to work.

To install the authentication agent: 1.

Download the file from the Blue Coat download site at https://download.bluecoat.com/

2.

Launch the install wizard.

3.

Click Next to select the destination folder. Note: When doing an upgrade from one version of BCAAA to another version of BCAAA, you must install into the previous BCAAA folder to retain your settings. If you install to a different folder, a new .ini file with default settings is created.

4.

Click Browse to select a different destination folder for the BCAAA service.

5.

Click Next to accept the default and select the port number.

217

Volume 4: Securing the Blue Coat SG Appliance

6.

The port number must match the port number you specify on the SG for the BCAAA service. The default is 16101.

7.

Click Next to select the number of threads.

8.

The recommended (and default) value is 2. The maximum number of threads allowed is 99 per SG. After selecting the number, click Next to specify the SSL requirements.

9.

The default is that SSL is Permitted, allowing both SSL and non-SSL connections. This setting must be compatible with the setting on the SG appliance.

10. Click Next to specify the subject of the SSL certificate.

218

Appendix B: Using the Authentication/Authorization Agent

11. Specify the subject of the certificate. The BCAAA service looks up the specified subject in the service's certificate store. If it finds the subject, it uses it instead of generating a new certificate. If not, it generates a self-signed certificate with that subject. This generated certificate can be saved (as specified on the next screen). 12. Click Next to specify save options for the certificate.

13. Click Next to specify whether the SG appliance must provide a valid certificate when connecting to the BCAAA service.

219

Volume 4: Securing the Blue Coat SG Appliance

14. To force the SG to provide a valid certificate to connect to the BCAAA service, select the Yes radio button. The default is No. 15. Click Next to view the summary of the changes you made. 16. Click Install to install the BCAAA service using the settings you configured. When installation completes, the final BCAAA screen displays. To modify settings or uninstall the authentication agent: 1.

Launch the install wizard.

2.

Click Modify to re-enter the installation wizard; click Remove to uninstall the BCAAA service from the system. Note: For instructions on using the installation wizard, see “Installing the BCAAA

Service on a Windows System” on page 217. 3.

Click Next to start the procedure.

4.

Click Finish to exit the uninstall application.

220

Appendix B: Using the Authentication/Authorization Agent

To view the application event log The BCAAA service logs all errors to the Windows 2000 Application Event Log under the name BCAAA. 1.

Launch the Event Log.

2.

Doubleclick the information message BCAAA service to see that the BCAAA service has been automatically started.

To view the BCAAA service The BCAAA service logs all errors to the Windows 2000 Application Event Log under the name BCAAA. 1.

Launch the Event Viewer.

2.

Right-click on BCAAA and select Properties to manage the service. For example, to make the BCAAA service start only manually, set the Startup Type to Manual. (Automatic is the default setting.)

Completing Setup for the BCAAA Service Once the BCAAA service is installed, you must complete BCAAA setup by configuring the service to work with Windows. To configure the BCAAA service: 1.

2.

Open the properties panel for the BCAAA service. a.

Select the Log-on tab.

b.

Change the account to the one you created for the BCAAA service, and enter the password.

c.

Click OK. You might be warned that the account has been given logon as service privileges.

Verify in Local Security Policy's User Rights Assignment folder that the BCAAA Service user account has been added to the list of the Log on as a service policy. Note:

3.

You must have modify/write privileges in the BCAAA folder.

(Optional) If group-based authorization is being done, then: •

Ensure that the user impersonation privilege is set for the SERVICE group. For more information setting the user impersonation privilege, see: http:// support.microsoft.com/default.aspx?scid=kb;en-us;831218.

•

Ensure that the Active Directory computer account running the BCAAA service has the Trust computer for delegation configuration property enabled.

4.

(Optional) For all users authenticating to the SG using IWA realms, user accounts in the Active Directory must have permission to log onto the machine where the BCAAA server is running.

5.

Go to the user’s account properties user account tab.

6.

Click the Log On To… button to specify the domain that computers can log onto. If the network environment restricts users to specific computers, then each user must have the name of the host running the BCAAA service added to their list.

221

Volume 4: Securing the Blue Coat SG Appliance

Notes on SSL and Systems Running pre-Windows 2003 The BCAAA service fails to negotiate an SSL connection under certain conditions when the BCAAA user is changed. If the BCAAA was originally running as LocalSystem and a self-signed certificate was created and saved (that is, you chose to save the automatically generated certificate option) SSL fails if the BCAAA service is changed to run as a different user. To solve this: 1.

Stop the BCAAA service.

2.

From the Run prompt, type mmc, which is the Microsoft Management Console.

3.

Click File > Add/Remove Snap-in > Add > Certificates > Add Service Account > Local Computer > BCAAA

4.

Delete any certificate shown in the BCAAA/Personal category.

Now when the BCAAA is run, it can create a new certificate and successfully handle an SSL connection.

Notes on SSL and Systems Running Windows 2003 and Later The BCAAA service fails to negotiate an SSL connection under certain conditions when the BCAAA user is changed. The certificate store can only be accessed by a Domain Administrator or LocalSystem. If the BCAAA service is running as a Domain User who does not have Domain Administrator privileges, it cannot negotiate an SSL connection. Solutions: ❐

Make the BCAAA user a Domain Administrator or an Administrator of the computer where the BCAAA service is running.

❐

Give the BCAAA user access the certificate store: •

Stop the BCAAA service.

•

From the Run prompt, launch the regedit program to give the BCAAA user full access to the following key and its children: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Services

Installing the BCAAA Service on a Solaris System To install the BCAAA service on Solaris, complete the following instructions. You must be root to complete installation. Note: For successful installation of the BCAAA service on a Solaris system, you need libstdc++.so.5", usually installed with package SFWgcc32 gcc-3.2 - GNU Compiler Collection Version 3.2

1.

Download the shell script to your system.

2.

Execute the shell script: # sh bcaaa-version_number-SOLARIS-install.sh

222

Appendix B: Using the Authentication/Authorization Agent

3.

Answer the questions to install the service on your Solaris system. A sample session is shown below: Enter a path to a scratch directory [/tmp]: Install Blue Coat Systems Authentication and Authorization Agent (BCAAA)? (y/n)y Enter user that should own the installed files [root] Enter group for the installed files [root] /usr/local/bin/bcaaa installed /usr/local/bin/bcaaa-100 installed Libraries installed in /usr/local/lib/BlueCoatSystems/ /usr/local/etc/bcaaa.ini installed If you use inetd, append the following line to /etc/services bcaaa 16101/tcp Authentication Agent

#Blue Coat Systems

If you use inetd, append the following line to /etc/inetd.conf, then signal inetd to re-read the configuration file If you use something else, make the equivalent changes bcaaa stream tcp nowait root /usr/local/bin/bcaaa bcaaa -c /usr/local/ etc/bcaaa.ini Installation complete

Creating Service Principal Names for IWA Realms For the BCAAA service to participate in an IWA Kerberos authentication exchange, it must share a secret with the Kerberos server (called a KDC) and have registered an appropriate Service Principal Name (SPN). You can share the secret two ways: ❐

LocalSystem In this approach the SPN is registered with the NetBIOS name of the machine on which BCAAA is running. BCAAA runs under LocalSystem (the default for services), and uses the machine's shared secret. The primary advantage of this approach is convenience: it works with the default settings for service installation. The disadvantage is that only one BCAAA server is allowed for the realm, so you cannot have a backup server. Note: Handling of the shared secret is done by Windows when the machine joins the

domain; there is no explicit knowledge of the shared secret by SGOS or by BCAAA. ❐

Service Account You can also create a service account for the BCAAA service and register the SPN on the service account. This allows multiple servers to run BCAAA all using the same account. The advantage is the ability to have a backup BCAAA server. The disadvantage is that it requires additional configuration on the Active Directory server, the domain controller, and on each BCAAA machine. It is also less secure, since the BCAAA account password is shared among multiple machines.

223

Volume 4: Securing the Blue Coat SG Appliance To share a secret by creating a service account: Note: All steps require administrator privileges.

1.

Go to the Active Directory server.

2.

Create an account for use by the BCAAA service.

3.

Create a password.

4.

On the domain controller, open the domain policy console and modify the Local Policy’s user rights assignment and allow the account you created in on the Active Directory to have the right to "act as the operating system."

5.

Run the following command: setspn -A HTTP/FQDN-of-host name

where name is the name of the account created in step 1 and the FQDN is the virtual URL that was set in the authentication realm. For example: setspn -A HTTP/krbproxy.authteam.waterloo.bluecoat.com authteam\krbbcaaa Note:

The setspn application might have to be downloaded from Microsoft. It is installed by default in program files\resource kit. (Optional) To create a group account (a BCAAA user account capable of doing group-based authorization): If group-based authorization is being done, then: 1.

Ensure that the user impersonation privilege is set for the SERVICE group. Note:

For information on setting the user impersonation privilege, see

http://support.microsoft.com/default.aspx?scid=kb;en-us;831218

2.

Ensure that the Active Directory computer account running the BCAAA service has the "Trust computer for delegation" configuration property enabled.

On each machine where you want to run the BCAAA service: 1.

Install the BCAAA service as normal.

2.

Open the Properties panel for the BCAAA service and select the Logon tab. Change the account to the one you created on the Active Directory server, and enter the password. When you click OK, it might warn you that the account has been granted "Log On as A Service right".

3.

Change the security on the BCAAA install directory to give the account created on the Active Directory server full control.

All these machines now share the same secret with the KDC and can decrypt service tickets intended for the service described by the SPN.

224

Appendix B: Using the Authentication/Authorization Agent

Troubleshooting Authentication Agent Problems This section describes some common problems you might encounter when setting up or using the BCAAA service on a Windows platform. To troubleshoot the BCAAA service, launch the event viewer. The Properties pane displays, providing information about the status of the BCAAA service at that time. Note the Type and the Event ID. The description below the Type/ Event ID lists the problem. You can often find more information about the problem and suggestions for its solution in “Common BCAAA Event Messages” on page 225. Common problems: ❐

If an attempt to start the BCAAA service is issued when BCAAA is already started, the following error message displays: The requested service has already been started.

❐

If another application is using the same port number as the BCAAA service, the following messages are displayed: The BCAAA service could not be started. A system error has occurred. System error 10048 has occurred. Only one usage of each socket address (protocol/network address/port) is normally permitted.

Common BCAAA Event Messages Following are the most common event messages that can be logged to the Windows 2000 Application Event Log. Most of the event messages not listed here are error status messages returned by Win32 function calls. When a Win32 call fails, the error code and error text containing the reason for the error displays in the event log under the name BCAAA. To view the BCAAA event log: 1.

Right click on My Computer and select Manage.

2.

Select System Tools > Event Viewer > Application.

For each BCAAA event message, the event message is displayed along with the event number. Table B-1. BCAA Event Messages Message ID

Message

Description

200

Various messages

The associated message provides information about a condition that is not an error.

300

Various messages

The associated message warns about an unexpected condition that does not prevent operation.

400

Various messages

The associated message describes an error condition that prevents normal operation.

1001

Authentication Agent service started: port=# threads=# socket=0x# process id=# agent version=# SG Appliance version=#

This indicates successful startup and provides information about the agent.

225

Volume 4: Securing the Blue Coat SG Appliance

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

1002

Authentication Agent stopped

This indicates normal shutdown of the service.

1003

SG Appliance (a.b.c.d) connected; Process # spawned as #

This indicates a SG appliance has connected to the agent (Windows only).

1004

SG Appliance agent process exited (normal logout)

This indicates normal logout by a SG appliance.

1005

Process %d has terminated, ExitCode=0x#, link=0x#

This indicates an unexpected termination of an agent process (Windows only).

1006

Service dispatcher exited.

This indicates an unexpected termination of the service dispatcher.

1007

CreateNamedPipe failed, pipe='%s'

The agent dispatcher could not create the named pipe for the reason given.

1008

ConnectNamedPipe failed, pipe='%s'

The agent process could not obtain the information from the dispatcher on the named pipe for the reason given.

1009

WriteFile failed, pipe='%s'

The dispatcher could not write information to the named pipe for the reason given.

1011

CreateThread (ProcessTimerThread) failed

The dispatcher could not create its timer thread.

1012

Failed to create SG Appliance process '%s'

1019

Various

The dispatcher was unable to determine the exit status of an agent process.

1020

Terminating SG Appliance process #, ProcNum=# Handle=0x#

An agent process was active when the Windows service was shut down.

1022

Various

The associated message reports the status of a SG appliance login attempt.

1101

BasicAuth: CloseHandle failed; user 'xx\\xx'

The agent was unable to close the login handle for the specified user.

1102

Username: '%s\\%s' too long

The SG appliance offered the specified username, which is too long.

1106

Various

An attempted authentication using BASIC credentials failed for the reason given.

1107

User Right 'Act as part of the operating system' required for Basic Authentication

The agent does not have the necessary privileges to do BASIC authentication

1108

Various

The agent was unable to determine information about the user for the reason given.

1202

Unable to create GroupsOfInterest mutex 'xx' - already exists

The agent could not create the Windows mutex needed for group authorization checks because it already exists.

1203

Unable to create GroupsOfInterest mutex 'xx

The agent could not create the Windows mutex needed for group authorization checks.

The BCAAA server does not have the same version of BCAAA available as the SG is expecting.

226

Appendix B: Using the Authentication/Authorization Agent

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

1204

OpenMutex failed for AuthGroups mutex '%s', group='%s'

The agent was unable to open the Windows mutex needed for group authorization checks.

1205

Various

The agent was unable to close the Windows mutex named for the reason given.

1207

GetAclInformation failed

The agent was unable to obtain ACL information needed to do group authorization checks.

1209

GetKernelObjectSecurity failed for AuthGroup='%s'

The agent was unable to obtain security information about the specified group.

1210

SetKernelObjectSecurity failed

The agent was unable to set up security information for the reason specified.

1211

InitializeSecurityDescriptor failed

The agent was unable to initialize the security descriptor for the reason specified.

1212

GetSecurityDescriptorDacl failed

The agent was unable to get the discretionary access control list (DACL) for the reason specified.

1213

SetSecurityDescriptorDacl failed

The agent was unable to set the discretionary access control list (DACL) for the reason specified.

1214

InitializeAcl failed

The agent was unable to initialize the access control list (ACL) for the reason specified.

1215

GetUserName failed for AuthGroup='%s'

The agent was unable to determine the username while processing the specified group.

1217

GetAce failed for AuthGroup='%s'

The agent was unable to get the access control entry (ACE) for the specified group.

1218

AddAce failed

The agent was unable to add the necessary access control entry (ACE) for the reason specified.

1219

AddAccessAllowedAce failed

The agent was unable to add the necessary "access allowed" access control entry (ACE).

1220

Could not establish groups-of-interest: result=0x##

The agent was unable to initialize groups-of-interest checking.

1221

AuthGroup '%s' does not exist

The specified group does not exist.

1222

IWA RevertSecurityContext failed, user='%s'

The agent could not revert the security context for the specified user.

1223

BASIC: RevertToSelf failed, user='%s'

The agent could not revert the security context for the specified user.

1224

Error calling OpenProcessToken

The agent's call to OpenProcessToken failed for the specified reason.

1225

Error calling LookupPrivilegeValue

The agent could not get information about a needed privilege.

1226

Error calling AdjustTokenPrivileges

The agent could not adjust its privileges as required.

1227

ImpersonateLoggedOnUser failed; Group access denied for user '%s'

The agent could not impersonate the specified user.

227

Volume 4: Securing the Blue Coat SG Appliance

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

1228

IWA: ImpersonateSecurityContext failed; Group access denied for user '%s'

The agent could not impersonate the specified user.

1301

NOTE: Pending ContextLink=### timed out; deleting SecurityContext h=## TS=## now=##

The SG appliance did not provide a response to a challenge quickly enough.

1302

Various

An authentication request from a SG appliance referenced an in-progress request that has timed out or does not exist.

1304

Various

The agent was unable to delete a security context for the reason given.

1305

AcceptSecurityContext failure, SEC_E_INVALID_HANDLE, ContextLink=### count=#

The agent was provided with an invalid context handle.

1306

Various

The client provided an invalid token to the authentication system.

1308

AcceptSecurityContext failure, ContextLink=# count=#, detail=#(xxx)

Windows rejected the authentication attempt for the reason given.

1310

Various

This records the failure of NTLM authentication or group authorization.

1311

3:Failed NTLM Authentication for user: '%s'

This records the failure of NTLM authentication; the user name was supplied by the client.

1312

Various

The agent could not determine the username from the NTLM type 3 message supplied by the client.

1313

Invalid Type3 message

The client provided an NTLM type 3 message that was invalid.

1314

BASE64_Decode: Length of token exceeds max (%d)

The client provided an NTLM token that was too long.

1316

Unsupported version in request: %d(0x%x)

The SG appliance sent a request with an unsupported version number.

1401

Various

The agent lost communication with the SG appliance.

1403

Various

The agent is aborting for the reason given.

1402

Unexpected thread 0 exit

The agent exited unexpectedly.

1404

Unable to get ProcessInfo from parent process.

The agent could not obtain its information from the dispatcher.

1405

CreateFile failed, pipe='xx'

The agent could not create a handle for the dispatcher's named pipe.

1406

WaitNamedPipe failed, pipe='%s'

The agent could not wait for the dispatcher's named pipe.

1407

ReadFile failed, pipe='%s'

The agent could not read information from the dispatcher's named pipe.

228

Appendix B: Using the Authentication/Authorization Agent

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

1409

Various

The agent could not create the specified thread for the reason given.

1412

Various

The agent could not create a required Windows event object.

1413

AuthMethod 'xxs' not supported: returning _AuthResult=0x##

The SG appliance requested an unsupported authentication mechanism.

1414

Various

The specified request is unsupported.

1500

Various

The agent has a problem with memory allocation; typically this means there is not enough memory.

1501

Unable to allocate memory for ProcLink buffer.

The agent could not allocate some needed memory.

1502

Unable to allocate memory for ContextLink buffer.

The agent could not allocate some needed memory.

1503

Various

The agent was unable to allocate needed memory.

1604

Service dispatch failed

The Windows service dispatcher failed to start.

1605

RegisterServiceCtrlHandler failed

The agent dispatcher was unable to register the service control handler.

1608

SetServiceStatus failed, g_StatusHandle=%d

The agent was unable to set the service's status.

1610

Unsupported service control code: #

Windows sent a service control code that the agent does not support.

1701

WSASocket failed

The agent could not create a Windows socket for the reason given.

1702

WSAStartup failed.

The agent could not start the Windows socket for the reason given.

1703

Various

The agent could not send data to the SG appliance for the reason given.

1704

Various

The agent could not receive data from the SG appliance for the reason given.

1705

accept failed

The agent dispatcher could not initialize to accept new connections.

1706

bind failed, PortNumber=#

The agent dispatcher could not bind to the specified port.

1707

listen failed.

The agent dispatcher could not listen for new connections.

1708

Various

Windows reported an event wait failure to the agent while doing I/O on the socket.

1709

The agent is already running or the agent's port # is in use by another process

Some other process is already using the port needed by the agent.

229

Volume 4: Securing the Blue Coat SG Appliance

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

1710

WSARecv failed reading bytes from socket

Windows reported an error when the agent tried to receive bytes from the SG appliance.

1711

WSASend failed sending bytes to socket. Windows reported an error when the agent tried to send bytes to the SG appliance.

1712

Various

A socket I/O operation did not complete successfully.

1801

Error calling AcquireCredentialsHandle

The agent could not acquire its credentials from Windows.

1803

Various

The agent could not load a needed library (DLL).

1804

Various

The agent could not locate the needed services in a library (DLL).

1805

Unsupported SSPI Windows platform; PlatformId=#

The reported Windows platform is not supported for NTLM authentication.

1806

Error calling QueryContextAttributes

The agent could not determine the authenticated user's security attributes.

1807

QuerySecurityPackageInfo failed

The agent could not get needed security information from Windows.

1808

Max Token size too long (#); max size is #

The client supplied an NTLM token that is too long.

1809

FreeContextBuffer failed

An attempt to free the NTLM context buffer failed.

1811

Username 'x\\y' too long

The reported user name is too long.

1901

Admin Services Error: Access denied to domain/user/group information

The agent was unable to access necessary information.

1902

Admin Services Error: Invalid computer from which to fetch information

The computer to be used to get security information is invalid.

1903

Admin Services Error: Group not found

The requested group could not be found.

1904

Various

The reported error was encountered while browsing.

1905

Admin services error: could not translate context to Unicode

The requested object for browsing could not be translated to Unicode

1906

Admin service out of memory

The browsing service ran out of memory.

1907

Search request object too long: # > #

The requested object for browsing is too long.

2000

AcquireCredentialsHandle failed: 0x#

The agent could not acquire the credentials needed for an SSL session.

2001

Various

The agent was unable to negotiate an SSL session for the reason given.

2002

Various

An I/O error occurred during an SSL session.

2003

Various

The specified cryptographic error occurred during an SSL session.

230

Appendix B: Using the Authentication/Authorization Agent

Table B-1. BCAA Event Messages (Continued) Message ID

Message

Description

2004

Various

The specified problem occurred with a certificate during SSL negotiation.

231

Volume 4: Securing the Blue Coat SG Appliance

232

Appendix C: Managing the SSL Client

Understanding the SSL Client The SSL client is used to determine various SSL parameters for outgoing HTTPS connections. Specifically, its role is to: ❐

Identify the SSL protocol version the SG uses in negotiations with origin servers.

❐

Identify the cipher suites used.

❐

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

Creating an SSL Client The SG is configured with a default SSL client. Creation of the SSL client means that for every HTTPS connection to the destination server, the SG picks the parameters needed for negotiating the SSL connection from the SSL-client configuration. Thus, multiple SSL connections to different HTTPS destination servers can be supported with a single SSL-client configuration. This is similar to a browser where one configuration is used to negotiate multiple connections with different hosts. When the SG is acting as an SSL client (SSL origination), SSL sessions are re-used until the server forces a fresh handshake or until the same session ID has been used 255 times. If you just need to change the protocol, the cipher suites, or the keyring associated with the SSL client, you do not need to recreate the client. Continue with “Associating a Keyring and Protocol with the SSL Client” on page 233 or “Changing the Cipher Suites of the SSL Client” on page 234. To create the SSL client: SGOS#(config ssl) create ssl-client default defaulting protocol to SSLv2v3TLSv1 defaulting associated keyring-id to default ok

To delete the SSL client: SGOS#(config ssl) delete ssl-client default ok

Associating a Keyring and Protocol with the SSL Client The SSL client, called default, already exists on the SG. 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: 1.

Select Configuration>SSL>SSL Client.

2.

Verify Use SSL Client is selected.

233

Volume 4: Securing the Blue Coat SG Appliance

3.

Only keyrings with certificates can be associated with the SSL client, displayed in the Keyring drop-down list. Select the keyring used to negotiate with origin content servers through an encrypted connection.

4.

You can change the SSL Versions default from SSLv2v3TLSv1 to any other protocol listed in the drop-down list.

5.

Click OK; click Apply

Related CLI Syntax to Associate a Keyring and Protocol with the SSL Client SGOS#(config) ssl SGOS#(config ssl) edit ssl-client default SGOS#(config ssl ssl-client default) keyring-id keyring_id SGOS#(config ssl ssl-client default) protocol {sslv2 | sslv3 | tlsv1 | sslv2v3 | sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1}

Changing the Cipher Suites of the SSL Client The cipher suite sets the encryption method used by the SG. As the encryption key strength is determined by the signed certificate, configuring a higher cipher suite than defined by the certificate has no affect. Conversely, the cipher suite configuration must be high enough to accommodate certification encryption values. This can only be done through the CLI. To change the cipher suite of the SSL client: The default is to use all ciphers. You have a choice of using the interactive or non-interactive create command. Note: Director uses non-interactive commands in profiles and overlays to create cipher suites. For more information on Director, refer to the Blue Coat Director Configuration and Management Guide.)

To change the cipher suites used through the: ❐

interactive command: continue with the next procedure.

❐

non-interactive command: skip to “To change the cipher suites non-interactively:” on page 235.

To change the cipher suites using the interactive cipher-suites command: Note that the Use column in the set cipher-suite output below indicates that the default is to use all ciphers. 1.

Choose the cipher suites you want to use at the prompt. SGOS#(config) ssl SGOS#(config ssl) edit ssl-client default SGOS#(config ssl ssl-client default) cipher-suite SSL-Client Name -------------default

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

Protocol -----------SSLv2v3TLSv1

234

Appendix C: Managing the SSL Client

Cipher# ------1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Use --yes no no no no no no no no no no no no no no no no

Description -------------------RC4-MD5 RC4-SHA DES-CBC3-SHA DES-CBC3-MD5 RC2-CBC-MD5 RC4-64-MD5 DES-CBC-SHA DES-CBC-MD5 EXP1024-RC4-MD5 EXP1024-RC4-SHA EXP1024-RC2-CBC-MD5 EXP1024-DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 EXP-DES-CBC-SHA AES128-SHA AES256-SHA

Strength -------Medium Medium High High Medium Low Low Low Export Export Export Export Export Export Export Medium High

Select cipher numbers to use, separated by commas: 1,3,4 ok

2.

(Optional) View the results. Notice the change in the Use column. SGOS#(config ssl ssl-client default) view SSL-Client Name --------------default Cipher# ------1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Use --yes no yes yes no no no no no no no no no no no no no

Keyring Name -----------default Description -------------------RC4-MD5 RC4-SHA DES-CBC3-SHA DES-CBC3-MD5 RC2-CBC-MD5 RC4-64-MD5 DES-CBC-SHA DES-CBC-MD5 EXP1024-RC4-MD5 EXP1024-RC4-SHA EXP1024-RC2-CBC-MD5 EXP1024-DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 EXP-DES-CBC-SHA AES128-SHA AES256-SHA

Protocol -----------SSLv2v3TLSv1 Strength -------Medium Medium High High Medium Low Low Low Export Export Export Export Export Export Export Medium High

To change the cipher suites non-interactively: Enter the following commands: SGOS#(config) ssl SGOS#(config ssl) edit ssl-client default SGOS#(config ssl ssl-client default) cipher-suite cipher-suite ciphersuite

235

Volume 4: Securing the Blue Coat SG Appliance

where [cipher-suite] can be any combination of the following: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

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 aes128-sha aes256-sha

Notes: ❐

If you do not specify any attributes, the interactive mode is assumed and the cipher suites cannot be used by Director in profiles or overlays.

❐

Multiple cipher suites can be specified on the command line.

Example SGOS#(config ssl ssl-client default) cipher-suite rc4-md5 des-cbc3-md5 exp1024-rc4-md5 exp-des-cbc-sha ok SGOS#(config ssl ssl-client default) view SSL-Client Name Keyring Name Protocol -----------------------------------default default SSLv2v3TLSv1 Cipher# ------1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Use --no no no no no no no no no no no no no no yes no no

Description -------------------RC4-MD5 RC4-SHA DES-CBC3-SHA DES-CBC3-MD5 RC2-CBC-MD5 RC4-64-MD5 DES-CBC-SHA DES-CBC-MD5 EXP1024-RC4-MD5 EXP1024-RC4-SHA EXP1024-RC2-CBC-MD5 EXP1024-DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 EXP-DES-CBC-SHA AES128-SHA AES256-SHA

Strength -------Medium Medium High High Medium Low Low Low Export Export Export Export Export Export Export Medium High

236

Appendix C: Managing the SSL Client

Troubleshooting Server Certificate Verification Server certificate verification can be disabled for all upstream hosts or specific upstream hosts. The SG, by default, verifies the SSL certificate presented by the upstream HTTPS server. However, it fails to negotiate the SSL connection if SSL certificate verification fails. The two most common causes of server certificate verification failure are: ❐

The absence of a suitable CA certificate on the SG. Be sure that the SG is configured with the relevant CA certificates to avoid unwanted verification failures.

❐

If a forwarding host of type HTTPS server is being used, you can override the default behavior by changing the ssl-verify-server option on a per-host basis.

❐

The server is using a self-signed certificate. In this case, you need to change the keyring to one that has a CA certificate.

Setting the SSL Negotiation Timeout The SSL negotiation timeout value dictates the time a SG waits for a new SSL handshake to complete. This value applies to both the HTTPS Reverse Proxy and SSL origination. You can change the default SSL negotiation timeout value if the default, 300 seconds, is not sufficient for your environment. This value can only be changed through the CLI; it cannot be set from the Management Console. To change the HTTPS Reverse Proxy timeout period, enter the follow commands from the command prompt: SGOS#(config) ssl SGOS#(config ssl) view ssl-nego-timeout 300 SGOS#(config ssl) ssl-nego-timeout seconds

237

Volume 4: Securing the Blue Coat SG Appliance

238

Appendix D: XML Protocol

The XML realm uses a SOAP 1.2 based protocol for the Blue Coat supported protocol. A schema has been placed at http://www.bluecoat.com/xmlns/xml-realm/1.0. This appendix includes the following sections: ❐

Section A: "Authenticate Request" on page 240

❐

Section B: "Authenticate Response" on page 242

❐

Section C: "Authorize Request" on page 244

❐

Section D: "Authorize Response" on page 245

239

Volume 4: Securing the Blue Coat SG Appliance Section A: Authenticate Request

Section A: Authenticate Request GET Method (User Credentials in Request) If the user credentials are not set in the HTTP headers, the username and password are added to the query. The name of the username parameter is configured in the realm. The groups and attributes of interest are only included if the realm is configured to include them. http://:/?=&password=[&group=&group=…&attribute=&attribute=]

GET Method (User Credentials in Headers) If the user credentials are in the HTTP headers, the password is not added to the query. http://:// authenticate?=[&group=&group=…&attribute=&attribute=]

POST Method (User Credentials in Request) The parameter name of the username is configured in the realm. The groups and attributes of interest will only be included if the realm is configured to include them. Username password group1 group2 attribute1 attribute2

POST Method (User Credentials in Headers) If the user credentials are in the HTTP headers, the password is not added to the request.

240

Appendix D: XML Protocol

Section A: Authenticate Request Username challenge state group1 group2 attribute1 attribute2

241

Volume 4: Securing the Blue Coat SG Appliance Section B: Authenticate Response

Section B: Authenticate Response Success All of the response fields except "full-username" are optional. The intersection of the groups of interest and the groups that the user is in are returned in the groups element. The attributes of interest for the user are returned in a flattened two dimensional array of attribute names and values. full-username group2 attribute2 value2a attribute2 value2b attribute2 value2c

Failed/Denied The failed response includes a text description of the failure that becomes the text description of the error reported to the user. The fault-code is one of a set of SGOS authentication errors that can be returned from the responder. The codes are returned as strings, but are part of an enumeration declared in the schema for the protocol. Only codes in this list are acceptable. account_disabled account_restricted credentials_mismatch general_authentication_error expired_credentials account_locked_out account_must_change_password offbox_server_down general_authorization_error unknown_error env:Sender

242

Appendix D: XML Protocol

Section B: Authenticate Response Bad username or password general_authentication_error

243

Volume 4: Securing the Blue Coat SG Appliance Section C: Authorize Request

Section C: Authorize Request The groups and attributes of interest for the user are embedded in the request if they are configured to be included. The XML responder must not require credentials for authorization requests.

GET Method http://:/?=[&group=&group=…&attribute=&…]

POST Method Username group1 group2 attribute1 attribute2

244

Appendix D: XML Protocol

Section D: Authorize Response

Section D: Authorize Response Success Only applicable groups and attributes are returned. Multi-valued attributes are returned by multiple instances of the same attribute name. group2 attribute2 value2a attribute2 value2b attribute2 value2c

Failed env:Receiver Could not contact LDAP server offbox_server_down

245

Volume 4: Securing the Blue Coat SG Appliance Section D: Authorize Response

246

Appendix E: Authentication and Authorization Errors

Following is the list of all groups and individual errors that can be permitted during authentication and authorization. The first table lists the groups and the individual errors within each group. The second table lists all of the individual errors along with descriptions of the errors. Table E-1. Groups and Individual Errors Error Group

CPL

Members

Description

All

All

account_disabled account_expired account_locked_out account_must_change_password account_restricted account_wrong_place account_wrong_time agent_config_changed agent_config_cmd_failed agent_connection_failed agent_init_failed agent_no_groups_provided agent_resource_not_protected agent_too_many_retries agent_unsupported_scheme authorization_username_too_long

Includes all errors that can be permitted. Note that this group includes errors such as need_credentials which if permitted will result in the user never being challenged. As this is not the desired behavior for most realms (i.e. the user should be given the chance to enter credentials) do not permit this group when using challenge realms. Instead, use combinations of the other error groups as appropriate.

basic_password_too_long basic_username_too_long cannot_decrypt_secret cannot_determine_authorization_ username cannot_determine_full_username cannot_determine_username cannot_expand_credentials_ substitution cannot_redirect_connect cannot_redirect_https_to_http cannot_setup_working_dir cert_explicit_unsupported certificate_missing credential_decode_failure credentials_mismatch

247

Volume 4: Securing the Blue Coat SG Appliance

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

domain_controller_query_disabled expired_credentials form_does_not_support_connect form_requires_basic_support general_authentication_error general_authorization_error guest_user invalid_ip invalid_license invalid_local_user_list invalid_realm invalid_search_credentials invalid_surrogate issuer_too_long ldap_busy ldap_filter_error ldap_inappropriate_auth ldap_insufficient_access ldap_invalid_credentials ldap_invalid_dn_syntax ldap_loop_detect ldap_no_such_attribute ldap_no_such_object ldap_partial_results ldap_server_down ldap_timelimit_exceeded ldap_timeout ldap_unavailable ldap_unwilling_to_perform missing_base_dn missing_form_configuration multiple_users_matched need_credentials netbios failure netbios_cannot_send netbios_multiple_users netbios_no_computer_name netbios_no_domain_name netbios_no_user_name netbios_recv_failed netbios_reply_invalid netbios_reply_timeout no_offbox_url_specified no_servers no_user_in_cert not_attempted not_ssl offbox_abort offbox_missing_secret offbox_process_create_failed offbox_protocol_error offbox_server_down

248

Appendix E: Authentication and Authorization Errors

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

offbox_server_unreachable offbox_timeout otp_already_used password_too_long radius_socket_interface rdns_cannot_determine_name rdns_failed redirect_from_vh sspi_context_lost sspi_context_too_old sspi_domain_controller_not_found sspi_invalid_handle sspi_invalid_mechanism sspi_invalid_token sspi_invalid_type3_message sspi_logon_denied sspi_logon_type_not_granted sspi_no_authenticating_authority sspi_null_lm_password sspi_process_create_failed sspi_rpc_error sspi_service_disabled sspi_timeout sspi_unable_to_connect_to_agent subject_too_long too_many_users unable_to_query_client unknown_user user_domain_not_trusted username_too_long Communication Error

communication_ agent_connection_failed error ldap_busy ldap_loop_detect ldap_server_down ldap_unavailable ldap_unwilling_to_perform netbios_cannot_send netbios_reply_invalid no_servers radius_socket_interface sspi_no_authenticating_authority sspi_rpc_error sspi_unable_to_connect_to_agent

Includes communication errors with BCAAA, LDAP, and RADIUS servers and during NetBIOS queries.

Configuration Changed

configuration_ changed

agent_config_changed offbox_abort

The SG has been notified that configuration affecting the realm has been changed offbox. Used primarily with SiteMinder and COREid realms.

general_authentication_error

A general authentication error has occurred. This is returned when a specific error does not apply. It does not include all authentication errors.

General general_ Authentication authentication_ Failure failure

249

Volume 4: Securing the Blue Coat SG Appliance

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

General Authorization Failure

general_ authorization_ failure

cannot_determine_authorization_ username

A general authorization error has occurred. This is returned when a specific error does not apply. It does not include all authorization errors. This can be returned as an authentication error in realms that do not support specifying a separate authorization realm.

General Offbox Error

offbox_error

agent_connection_failed agent_init_failed cannot_determine_full_username

general_authorization_error

ldap_busy ldap_loop_detect ldap_server_down ldap_timelimit_exceeded ldap_timeout ldap_unavailable ldap_unwilling_to_perform

Includes all errors that can result with failures found during any offbox configuration or communications. It includes all errors found in the Communication Error group.

netbios failure netbios_cannot_send netbios_multiple_users netbios_no_computer_name netbios_no_domain_name netbios_no_user_name netbios_recv_failed netbios_reply_invalid netbios_reply_timeout no_servers offbox_process_create_failed offbox_protocol_error offbox_server_down offbox_server_unreachable offbox_timeout radius_socket_interface rdns_cannot_determine_name rdns_failed sspi_context_lost sspi_context_too_old sspi_invalid_mechanism sspi_no_authenticating_authority sspi_process_create_failed sspi_rpc_error sspi_timeout sspi_unable_to_connect_to_agent Ident Error

ident_error

Initialization initialization_ Error error

Errors found during Ident query agent_init_failed offbox_process_create_failed sspi_process_create_failed

Internal Error internal_error Invalid BCAAA Request

invalid_bcaaa_ request

Errors related to initializing the realm. Any internal error.

sspi_context_lost sspi_context_too_old sspi_invalid_mechanism

Includes errors returned if the request sent to BCAAA is invalid. Applies to IWA realms only.

250

Appendix E: Authentication and Authorization Errors

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

Invalid Configuration

invalid_ configuration

agent_config_cmd_failed agent_no_groups_provided agent_resource_not_protected agent_too_many_retries agent_unsupported_scheme

Includes any errors that resulted from a possible misconfiguration of the SG. These errors usually require administrator action to address.

cannot_decrypt_secret cannot_determine_full_username cannot_determine_username cannot_setup_working_dir cert_explicit_unsupported domain_controller_query_disabled form_does_not_support_connect form_requires_basic_support invalid_local_user_list invalid_realm invalid_search_credentials ldap_filter_error ldap_inappropriate_auth ldap_insufficient_access ldap_invalid_dn_syntax ldap_no_such_attribute ldap_no_such_object ldap_partial_results missing_base_dn missing_form_configuration no_offbox_url_specified no_servers not_ssl offbox_missing_secret offbox_protocol_error offbox_server_unreachable sspi_domain_controller_not_found sspi_logon_type_not_granted sspi_null_lm_password sspi_service_disabled Invalid License

invalid_license

invalid_license

An invalid license was found for an authentication component.

Invalid NetBIOS Reply

invalid_netbios_ reply

netbios failure netbios_multiple_users netbios_no_computer_name netbios_no_domain_name netbios_no_user_name netbios_recv_failed

The NetBIOS reply was invalid.

251

Volume 4: Securing the Blue Coat SG Appliance

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

Invalid User Information

invalid_user_ info

authorization_username_too_long

Includes errors that result from invalid user information being entered.

basic_password_too_long basic_username_too_long cannot_expand_credentials_ substitution credential_decode_failure credentials_mismatch general_authentication_error invalid_surrogate issuer_too_long ldap_invalid_credentials otp_already_used password_too_long sspi_invalid_handle sspi_invalid_token sspi_invalid_type3_message sspi_logon_denied subject_too_long user_domain_not_trusted username_too_long

RDNS Failure

rdns_failure

Redirect Error redirect_error

Request Timeout

request_timeout

rdns_cannot_determine_name rdns_failed

Errors found during Reverse DNS lookup.

cannot_redirect_connect cannot_redirect_https_to_http redirect_from_vh

Errors found while attempting to redirect the user’s request for authentication. Only returned when using a redirect authentication mode.

ldap_timelimit_exceeded ldap_timeout

Includes timeout errors with authentication servers.

netbios_reply_timeout offbox_timeout sspi_timeout Single Sign-on Failure

sso_failure

invalid_ip multiple_users_matched too_many_users unknown_user unable_to_query_client

User Account Error

user_account_ error

account_disabled account_expired account_locked_out account_must_change_password account_restricted account_wrong_place account_wrong_time

Errors returned during Single Sign-on authentication. These errors apply to Windows SSO and Novell SSO realms only.

Errors with the user’s account.

expired_credentials

252

Appendix E: Authentication and Authorization Errors

Table E-1. Groups and Individual Errors (Continued) Error Group

CPL

Members

Description

User Credentials Required

credentials_ required

certificate_missing

User credentials are required. Do not permit this error if the user should be challenged for credentials.

guest_user need_credentials no_user_in_cert

Table E-2. Individual Errors Error Name

Description

Groups

account_disabled

Account is disabled.

All User Account Error

account_expired

Account has expired.

All User Account Error

account_locked_out

Account is locked out.

All User Account Error

account_must_change_password

Account password must be changed.

All User Account Error

account_restricted

Account is restricted.

All User Account Error

account_wrong_place

Account cannot be used from this location.

All User Account Error

account_wrong_time

Account logon time restricted - cannot be used now.

All User Account Error

agent_config_changed

Agent reports server configuration has changed; please try your request again.

All Configuration Changed

agent_config_cmd_failed

Configuration of the authentication agent failed All Invalid Configuration

agent_connection_failed

The authentication agent could not communicate with its authority.

All Communication Error General Offbox Error

agent_init_failed

The authentication agent failed to initialize.

All Initialization Error General Offbox Error

agent_no_groups_provided

The authentication agent did not receive the group list from the server.

All Invalid Configuration

agent_resource_not_protected

The authentication agent reports that the resource is not protected.

All Invalid Configuration

agent_too_many_retries

Agent configuration failed.

All Invalid Configuration

agent_unsupported_scheme

The requested authentication scheme is not supported.

All Invalid Configuration

authorization_username_too_long

The resolved authorization username is too long.

All Invalid User Information

basic_password_too_long

Basic password is too long.

All Invalid User Information

basic_username_too_long

Basic username is too long.

All Invalid User Information

253

Volume 4: Securing the Blue Coat SG Appliance

Table E-2. Individual Errors (Continued) Error Name

Description

Groups

cannot_decrypt_secret

Cannot decrypt shared secret.

All Invalid Configuration

cannot_determine_authorization_user name

Could not determine the authorization username.

All General Authorization Failure

cannot_determine_full_username

Could not determine full user name.

All Invalid Configuration General Offbox Error

cannot_determine_username

Agent could not determine simple user name.

All Invalid Configuration

cannot_expand_credentials_substituti on

The substitution used to determine the credentials could not be expanded.

All Invalid User Information

cannot_redirect_connect

Cannot use origin-redirect or form-redirect for CONNECT method (explicit proxy of https URL)

All Redirect Error

cannot_redirect_https_to_http

Cannot redirect an HTTPS request to an HTTP virtual URL

All Redirect Error

cannot_setup_working_dir

Unable to setup working directory for COREid AccessGate

All Invalid Configuration

cert_explicit_unsupported

Certificate authentication not supported for explicit proxy.

All Invalid Configuration

certificate_missing

No certificate found. Check that verify-client is set on https service.

All User Credentials Required

credential_decode_failure

Unable to decode base64 credentials.

All Invalid User Information

credentials_mismatch

Credentials did not match.

All Invalid User Information

domain_controller_query_disabled

Windows SSO Domain Controller Querying is not enabled on the Single Sign-on agent.

All Invalid Configuration

expired_credentials

Credentials on back-end server have expired.

All User Account Error

form_does_not_support_connect

Cannot use form authentication for CONNECT method (explicit proxy of https URL)

All Invalid Configuration

form_requires_basic_support

Form authentication requires the realm to support Basic credentials.

All Invalid Configuration

general_authentication_error

General authentication failure due to bad user ID or authentication token.

All General Authentication Failure Invalid User Information

general_authorization_error

Unable to authorize authenticated user.

All General Authorization Failure

guest_user

Credentials required.

All User Credentials Required

invalid_ip

The IP address of this computer could not be determined by the Single Sign-on agent.

All Single Sign-on Failure

254

Appendix E: Authentication and Authorization Errors

Table E-2. Individual Errors (Continued) Error Name

Description

Groups

invalid_license

The license for the configured realm does not exist or is invalid. A valid license must be installed.

All Invalid License

invalid_local_user_list

Invalid local user list.

All Invalid Configuration

invalid_realm

The specified realm is invalid.

All Invalid Configuration

invalid_search_credentials

The LDAP search credentials are invalid.

All Invalid Configuration

invalid_surrogate

The surrogate is invalid for the specified realm.

All Invalid User Information

issuer_too_long

Certificate's issuer string is too long.

All Invalid User Information

ldap_busy

LDAP: server busy.

All Communication Error General Offbox Error

ldap_filter_error

LDAP: filter error.

All Invalid Configuration

ldap_inappropriate_auth

LDAP: inappropriate authentication.

All Invalid Configuration

ldap_insufficient_access

LDAP: insufficient access.

All Invalid Configuration

ldap_invalid_credentials

LDAP: invalid credentials.

All Invalid User Information

ldap_invalid_dn_syntax

LDAP: invalid DN syntax.

All Invalid Configuration

ldap_loop_detect

LDAP: loop detected.

All Communication Error General Offbox Error

ldap_no_such_attribute

LDAP: No such attribute.

All Invalid Configuration

ldap_no_such_object

LDAP: no such object.

All Invalid Configuration

ldap_partial_results

LDAP server returned partial results.

All Invalid Configuration

ldap_server_down

Could not connect to LDAP server.

All Communication Error General Offbox Error

ldap_timelimit_exceeded

LDAP server exceeded time limit.

All Request Timeout General Offbox Error

ldap_timeout

The LDAP request timed out.

All Request Timeout General Offbox Error

ldap_unavailable

LDAP: service unavailable.

All Communication Error General Offbox Error

255

Volume 4: Securing the Blue Coat SG Appliance

Table E-2. Individual Errors (Continued) Error Name

Description

Groups

ldap_unwilling_to_perform

LDAP: server unwilling to perform requested action.

All Communication Error General Offbox Error

missing_base_dn

No base DNs are configured.

All Invalid Configuration

missing_form_configuration

Form authentication is not properly configured

All Invalid Configuration

multiple_users_matched

The user query resulted in multiple users. A unique user could not be determined.

All Single Sign-on Failure

need_credentials

Credentials are missing.

All User Credentials Required

netbios failure

NetBIOS reply did not contain data needed for authentication.

All Invalid NetBIOS Reply General Offbox Error

netbios_cannot_send

Could not send NetBIOS query.

All Communication Error General Offbox Error

netbios_multiple_users

NetBIOS reply contained multiple user names.

All Invalid NetBIOS Reply General Offbox Error

netbios_no_computer_name

Could not determine computer name from NetBIOS reply.

All Invalid NetBIOS Reply General Offbox Error

netbios_no_domain_name

Could not determine domain name from NetBIOS reply.

All Invalid NetBIOS Reply General Offbox Error

netbios_no_user_name

NetBIOS reply did not contain the user name.

All Invalid NetBIOS Reply General Offbox Error

netbios_recv_failed

Failed to receive reply to NetBIOS query.

All Invalid NetBIOS Reply General Offbox Error

netbios_reply_invalid

Reply to NetBIOS query was invalid.

All Communication Error General Offbox Error

netbios_reply_timeout

Timed out awaiting reply to NetBIOS query.

All Request Timeout General Offbox Error

no_offbox_url_specified

Off-box redirects are configured but no off-box URL is specified.

All Invalid Configuration

no_servers

No usable authentication servers found.

All Communication Error Invalid Configuration General Offbox Error

no_user_in_cert

Could not retrieve username from certificate.

All User Credentials Required

256

Appendix E: Authentication and Authorization Errors

Table E-2. Individual Errors (Continued) Error Name

Description

Groups

none

Status successful.

not_attempted

The method has not been attempted.

All

not_ssl

SSL is required but connection is not using it (check virtual-url).

All Invalid Configuration

offbox_abort

The request was aborted due to a change in configuration.

All Configuration Changed

offbox_missing_secret

Secret is not defined for authentication realm

All Invalid Configuration

offbox_process_create_failed

Could not create offbox authentication processes

All Initialization Error General Offbox Error

offbox_protocol_error

The authentication server returned an invalid result.

All Invalid Configuration General Offbox Error

offbox_server_down

The authentication server cannot process requests.

All General Offbox Error

offbox_server_unreachable

The authentication server could not be contacted.

All Invalid Configuration General Offbox Error

offbox_timeout

The request timed out while trying to authenticate. The authentication server may be busy or offline.

All Request Timeout General Offbox Error

otp_already_used

The one-time password has already been used

All Invalid User Information

password_too_long

Password is too long.

All Invalid User Information

radius_socket_interface

RADIUS received an unexpected socket error.

All Communication Error General Offbox Error

rdns_cannot_determine_name

Could not determine user name from client host name.

All RDNS Failure General Offbox Error

rdns_failed

Reverse DNS address resolution failed.

All RDNS Failure General Offbox Error

redirect_from_vh

Redirecting from the virtual host.

All Redirect Error

sspi_context_lost

Authentication agent rejected request (context lost).

All Invalid BCAAA Request General Offbox Error

sspi_context_too_old

Authentication agent rejected request - too old.

All Invalid BCAAA Request General Offbox Error

sspi_domain_controller_not_found

Cannot find domain controller.

All Invalid Configuration

sspi_invalid_handle

SSPI protocol error - invalid context handle.

All Invalid User Information

257

Volume 4: Securing the Blue Coat SG Appliance

Table E-2. Individual Errors (Continued) Error Name

Description

Groups

sspi_invalid_mechanism

Authentication agent rejected request - Invalid mechanism requested.

All Invalid BCAAA Request General Offbox Error

sspi_invalid_token

The credentials provided are invalid.

All Invalid User Information

sspi_invalid_type3_message

Client sent invalid NTLM Type 3 message.

All Invalid User Information

sspi_logon_denied

The logon failed.

All Invalid User Information

sspi_logon_type_not_granted

Requested logon type not granted.

All Invalid Configuration

sspi_no_authenticating_authority

No authority could be contacted for authentication.

All Communication Error General Offbox Error

sspi_null_lm_password

Windows NT password too complex for LanMan.

All Invalid Configuration

sspi_process_create_failed

NTLM realm could not create administrator processes.

All Initialization Error General Offbox Error

sspi_rpc_error

Connection to authentication agent lost.

All Communication Error General Offbox Error

sspi_service_disabled

SSPI service disabled.

All Invalid Configuration

sspi_timeout

Authentication agent did not respond to request in time.

All Request Timeout General Offbox Error

sspi_unable_to_connect_to_agent

Unable to connect to authentication agent.

All Communication Error General Offbox Error

subject_too_long

Certificate's subject string is too long.

All Invalid User Information

too_many_users

More than one user is logged onto this computer. Only one user can be logged on for Single Sign-on authentication.

All Single Sign-on Failure

unable_to_query_client

The client workstation could not be queried by the Single Sign-on agent.

All Single Sign-on Failure

unknown_user

The user could not be determined by the Single Sign-on agent.

All Single Sign-on Failure

user_domain_not_trusted

The specified domain is not trusted.

All Invalid User Information

username_too_long

Specified username is too long.

All Invalid User Information

258

Index

A

B

access control list creating 19, 27 restricting access with 19 access logs digital signing overview 66 access restrictions access control list for 19 configuring 19 Admin layer example 24 administrator defining policies 20 security levels 17 ADN realms, using with 141, 172, 190 Application Delivery Network (ADN) Novell SSO realms, using with 141, 172, 190 policy substitution realms, using with 141, 172, 190 realm authentication, configuring policy 141, 172, 190 reflect ip address attribute, using 141, 172, 190 Windows SSO realms, using with 141, 172, 190 authenticate.mode, IWA, realm setting for 34 authentication configuring transparent proxy authentication 35 definition of 11 guest 38 LDAP realm 109 permitted errors, understanding 37 policies 11, 15 setting options for transparent proxy authentication 35, 36 authentication realm typical configuration 12 authorization definition of 11 LDAP realm 109 policies 11, 15, 55 authorization refresh time, discussed 29

BCAAA COREid realm, using with 82 event log, viewing 221 event messages 225 installation folder, selecting 217 Service Principal Names, creating 223 services, viewing 221 SSL, using with pre-Windows 2003 222 SSL, using with Windows 2003 and higher 222 troubleshooting 225 WIDMS, configuring for 146 Blue Coat SG read-only and read-write access 17 restricting access to 19

C CA Certificates certificate signing request creating 59, 60 error message 61 lists creating through CLI 71 creating through Management Console 70 managing 60 troubleshooting 61 CAASNT, see BCAAA certificate realm authentication and authorization overview 73 configuring authentication and authorization 73 defining properties 74 defining realm server properties 74 how it works 73 LDAP authorization, adding 74 local authorization, adding 74 overview 73 policies, creating 77 requirements 73 Certificate Revocation Lists (CRLs) configuring 63 PEM encoded/DER format 63 using 62 certificate signing request creating 59

259

Volume 4: Securing the Blue Coat SG Appliance

Certificate Signing Request, viewing 60 certificates chaining, about 69 commands creating certificate 60 creating 61 CSA importing 69 explained 52 importing 68 importing existing 67 self-signed creating 62 troubleshooting 64 challenge type, explained 32 cipher suites interactive mode, using 234 International Step-Up, working with 54 non-interactive mode, using 235 Server Gated Cryptography, working with 54 SGOS, supported by 53 client map, see SSL client CONNECT method, using with origin-style redirection 35 console account minimum security 17 cookie surrogates, refresh time, discussed 30 COREid realm Access Server specifying 83 agents, configuring 82 Blue Coat appliance challenges, avoiding 81 configuring 80 configuration overview 79 CPL, creating 86 creating 82 forward proxy, using with 81 general settings configuring 84 general settings, specifying 84 SSO scheme, participating in 81 system, configuring 79 CPL Admin layer, example 24 certificate realm, policies, creating 77 IWA realm policies, creating 107 LDAP realm examples 119 local realm, creating policies 129

Netegrity SiteMinder policies, creating 153 Novell SSO policies, creating 172 policy substitution realm, policies, creating 140 RADIUS realm policies, creating 160 Windows SSO policies, creating 190 credential refresh time cached usernames, passwords 29 discussed 29 one-time passwords 29

D database creating through Blue Coat SG 126 local realm, setting up 123 viewing all users 127 default groups policy used with 40 understanding 39 DER-format URLs, CRLs, using with 63 digital signing, overview 66 document conventions 13

E error message, HTTPS Console 64 event messages, BCAAA 225 explicit proxy policy substitution realm, troubleshooting 179 external certificates, using with digital signing 66

F forms-based authentication realm CPL, using with 99 creating 96 creating, tips 94 creating/editing form 95 credentials sent in cleartext 100 customizing through Blue Coat SG 96 installing from local file 96 installing from remote URL 96 required values 91 storage options, setting 97, 98 substitutions for 93 tips/boundary conditions 100 understanding 90 front panel PIN clearing 15

260

Index

creating 15

G guest authentication policy substitutions used with 39 policy used with 39 understanding 38

H .htpasswd file creating password realm database 125 loading 125 uploading 125 hashed passwords, using 16 header policy substitution realm, using with 140 HTTP server XML realms, configuring for 194 HTTPS Console certificate error message 64 troubleshooting certificate problems 64 HTTPS termination certificates 52 configuring 55 keyring, creating 56

I Internet Explorer troubleshooting for explicit policy substitution realm 179 troubleshooting for transparent proxy 179 IP address surrogates, refresh time, discussed 30 IWA realm authenticate.mode, setting 34 configuring authentication and authorization 101 defining realm server properties 101 Kerberos, enabling 103 overview 101 policies, creating 107 Service Principal Names, creating 223 single sign-on, configuring 107

K Kerberos. See IWA keyring associating with certificate 68 importing 67 SSL client, associating 233

L LDAP policy-substitution realm, adding to 137 v2/v3 support 109 LDAP realm authentication and authorization overview 109 authorization 114 case-sensitive configuration 111 certificate realm, adding to 74 CPL examples 119 defining Base DNs 113 defining realm authorization properties and group information 114 defining realm server properties 110 defining server properties 111 group information 115 search boundaries 114 searching multiple base DNs 112 SSL, enabling 111 virtual URL, setting up 118 Lightweight Directory Access Protocol, see LDAP local realm authentication and authorization overview 121 certificate realm, adding to 74 changing properties 121 CPL, creating policies 129 creating a realm 121 database group, creating 126 database user, creating 126 database users, viewing 127 database, creating 123 database, creating through Blue Coat SG 126 database, populated 124 database, setting up 123 defining realm server properties 121 deleting groups 128 deleting users 128 groups, defined 124 groups, deleting 128 hashed passwords 124 policy substitution realm, adding to 137 user name, defined 124 users, deleting 128 view all lists 127 virtual URL, setting up 123 local user list security settings, changing 128

261

Volume 4: Securing the Blue Coat SG Appliance

N netbios using with policy substitution realm 139 Netegrity SiteMinder realm agents, configuring 146 case-sensitive configuration 147 creating 146 display name, changing 150 policies, creating 153 protected resource, entering 149 server mode, configuring 149 servers, configuring 147 servers, editing 148 SSO-only mode, enabling 149 Novell SSO realms ADN, using with 141, 172, 190 authorization, using 164 BCAAA, configuring 165 creating a realm through CLI 166 defining realm server properties 165 general properties, configuring 169 policies, creating 172 sso.ini file, modifying 171 Novell SSO realms, ADN using with 141, 172, 190 NTLM realm. See IWA realm

O one-time passwords XML realms, configuring 195 Oracle, See COREid origin-style authentication origin 32 origin-cookie 32 origin-cookie-redirect 32 origin-ip 32 origin-ip-redirect 32

P passwords hashed, encrypted 16 security, understanding 16 PEM-encoded URLs, CRLs, using with 63 permitted errors, authentication authentication failures 37 authorization failures 37 policy used with 37 policy for maximum security 18 for moderate security 17

policy substitution realm configuring 131 creating a realm through CLI 134 defining properties through Management Console 134 defining realm server properties through Management Console 134 full usernames, constructing 135 general properties, defining through CLI 139 general properties, defining through Management Console 138 header, using with 140 how it works 131 LDAP authorization, adding 137 local authorization, adding 137 netbios, using with 139 policies, creating 140 troubleshooting 179 user, username fields, explained 132 usernames, constructing 135 policy substitution realms ADN, using with 141, 172, 190 proxies setting up 11

R RADIUS realm authentication and authorization overview 155 case-sensitive usernames, setting 157 defining realm server properties 156 policies, creating 160 troubleshooting 162 read-only access in Blue Coat SG 17 read-write access in Blue Coat SG 17 realm sequence creating 176 promote/demote member realms 177 realms certificate 73 COREid 79 forms-based authentication 90 IWA 101 LDAP 109 local 121 RADIUS 155 sequence 176 understanding 11 requestor. See XML realms responder See XML realms

262

Index

S security console account 17 local user list settings, changing 128 policies for 17 sequence realm defining realm server properties 176 sequences, troubleshooting 175 serial port password, creating 16 Service Principal Names, creating for IWA realm 223 set_aut.pl script, using with .htpasswd file 125 setup console password, creating 16 SiteMinder, see Netegrity SiteMinder realm SOAP XML realms, using with 193 SSH password authentication 17 SSH with RSA authentication, not controlled by policy 20 SSL authentication/authorization services, using with 41 caching behavior, SSL client 233 cipher suites interactive mode, using 234 cipher suites non-interactive mode, using 235 LDAP realm, enabling 111 no-show keyring option 57 show keyring option 57 show-director option 57 timeout, configuring 237 SSL certificates, see certificates. SSL client keyring, associating 233 managing 233 sso.ini, modifying for Novell SSO realms 171 sso.ini, modifying for Windows SSO realm 188 surrogate credentials defined 32 refresh time, discussed 30

T timeout configuring for SSL termination 237 transparent proxy CLI commands 36 policy substitution realm, troubleshooting 179 transparent proxy authentication

configuring 35 setting options for 35, 36 troubleshooting BCAAA service 225 CA Certificates 61 CONNECT method 35 forms-based authentication realm 100 HTTPS Console 64 RADIUS realm 162 TCP_DENIED 33

U user data policy, refreshing through 30 refreshing 28 users administrator logout 28 credential refresh time, discussed 29 logged-in, viewing 26 logging in 26 logging out 27 logout conditions 28 logout properties 28 managing 26 policy logout 28 timeout 27 user data, refreshing 28

V virtual URL LDAP realm set up 118

W Windows configuring authorization 181 Windows SSO authorization, configuring 185 authorization, using 183 BCAAA, configuring 184 BCAAA, works with 182 creating a realm through CLI 185 defining general properties through CLI 188 defining realm server properties 183 defining realm server properties through Management Console 183 general properties, configuring 186 how it works 181 policies, creating 190 sso.ini file, modifying 188

263

Volume 4: Securing the Blue Coat SG Appliance

substitutions, available 186 Windows SSO realms ADN, using with 141, 172, 190

X XML realms authorization, configuring 197 creating 194 HTTP server, configuring 194 one-time passwords, configuring 195 requestor, understanding 193 responder service, configuring 195

responder, authentication/authorization,configuring 196 responder, creating 194 server, default values, changing 195 SOAP, using with 193 statistics, viewing 200 tasks before creating realm 194 understanding 193 user credential location, configuring 196 username parameters, configuring 196 XML realms, authorization, understanding 197

264

Blue Coat® Systems SG™ Appliance

Volume 5: Advanced Networking

Version SGOS 5.2.2

Volume 5: Advanced Networking

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02842 Document Revision: SGOS 5.2.2 09/2007

ii

Contents Contact Information

Chapter 1: About Advanced Networking About This Book ................................................................................................................................................11 Document Conventions....................................................................................................................................12 Chapter 2: Configuring an Application Delivery Network In this Chapter ...................................................................................................................................................14 Section A: About the Blue Coat Implementation for WAN Optimization ADN Components.............................................................................................................................................15 ADN Manager and Backup Manager .....................................................................................................15 ADN Nodes.................................................................................................................................................16 SG Client Manager .....................................................................................................................................16 Choosing the Right Deployment.....................................................................................................................16 Transparent Connections ..........................................................................................................................17 Explicit Connections ..................................................................................................................................18 Combination of Transparent/Explicit Connections .............................................................................18 Choosing Which Traffic to Optimize ......................................................................................................19 About ADN Compression................................................................................................................................19 ADN Security.....................................................................................................................................................19 Authenticating and Authorizing ADN Nodes ......................................................................................19 Securing ADN Connections......................................................................................................................20 Section B: Basic ADN Setup Defining the ADN Manager ............................................................................................................................21 Section C: Transparent and Explicit Connection Deployments Configuring a Transparent Deployment .......................................................................................................23 Transparent Deployment Notes...............................................................................................................23 Transparent Load Balancing.....................................................................................................................24 Configuring an Explicit Deployment .............................................................................................................26 Managing Server Subnets and Enabling an Internet Gateway ...........................................................26 Preserving the Destination Port ...............................................................................................................28 Explicit Load Balancing.............................................................................................................................28 Configuring a Combined (Transparent and Explicit) Deployment ...........................................................31 Section D: Securing the ADN Network Configuring ADN Security Settings ...............................................................................................................32 Setting Device Security..............................................................................................................................32 Securing Connections ................................................................................................................................34 Authorizing Devices to Join the Network ..............................................................................................36

iii

Volume 5: Advanced Networking

Approved/Pending Notes............................................................................................................................... 38 Section E: ADN Network History, Statistics, and Health Metrics Reviewing ADN History.................................................................................................................................. 39 Reviewing Byte-Caching Statistics ................................................................................................................. 39 Reviewing ADN Health Metrics..................................................................................................................... 40 Section F: Advanced Tunnel Optimization Setting Advanced Tunneling Parameters...................................................................................................... 42 Section G: Manually Re-Sizing a Byte-Cache Dictionary Section H: Related CLI Syntax to Configure an ADN Network Section I: Policy Chapter 3: Attack Detection Configuring Attack-Detection Mode for the Client ..................................................................................... 53 Changing Global Settings ......................................................................................................................... 53 Configuring Attack-Detection Mode for a Server or Server Group .......................................................... 57 Chapter 4: TCP Connection Forwarding About Asymmetric Routing Environments .................................................................................................. 59 The TCP Connection Forwarding Solution ................................................................................................... 60 About Bidirectional Asymmetric Routing ............................................................................................. 60 About Dynamic Load Balancing.............................................................................................................. 61 About ADN Transparent Tunnel Load Balancing ................................................................................ 61 TCP Configuration Forwarding Deployment Notes ............................................................................ 63 Configuring TCP Connection Forwarding.................................................................................................... 63 Copying Peers to Another SG Appliance in the Cluster...................................................................... 64 Removing a Peer ........................................................................................................................................ 65 Related CLI Syntax to Configure TCP Connection Forwarding......................................................... 65 Chapter 5: Bandwidth Management Bandwidth Management Overview............................................................................................................... 67 Allocating Bandwidth ............................................................................................................................... 68 Flow Classification..................................................................................................................................... 71 Configuring Bandwidth Allocation................................................................................................................ 71 Enabling Bandwidth Management ......................................................................................................... 72 Creating, Editing, and Deleting Bandwidth Classes ............................................................................ 72 Bandwidth Management Statistics ................................................................................................................. 74 Current Class Statistics Tab...................................................................................................................... 74 Total Class Statistics Tab........................................................................................................................... 75 Bandwidth Management Statistics in the CLI ....................................................................................... 76 Using Policy to Manage Bandwidth............................................................................................................... 77 CPL Support for Bandwidth Management ............................................................................................ 77 VPM Support for Bandwidth Management........................................................................................... 78 Bandwidth Allocation and VPM Examples ........................................................................................... 78

iv

Contents

Policy Examples: CPL................................................................................................................................ 85 Chapter 6: Authenticating an SG Appliance Introduction ....................................................................................................................................................... 87 SG Appliance Overview................................................................................................................................... 87 Appliance Certificates and Device Authentication Profiles ....................................................................... 88 About SG Appliance Certificates............................................................................................................. 88 About Device Authentication Profiles .................................................................................................... 88 Obtaining an SG Appliance Certificate.......................................................................................................... 89 Automatically Obtaining an Appliance Certificate .............................................................................. 90 Manually Obtaining an Appliance Certificate....................................................................................... 90 Obtaining a Non Blue Coat Appliance Certificate ....................................................................................... 93 Creating an Authentication Profile................................................................................................................. 93 Related CLI Syntax to Manage Device Authentication ............................................................................... 95 Chapter 7: Configuring Failover About Failover................................................................................................................................................... 97 Configuring Failover ........................................................................................................................................ 98 Viewing Failover Statistics............................................................................................................................... 99 Chapter 8: Configuring the Upstream Network Environment Section A: Overview Section B: About Forwarding About Load Balancing............................................................................................................................. 103 About Host Affinity................................................................................................................................. 103 Using Load Balancing with Host Affinity............................................................................................ 104 Section C: Configuring Forwarding Creating Forwarding Hosts and Groups.............................................................................................. 106 Configuring Global Forwarding Defaults ................................................................................................... 109 Configuring the Default Sequence ............................................................................................................... 110 Statistics ............................................................................................................................................................ 113 Section D: Using Forwarding Directives to Create an Installable List Creating Forwarding Host and Group Directives ..................................................................................... 114 Creating Forwarding Hosts.................................................................................................................... 115 Creating Forwarding Groups Using Directives .................................................................................. 116 Setting Special Parameters............................................................................................................................. 116 Setting Fail Open/Closed and Host Timeout Values......................................................................... 116 Configuring Load-Balancing Directives............................................................................................... 117 Configuring Host Affinity Directives ................................................................................................... 117 Creating a Default Sequence ......................................................................................................................... 118 Creating a Forwarding Installable List ........................................................................................................ 119

v

Volume 5: Advanced Networking

Chapter 9: Internet Caching Protocol (ICP) Configuration Configuring ICP .............................................................................................................................................. 121 Using ICP Configuration Directives to Create an Installable List .................................................... 121 Naming the IP Hosts ............................................................................................................................... 123 Restricting Access .................................................................................................................................... 123 Connecting to Other ICP Hosts ............................................................................................................. 124 Creating an ICP Installable List ............................................................................................................. 125 Enabling ICP ............................................................................................................................................. 126 Chapter 10: Using RIP Installing RIP Configuration Files ................................................................................................................ 127 Configuring Advertising Default Routes .................................................................................................... 128 RIP Commands................................................................................................................................................ 129 net............................................................................................................................................................... 129 host............................................................................................................................................................. 129 RIP Parameters ................................................................................................................................................ 130 SG-Specific RIP Parameters ........................................................................................................................... 131 Using Passwords with RIP ............................................................................................................................ 131 Chapter 11: Configuring the SG Appliance as a Session Monitor Configuring the Session Monitor.................................................................................................................. 133 Configuring the RADIUS Accounting Protocol Parameters ............................................................. 133 Configuring a Session Monitor Cluster ................................................................................................ 134 Configuring the Session Monitor .......................................................................................................... 135 Creating the CPL ............................................................................................................................................. 136 Notes .......................................................................................................................................................... 136 Chapter 12: Configuring and Using the SG Client Overview .......................................................................................................................................................... 140 About the Terminology........................................................................................................................... 140 SG Client Features and Benefits............................................................................................................. 141 About SG Client Deployment ................................................................................................................ 142 Software and Hardware Requirements ................................................................................................ 143 About ADN Features...................................................................................................................................... 143 General ADN Feature Support .............................................................................................................. 143 Configuring Listening Modes ................................................................................................................ 144 About Internet Gateways........................................................................................................................ 146 Configuring Client Settings ........................................................................................................................... 146 Configuring General Client Settings..................................................................................................... 146 Configuring Client CIFS Settings .......................................................................................................... 148 Configuring Client ADN Settings ......................................................................................................... 149 Configuring the Client Manager................................................................................................................... 151 Uploading the SG Client Software to the Client Manager................................................................. 153 Configuring the SG Client from the Command Line................................................................................. 155

vi

Contents

Configuring General Client Settings (Command Line)...................................................................... 155 Configuring Client CIFS Settings (Command Line) ........................................................................... 155 Configuring Client ADN Manager Settings (Command Line) ......................................................... 156 Configuring Client ADN Rules Settings (Command Line) ............................................................... 156 Setting the Client Manager (Command Line)...................................................................................... 157 Loading the Software (Command Line) ............................................................................................... 157 Making the SG Client Software Available to Users ................................................................................... 158 Setting Up Interactive Installations ....................................................................................................... 159 Setting Up Silent Installations and Uninstallations ............................................................................ 162 Using Group Policy Object Distribution .............................................................................................. 168 Using the SG Client......................................................................................................................................... 171 Troubleshooting Tips for Administrators ................................................................................................... 171 Files and Folders Used by the SG Client .............................................................................................. 171 SG Client Logging.................................................................................................................................... 172 About Browser Proxies ........................................................................................................................... 173 ADN Tunnels............................................................................................................................................ 173 Clearing the Object Cache ...................................................................................................................... 173 Client Manager Logging ......................................................................................................................... 174 Advanced Troubleshooting Suggestions.............................................................................................. 174 Licensing........................................................................................................................................................... 181 Chapter 13: SOCKS Gateway Configuration Section A: Configuring a SOCKS Gateway Configuring Global SOCKS Defaults ........................................................................................................... 187 Configuring the Default Sequence ............................................................................................................... 188 Statistics ............................................................................................................................................................ 191 Section B: Using SOCKS Gateways Directives with Installable Lists Configuring SOCKS Gateways Using Directives....................................................................................... 193 Creating SOCKS Gateways Groups Using Directives............................................................................... 194 Setting Special Parameters............................................................................................................................. 194 Setting Fail Open/Closed ...................................................................................................................... 194 Configuring Load Balancing Directives ............................................................................................... 194 Configuring Host Affinity Directives ................................................................................................... 195 Creating a Default Sequence ......................................................................................................................... 196 Creating a SOCKS Gateway Installable List ............................................................................................... 196 Chapter 14: Health Checks Section A: Overview Background DNS Resolution ........................................................................................................................ 201 Querying Health Checks................................................................................................................................ 201 Section B: About Blue Coat Health Components Health Check Types................................................................................................................................. 202 Health Check Tests .................................................................................................................................. 203

vii

Volume 5: Advanced Networking

Section C: Configuring Global Defaults About Health Check Defaults ....................................................................................................................... 207 Enabling and Disabling Health Checks................................................................................................ 207 Notifications and SNMP Traps .............................................................................................................. 208 Changing Health Check Default Settings.................................................................................................... 208 Configuring Health Check Notifications..................................................................................................... 211 Section D: Forwarding Host and SOCKS Gateways Health Checks Forwarding Hosts and SOCKS Gateways Configurations ....................................................................... 214 Forwarding Hosts Health Checks ......................................................................................................... 214 SOCKS Gateways Health Checks .......................................................................................................... 214 Forwarding and SOCKS Gateways Groups Health Checks.............................................................. 214 Configuring Forwarding and SOCKS Gateways Health Checks............................................................. 214 Editing Automatically Generated Tests for Forwarding and SOCKS Gateways ........................... 215 Section E: Editing External Services Section F: Managing User-Defined Health Checks About User-Defined Host Health Checks ................................................................................................... 221 About User-Defined Composite Health Checks ................................................................................. 222 Creating User-Defined Host and Composite Health Checks ................................................................... 223 Copying and Deleting User-Defined Health Checks................................................................................. 226 Section G: Statistics Section H: Using Policy Section I: Related CLI Syntax to Configure Health Checks Chapter 15: TCP/IP Configuration RFC-1323........................................................................................................................................................... 233 TCP NewReno ................................................................................................................................................. 234 ICMP Broadcast Echo Support...................................................................................................................... 234 ICMP Timestamp Echo Support ................................................................................................................... 234 TCP Window Size ........................................................................................................................................... 235 PMTU Discovery ............................................................................................................................................. 235 TCP Time Wait ................................................................................................................................................ 235 TCP Loss Recovery Mode .............................................................................................................................. 236 Viewing the TCP/IP Configuration ............................................................................................................. 236 Chapter 16: Virtual IP Addresses Chapter 17: WCCP Settings Overview .......................................................................................................................................................... 239 Using WCCP and Transparent Redirection ......................................................................................... 239 WCCP Version 2....................................................................................................................................... 239 Procedure Overview................................................................................................................................ 240 Creating an SG Appliance WCCP Configuration File............................................................................... 241 Understanding Packet Forwarding....................................................................................................... 242

viii

Contents

Understanding Cache Load Balancing ................................................................................................. 242 Creating a Configuration File................................................................................................................. 244 Notes ................................................................................................................................................................. 248 Appendix A: Glossary Appendix B: Using Policy to Manage Forwarding Appendix C: Using WCCP Overview .......................................................................................................................................................... 267 WCCP Version 1....................................................................................................................................... 267 WCCP Version 2....................................................................................................................................... 268 Quick Start........................................................................................................................................................ 269 Configuring a WCCP Version 2 Service on the Router ............................................................................. 270 Setting up a Service Group..................................................................................................................... 270 Configuring the Internet-Connected Interface .................................................................................... 273 Saving and Viewing Changes ................................................................................................................ 275 Examples .......................................................................................................................................................... 276 Displaying the Router’s Known Caches............................................................................................... 276 Standard HTTP Redirection .................................................................................................................. 276 Standard HTTP Redirection and a Multicast Address....................................................................... 277 Standard HTTP Redirection Using a Security Password .................................................................. 277 Standard Transparent FTP ..................................................................................................................... 278 Reverse Proxy Service Group................................................................................................................. 279 Service Group with Alternate Hashing ................................................................................................ 279 Troubleshooting: Home Router .................................................................................................................... 280 Identifying a Home Router/Router ID Mismatch .............................................................................. 281 Correcting a Home Router Mismatch................................................................................................... 283 Index

ix

Volume 5: Advanced Networking

x

Chapter 1: About Advanced Networking

Volume 5: Advanced Networking discusses networking tasks that are not required in every environment, such as: ❐

TCP/IP settings.

❐

WAN Optimization, which enables you to optimize environments with application delivery networks (ADNs).

❐

Forwarding, which allows you to define the hosts and groups of hosts to which client requests can be redirected.

❐

Health Checks, which reports on the health of upstream hosts.

About This Book This book is organized into the following chapters: ❐

Chapter 2: "Configuring an Application Delivery Network" on page 13

❐

Chapter 3: "Attack Detection" on page 53

❐

Chapter 4: "TCP Connection Forwarding" on page 59

❐

Chapter 5: "Bandwidth Management" on page 67

❐

Chapter 6: "Authenticating an SG Appliance" on page 87

❐

Chapter 7: "Configuring Failover" on page 97

❐

Chapter 8: "Configuring the Upstream Network Environment" on page 101

❐

Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 121

❐

Chapter 10: "Using RIP" on page 127

❐

Chapter 11: "Configuring the SG Appliance as a Session Monitor" on page 133

❐

Chapter 12: "Configuring and Using the SG Client" on page 139

❐

Chapter 13: "SOCKS Gateway Configuration" on page 183

❐

Chapter 14: "Health Checks" on page 199

❐

Chapter 15: "TCP/IP Configuration" on page 233

❐

Chapter 16: "Virtual IP Addresses" on page 237

❐

Chapter 17: "WCCP Settings" on page 239

❐

Appendix A: "Glossary" on page 249

❐

Appendix B: "Using Policy to Manage Forwarding" on page 263

11

Volume 5: Advanced Networking

Document Conventions The following table lists the typographical and Command Line Interface (CLI) syntax conventions used in this manual. Table 1-1. Document 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 Blue Coat 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.

12

Chapter 2: Configuring an Application Delivery Network

The Blue Coat implementation of an Application Delivery Network (ADN) requires two-sided deployments, with an SG appliance (a peer) at each end of the WAN link. It also features: ❐

Byte caching. The use of byte caching in an application delivery network reduces the amount of TCP traffic across a WAN by replacing large chunks of repeated data with small tokens representing that data. Working with patterns detected in the WAN traffic, the ADN pair of systems handling the traffic builds a byte cache dictionary of small tokens.

❐

Acceleration techniques. The use of bandwidth management, compression, protocol optimization, and object caching reduces WAN usage even more.

In such an environment, with only minimal configuration changes, between 30 percent and 90 percent of WAN usage can be eliminated, and WAN performance can be increased from 30 percent to 90 percent. Applications that benefit from ADN optimization include Windows file servers, Web share applications such as WebDAV, CRMs such as Siebel, e-mail, and FTP.

In addition, you can configure the ADN network to provide additional security to internal ADN routing connections and to ADN tunnel connections that carry optimized application data. In a fully secured ADN network, only authenticated and authorized devices are allowed to join the ADN network. All connections between ADN nodes and the ADN manager and connections among the ADN nodes are ensured of message authenticity and privacy protection.

13

Volume 5: Advanced Networking

In this Chapter The following topics are discussed in this chapter: ❐

Section A: "About the Blue Coat Implementation for WAN Optimization" on page 15.

❐

Section B: "Basic ADN Setup" on page 21.

❐

Section C: "Transparent and Explicit Connection Deployments" on page 23.

❐

Section D: "Securing the ADN Network" on page 32.

❐

Section E: "ADN Network History, Statistics, and Health Metrics" on page 39.

❐

Section F: "Advanced Tunnel Optimization" on page 42.

❐

Section G: "Manually Re-Sizing a Byte-Cache Dictionary" on page 45.

❐

Section H: "Related CLI Syntax to Configure an ADN Network" on page 48.

❐

Section I: "Policy" on page 50.

14

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization

Section A: About the Blue Coat Implementation for WAN Optimization This section provides conceptual information regarding various deployments that employ WAN optimization. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment. Blue Coat recommends that you review this section for a high-level overview of the Blue Coat ADN implementation. This section contains discussions on: ❐

“ADN Components” , below.

❐

“Choosing the Right Deployment” on page 16.

❐

“About ADN Compression” on page 19.

❐

“ADN Security” on page 19.

ADN Components The components of the Blue Coat ADN implementation are: ❐

ADN manager and backup ADN manager to provide routing information and control access to the ADN network.

❐

ADN nodes in both branch offices and data centers that can be authenticated (identity verified) and authorized (permitted to join the network).

❐

(Optional) An SG Client manager if you have mobile users or users in small branch offices, where it might not be cost-justifiable to deploy an acceleration gateway.

ADN Manager and Backup Manager The ADN manager keeps track of and advertises the routes of the appliances it knows about. The ADN manager must be one of the peers in the ADN optimization network. Note: Peer refers to any ADN system, manager refers to the ADN system that broadcasts route information to all ADN peers and controls peer access to the ADN network, and node refers to all non-manager ADN peers. ADN managers can also act as nodes on the network.

A backup ADN manager (optional, but recommended) can also be configured. The ADN managers and the registered nodes periodically send keep-alive messages to each other. If a node detects the primary ADN manager is not responding, the node automatically fails over to the back-up ADN manager. The node repeatedly attempts to restore its connection with the primary manager. After the primary ADN manager is responding to the node again, the active routing connection of this node switches back to the primary manager. If the ADN manager detects a node is not responding, the ADN manager removes the node from the database and notifies all other nodes in the network to do the same. If both the ADN manager and the backup ADN manager are unavailable, no further routing advertisements are broadcast. In this case, routes already known by the peers continue to be remembered and used.

15

Volume 5: Advanced Networking Section A: About the Blue Coat Implementation for WAN Optimization You also can use the ADN manager and backup manager to authorize which peers are allowed to advertise or retrieve route information to and from the ADN manager, and whether plain connection requests to the ADN manager are accepted. Connections to the ADN manager and backup manager are made at startup and kept open as long as ADN is enabled. These connections are referred to as routing connections, and are used to advertise configured server subnets and to receive routing table updates from the ADN manager. Note: Even if you use a transparent tunnel deployment where ADN nodes do not require routing information, you must configure each ADN node and register it with the ADN manager. If you secure the network (highly recommended), the ADN manager is used to authorize ADN peers before they join the network.

Whenever the ADN manager receives a new advertisement from a node that is joining the network, a route update is sent to all the appliances in the ADN optimization network that have already established a routing connection; in addition, the current routing table is updated. The ADN manager and backup manager can each listen on two ports: one accepting the default plain (unsecured) routing connection requests and another accepting secure routing connection requests. The plain listener can be shut down if routing connections from all ADN nodes are secured. To configure the ADN manager and backup ADN manager, see Section B: "Basic ADN Setup" on page 21.

ADN Nodes An ADN node is any SG appliance that is configured for ADN optimization and sends routing information to the ADN manager and backup ADN manager. A node excludes those appliances that are acting as ADN managers and backup ADN managers, although the manager and backup manager can also participate as nodes in the network.

SG Client Manager The SG Client typically connects to an SG appliance typically located in a data center. That SG appliance provides the SG Client software to users, and maintains the software and the client configuration on all clients in the ADN network. Only one SG Client Manager can be used in the ADN network. For information on using the SG Client and SG Manager, see Chapter 12: "Configuring and Using the SG Client" on page 139.

Choosing the Right Deployment You must decide if the network should use explicit tunnel connections, transparent connections, or a combination of both. Note that ADN peers always intercept incoming transparent connections if ADN is enabled. ❐

Transparent: The branch SG appliance connects to the original server destination address and port. If an upstream proxy is capable of transparent tunneling, the downstream proxy transfers data over the ADN tunnel. The destination port is preserved and is not affected by security being enabled. Skip to “Transparent Connections” for more information.

16

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization ❐

Explicit: The branch SG appliance connection is established to the ADN peer discovered from the routing lookup table. The connection is established to the tunnel listening port by default or, if you are preserving the destination port, to the port number the application specifies. Skip to “Explicit Connections” on page 18 for more information.

❐

Combination: In some circumstances, some ADN nodes can connect transparently, while other nodes require explicit routing. Skip to “Combination of Transparent/ Explicit Connections” on page 18.

Transparent Connections Transparent connections are used when the network is required to see the original destination IP addresses and ports. This requires that each node be configured as an ADN node and deployed in in-line mode or virtual in-line mode. Note: Beyond setting up an ADN node in an in-line network and configuring the ADN node to point to the ADN manager and backup manager, no additional effort is required for transparent connections. If you use explicit connections, those connections must be explicitly configured.

Transparent connections take advantage of ADN tunnels that maintain layer-4 information from the original application connections. Layer-4 information provides an administrator more granular control of the ADN network and allows the enforcement of network policy. In a transparent connection deployment, connections are not established to a particular peer in the ADN, as they are in an explicit deployment. An ADN node can establish connections to its peers automatically in the absence of any ADN routing information. The reject-inbound per interface setting is honored for transparent tunnel interception, while the allow-intercept setting is ignored for transparent tunnel interception. Internet-bound traffic is automatically accelerated in a transparent deployment if a transparent ADN peer is installed at the internet access point and Internet traffic is routed correctly.

Transparent Deployment Load Balancing Scenarios In transparent load balancing, routes are not advertised, and configuration of load balancing must be done on each node in the ADN cluster. If you are using a transparent deployment, you have two options for load balancing. ❐

A dedicated SG appliance as a load balancer; that system makes the decision about which node receives which traffic.

❐

A WCCP router or other external load balancer, where the individual nodes in the ADN cluster make the informed load balancing decision.

17

Volume 5: Advanced Networking Section A: About the Blue Coat Implementation for WAN Optimization

Explicit Connections Explicit connections are used when maximum network control and granularity is needed. Blue Coat supports two explicit connections deployments: explicit or explicit but preserving the destination port. In the latter case, the destination port used is the original destination port from the client’s request, such as port 80 for HTTP. The destination port is not affected by the connection setting. In both explicit deployments, the server subnets that are fronted by each peer must be explicitly configured; the server subnets are then advertised to each ADN node. To accelerate Internet traffic in an explicit ADN network, set up a specific ADN peer as the Internet gateway. Typically, the Internet gateway is an ADN peer close to the enterprise’s Internet access point.

Note:

If multiple Internet gateways are available, each peer has its own preferred Internet gateway to route all Internet subnets. When an ADN peer is configured as an Internet gateway, all other ADN peers forward the Internet traffic to this peer. The following logic is used by an ADN peer to determine if the connection is destined to the Internet: ❐

If the destination address matches an advertised subnet from any of the ADN peers, the connection is forwarded to that peer over the ADN tunnel.

❐

If the destination address matches one of the exempted subnets, the connection is not forwarded over the ADN tunnel.

❐

If the destination address does not match an advertised subnet or an exempted subnet, the connection is forwarded to an ADN peer that is designated as an Internet gateway.

Explicit Deployment Load Balancing Scenarios If you use explicit network connections, you have two options when configuring load balancing: ❐

A server subnet, where the branch SG appliance makes the decision about the node receiving specific traffic for a destination subnet. This is the easiest and more preferred method. For more information, see“Using a Server Subnet” on page 29.

❐

An external load balancer, where that system makes the informed decision about which node in the ADN cluster receives specific traffic. For more information, see “Using an External Load Balancer” on page 29.

Combination of Transparent/Explicit Connections In some circumstances, it necessary to use explicit connections in addition to the much easier and preferred transparent connection deployment. A transparent network that can advertise explicit routing connections is supported. This configuration is useful: ❐

When a small branch office is using the SG Client, which allows SGOS functionality when a SG appliance is not on site.

❐

If some nodes are not in an in-line configuration or are incapable of initiating transparent connections.

18

Chapter 2: Configuring an Application Delivery Network

Section A: About the Blue Coat Implementation for WAN Optimization By default, if an ADN node is advertising routes, explicit connections are made. If no explicit routes are found and there is an upstream proxy in the path capable of transparent tunneling, the connection is intercepted. This preference is configurable.

Choosing Which Traffic to Optimize When you configure proxy services to manage TCP traffic through the ADN network, you can set various attributes that can optimize the traffic for the network. A specific attribute, use ADN, allows you to disable ADN for a given service. For information on using proxy services, including the services available, refer to Volume 2: Proxies and Proxy Services.

About ADN Compression ADN compression enables organizations to fully extract every performance benefit available when sending data through an ADN tunnel between SG appliances. ADN tunnels require that SG appliances on opposite sides of the WAN be members of the same ADN network and that the upstream SG appliance either be advertising routes to servers to be accessed by appliances on the opposite side of the WAN or be deployed inline so that transparent ADN tunnels can be used. Traffic accelerated between clients and servers is automatically compressed before being sent through the ADN tunnel, decreasing bandwidth usage and optimizing response time. ADN compression is often used in conjunction with byte caching and object caching to achieve optimum results. In the case of byte caching and compression, byte caching is first applied to the data and then the resulting data is compressed. Both features are enabled by default to optimize ADN directed traffic. ADN compression for any arbitrary protocol can also be configured on the SG appliance using policy; it can also be controlled separately for both inbound and outbound traffic on the WAN. For more information on byte caching, see Section G: "Manually Re-Sizing a Byte-Cache Dictionary" on page 45.

ADN Security ADN networks can and should be secured. You can limit access by: ❐

Authenticating and authorizing the ADN nodes that are allowed on the network and prevent unauthorized nodes from participating.

❐

Securing ADN connections.

Authenticating and Authorizing ADN Nodes By default, authentication and authorization are disabled.

ADN Node Authentication Secure ADN requires an appliance certificate for each ADN peer, including the ADN manager and backup manager for identification. You can provide your own device appliance certificates or obtain Blue Coat-issued appliance certificates from the Blue Coat CA server. For the most secure environment, Blue Coat-issued appliance certificates are recommended. To enable secure ADN, you must enable the appliance authentication profile for the ADN network to use before configuring any other security parameters.

19

Volume 5: Advanced Networking Section A: About the Blue Coat Implementation for WAN Optimization In secure ADN mode, full mutual authentication can be supported between the ADN manager and the ADN nodes and among ADN communicating peers. If authorization is enabled on the ADN manager, the peer proxy is authorized through an approval mechanism by the ADN manager before joining the network. For more information on managing appliance certificates, see Chapter 6: "Authenticating an SG Appliance".

ADN Node Authorization Authorization occurs when the ADN manager gives approval for the device to join the network. If the profile, authentication, and authorization are configured on each peer, and the Pending Peers option is enabled on both the ADN manager and the backup ADN manager (if one is configured), the following behavior takes place automatically: ❐

When an ADN node comes up, it contacts the ADN manager for routing information.

❐

The ADN manager extracts the device ID from the connecting ADN node's appliance certificate and looks for the device ID in its approved list of ADN nodes. •

If the device is on the approved list, a REQUEST-APPROVED response is sent, followed by the route information, and the node joins the network.

•

If the device is not on the approved list, the ADN manager adds the connecting node's device ID to a pending-peers list and sends a REQUEST-PENDING response. After the peer is moved to the Approved list by the administrator, a REQUESTAPPROVED response is sent, followed by the route information, and the node joins the network.

•

If the Pending Peers option is not enabled and a peer is not on the approved list, the ADN manager sends a REQUEST-DENIED response and closes the connection. The connecting node closes the connection and updates its connection status.

•

If a peer is deleted from the approved list, the ADN manager broadcasts a REJECT-PEER to all nodes to delete this node and terminate any existing ADN

connections to it. No new connections are routed through the deleted ADN node. For information on configuring authentication and authorization on each ADN node, see “Configuring ADN Security Settings” on page 32.

Securing ADN Connections By default, ADN routing and tunnel connection requests are unauthenticated and all ADN protocol messaging and compressed application data are transferred in plaintext. For maximum security, you can configure the ADN network to secure ADN routing and tunnel connections using standard SSL protocol, which provides authentication, message privacy, and message authenticity security services, regardless of the application traffic that is being accelerated or tunneled. In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode to listen for routing and tunnel requests. When secure ADN is enabled, any existing plain outbound connections are dynamically secured by activating SSL according to the secure-outbound setting. For information on optimizing and securing ADN tunnels, see Section D: "Securing the ADN Network" on page 32 and Section F: "Advanced Tunnel Optimization" on page 42.

20

Chapter 2: Configuring an Application Delivery Network

Section B: Basic ADN Setup

Section B: Basic ADN Setup Basic ADN setup includes: ❐

Configuring each node in an in-line deployment; if you are configuring an explicit deployment, you do not need to configure the network in an in-line deployment.

❐

Plugging each node in.

❐

Enabling the ADN manager and backup manager on each node, starting with the ADN manager and backup manager themselves.

If you are using a transparent connection deployment without load balancing, ADN configuration is complete at this point. If you are using an explicit connection deployment, a transparent connection deployment with load balancing, or if you are securing the ADN network (highly recommended), after finishing this section you must continue with: ❐

“Explicit Load Balancing” on page 28, for explicit deployment.

❐

“Transparent Load Balancing” on page 24, for transparent deployment.

❐

Section D: "Securing the ADN Network" on page 32.

Defining the ADN Manager When an SG appliance connects to the primary ADN manager, subnet information is sent to the manager, including: ❐

Peer ID: The serial number of the device. This is a globally unique identifier for the peer SG appliance that is used as a key to select the dictionary of tokens to use.

❐

Data IP Address and Port: The destination IP address and port number that a branch proxy should use when establishing an explicit (non preserve-dest-port) tunnel connection.

❐

Server Subnet Advertisements: The list of server subnets the SG appliance contains are sent to the ADN manager.

The first step in configuring an ADN network is to define the primary ADN manager. Blue Coat also recommends deploying a backup ADN manager to prevent loss of routing information should the primary ADN manager become unavailable for any reason. The ADN manager and backup ADN manager must be configured on each peer that is joining the ADN network. To enable ADN optimization and define the primary/backup ADN managers: Note:

1.

Fill in all fields on this pane before clicking Apply.

Select Configuration > ADN > General.

21

Volume 5: Advanced Networking Section B: Basic ADN Setup

2 3

4

5 6

2.

Select Enable Application Delivery Network.

3.

Primary ADN Manager: Enter the IP address of the primary ADN manager. This can be

the SG appliance itself or any peer on the ADN optimization network. 4.

Backup ADN Manager (Optional but highly recommended): Enter the IP address of the backup ADN manager or select the Self radio button if this SG appliance is the backup manager.

5.

Manager Ports: The ports are set to 3034 (for plain routing connections) and port 3036

(for secure routing connections). 6.

Click Reconnect to Managers to connect to the ADN manager and backup ADN manager, if one is configured. Note:

You cannot select this option until you select the primary ADN manager and apply the changes. The ADN manager does not exist until the changes are applied. 7.

Click Apply to commit the changes to the SG appliance.

22

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments

Section C: Transparent and Explicit Connection Deployments If you are configuring a transparent connection deployment without load balancing, remember that ADN peers always intercept incoming transparent connections if ADN is enabled. No special configuration is required after basic ADN configuration is completed unless you use transparent connection load balancing or if you need to configure a combined (explicit and transparent) connection network. The basic steps for configuring a combined transparent/explicit deployment or a pure explicit deployment are: ❐

Connect the nodes in in-line mode or virtual in-line mode only for those nodes that are using transparent connections.

❐

(Optional) Secure the ADN network:

❐

•

Configure the ADN nodes for ADN authentication and authorization for maximum security (see “Configuring ADN Security Settings” on page 32). The settings on each system should be identical.

•

Configure secure tunnels (see Section F: "Advanced Tunnel Optimization" on page 42).

(Optional) Configure the load balancing parameters for each node to be used in load balancing (see “Explicit Load Balancing” on page 28 or “Transparent Load Balancing” on page 24).

To configure transparent connections, including transparent connection load balancing, continue with the next section. To configure explicit connections, including explicit connection load balancing, see “Configuring an Explicit Deployment” on page 26. To configure a combined connection deployment, skip to “Configuring a Combined (Transparent and Explicit) Deployment” on page 31.

Configuring a Transparent Deployment After you have completed basic ADN configuration, transparent connections are made automatically. No further configuration is required, unless you need to configure transparent load balancing.

Transparent Deployment Notes ❐

The first proxy in the chain that supports transparent tunnels and is on the same ADN network intercepts ADN transparent tunnel connections.

❐

In transparent load balancing, routes are not advertised, and configuration of load balancing must be done on each node in the ADN cluster.

❐

Transparent load balancing relies on connection forwarding clusters for proper operation. All nodes in an ADN load balancing group must be part of the same connection forwarding cluster.

❐

If connection forwarding is not set up correctly, load balancing will fail. For information on connection forwarding, see Chapter 4: "TCP Connection Forwarding" on page 59.

23

Volume 5: Advanced Networking Section C: Transparent and Explicit Connection Deployments

Transparent Load Balancing In transparent load balancing, routes are not advertised, and configuration of load balancing must be done on each node in the ADN cluster. If you are using a transparent deployment, you have two options for load balancing. ❐

A dedicated SG appliance as a load balancer; that system makes the informed decision about which node receives which traffic.

❐

A WCCP router or other external load balancer, where the individual nodes in the ADN cluster make the informed load balancing decision.

Using the Blue Coat Appliance as a Load Balancer When a Blue Coat appliance is used as the external load balancer, it makes the decisions about which traffic is directed to which node.

To configure transparent load balancing with a dedicated Blue Coat appliance as the decision maker: ❐

Deploy the load-balancing SG appliance in-line so that it can transparently intercept all traffic.

❐

Enable load balancing on all nodes by going to Configuration > ADN > Tunneling > Load Balancing, and selecting the Enable Load Balancing checkbox.

24

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments ❐

(Optional) Configure each box in the cluster with the same load-balancing group name.

❐

On the Blue Coat appliance that’s acting as the dedicated load balancer, select Act as load balancer only through the Configuration > ADN >Tunneling > Load Balancing tab.

❐

Put all ADN nodes into a connection forwarding cluster. For more information, see Chapter 4: "TCP Connection Forwarding" on page 59. Note: No special configuration is required for client IP spoofing beyond standard configuration, which is to enable reflect-client-ip on the branch SG appliance and to set the concentrator SG appliance to allow client-ip spoofing under ADN tunneling.

Using a WCCP Router or L4 Switch as a Load Balancer Using a WCCP router or L4 switch as a transparent load balancer is similar to using an SG appliance as a transparent load balancer, except that WCCP router or L4 switch must be configured on each system in the cluster. In this scenario, the router or switch cannot guarantee ADN peer affinity because the router cannot use the peer ID as input for its hash. Because of this, the ADN nodes make the actual informed routing decisions.

To configure transparent load balancing with the nodes in the ADN cluster as the decision makers:

25

Volume 5: Advanced Networking Section C: Transparent and Explicit Connection Deployments ❐

Enable load balancing on all nodes by going to Configuration > ADN > Tunneling > Load Balancing, and selecting the Enable Load Balancing checkbox.

❐

(Optional) Set the same group name on all of the nodes in the cluster.

❐

Put all ADN nodes into a forwarding connection cluster. For more information, see Chapter 4: "TCP Connection Forwarding" on page 59.

❐

Configure WCCP settings on all nodes. For more information, see Chapter 17: "WCCP Settings" on page 239.

❐

Configure WCCP router settings. Review the vendor’s documentation for information. Note: Note: If client IP spoofing is desired, you must configure WCCP so that both traffic from the Branch Appliance to the Origin Content Server and traffic from the Origin Content Server to the Branch Appliance is redirected through WCCP. This requires configuring WCCP on multiple interfaces on your router, or configuring "in/ out" rules. If specific ports are desired (rather than all ports), you must configure both source-port and destination-port rules in two different service groups.

Configuring an Explicit Deployment Complete the following steps to configure an explicit deployment: ❐

Configure server subnets on each peer and enable an Internet gateway (see “Managing Server Subnets and Enabling an Internet Gateway” ).

❐

(Optional) Preserve the destination port (see “Preserving the Destination Port” on page 28).

❐

Configure explicit load balancing (see “Explicit Load Balancing” on page 28)

Managing Server Subnets and Enabling an Internet Gateway The server subnets you create here are advertised by this peer upon joining the explicit ADN network. You can also enable the peer as an Internet gateway. In addition, subnets not intended to go over ADN tunnels or to be routed to Internet gateways can be configured as exempt subnets. Note:

You can also configure the exempt subnet capability through policy that allows you to disable ADN tunnel for specific connections. For more information, refer to Volume 10: Content Policy Language Guide. To create server subnets for this peer: 1.

Select Configuration > ADN > Routing > Server Subnets.

26

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments

Added Server Subnet

3

2

2.

Click Add.

3.

In the Add IP/Subnet dialog, enter the following information and click OK when you are done: •

IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet in Classless Inter-Domain Routing (CIDR) notation (for example, 192.168.0.1/16).

•

Subnet Mask field: Use this field if you entered only an IP address in the preceding

field (in other words, if you used CIDR notation in the preceding field, you do not need to enter a value in this field). •

To remove excluded subnets, click the subnets to remove and click Remove. You must confirm the action.

•

To clear all excluded subnets, requiring traffic from all IP addresses and subnets to be tunneled, click Clear all. You must confirm the action.

4.

(Optional) Repeat for additional routes.

5.

Click Apply to commit the changes to the SG appliance.

To enable this peer as an Internet gateway: 1.

Select Configuration > ADN > Routing > Internet Gateway.

27

Volume 5: Advanced Networking Section C: Transparent and Explicit Connection Deployments

2

3

2.

Select the Enable this SG as an Internet Gateway for all subnets except the following checkbox.

3.

Click Add.

4.

Add the IP/Subnet that must not be routed to Internet gateway(s); click OK.

5.

(Optional) Repeat for additional subnets.

6.

Click Apply to commit the changes to the SG appliance.

Preserving the Destination Port Complete the following procedure. To preserve the destination port: 1.

Select Configuration > ADN > Tunneling > Connection.

2.

Select the checkbox for When a route is available, preserve the destination TCP port number when connecting to the ADN peer.

Explicit Load Balancing Of the two explicit load balancing types, server subnet or external load balancer, the server subnet is the preferred and easiest to use. While the server subnets must be configured, no additional load balancing settings must be made, and the ADN nodes explicitly advertise their own IP addresses.

28

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments

Using a Server Subnet If you use an explicit deployment, or if you just want to load balance traffic destined to a specific subnet, configure the subnet as a server subnet on each ADN node within that group. To forward the connection destined to the load balanced subnet, each ADN node selects the preferred node from the list of all peers fronting that subnet. This is done by ranking the list of all nodes fronting a given subnet from highest to lowest. The node with the highest rank is chosen to route the client traffic for that subnet.

Using an External Load Balancer If you use explicit deployments, you can rely upon an external load-balancer fronting a group of ADN nodes. The load balancer is configured to distribute the load among the nodes that it fronts using client/IP address affinity. The external load balancer provides more control than the server subnet, but it requires more configuration. For example, you must create an external VIP address on the Configuration > ADN > Tunneling > Load Balancing tab on each system in the ADN cluster; the VIP address is explicitly advertised by the ADN manager. Both server subnet and external load balancer use a cluster of ADN nodes for load balancing. The cluster is formed by ADN nodes that are configured to the same ADN manager and are advertising the same server subnets.

29

Volume 5: Advanced Networking Section C: Transparent and Explicit Connection Deployments

Whether you are using server subnets or an external load balancer, you must configure server subnets. If you are using an external load balancer, you must also configure the external load balancer with a VIP address and put the address in the Load Balancing tab. Continue with the next procedures to configure explicit load balancing.

Explicit Load Balancing Procedures If you want to use either the server subnet load balancing deployment or the external load balancing deployment, you must configure server subnets. If you are using the external load balancing deployment, you must also configure the external load balancer with a VIP address. To configure server subnets: 1.

Go to Select Configuration > ADN > Routing.

2.

Click Add.

3.

Add the IP/Subnet route to be advertised by the ADN manager; click OK.

4.

(Optional) Repeat for additional routes.

For detailed information about configuring server subnets, see “Managing Server Subnets and Enabling an Internet Gateway” on page 26.

30

Chapter 2: Configuring an Application Delivery Network

Section C: Transparent and Explicit Connection Deployments To configure VIP addresses: 1.

Select Configuration > ADN > Tunneling > Load Balancing.

2.

Enter the VIP address of the external load balancer. Note:

The VIP address is added from the Load Balancing tab of the App Delivery Network menu, not the Advanced tab of the Network menu. 3.

Click Apply to commit the changes to the SG appliance.

The address must be entered on each ADN node in the cluster.

Configuring a Combined (Transparent and Explicit) Deployment If you set up a transparent ADN network with no explicit connections, no additional configuration is required for transparent tunnel connections to work unless you want to configure load balancing. To configure transparent load balancing, skip to “Setting Device Security” on page 32. If you set up a combined ADN network with both explicit and transparent connections, you must: ❐

Configure the explicit routes you need (see “Managing Server Subnets and Enabling an Internet Gateway” on page 26).

❐

Configure the routing preference for each ADN node to tell ADN peers to prefer transparent connections (see “To configure the routing preference:” ). The default is to always use advertised, explicit, routes.

❐

Set the manager listening mode to Plain read-only mode if SG Clients are in the network (see “To configure ADN manager and tunnel listening mode and ports:” on page 35.

❐

Configure transparent or explicit load balancing, if necessary. For more information, see “Transparent Load Balancing” on page 24 or “Explicit Load Balancing” on page 28.

To configure the routing preference: 1.

Select Configuration > ADN > Routing > Advanced.

2.

Select the Tell ADN peers to prefer transparent connections over advertised routes radio button.

31

Volume 5: Advanced Networking Section D: Securing the ADN Network

Section D: Securing the ADN Network Depending on your environment, you might need to secure your ADN network to provide the following services: ❐

Host validation: Securing the ADN network allows you to be sure that the ADN peers are talking to the right devices and that the peer is authorized to join the ADN network.

❐

Privacy: Privacy can be an issue, especially for tunnels that carry application data. You can configure the ADN network to secure ADN routing and tunnel connections using standard SSL protocol. SSL tunnels provide authentication, message privacy, and message authenticity security services, regardless of the application traffic that is being accelerated or tunneled.

❐

Message authenticity: Ensure that messages sent over ADN connections are not altered. Messages include the route information sent over the routing connections and compressed application data sent over the tunnel connections.

Secure ADN implementation includes: ❐

Device authentication, managed through the device authentication profile.

❐

Securing the device, including device authentication profile selection and device IDbased peer authorization.

❐

Securing the connections, both inbound and outbound connection security control.

❐

Configuring the SSL proxy. Note: If you only want secure routing connections to the ADN manager, an SSL license is not required. Secure tunnel connections for applications such as CIFS, MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL license.

Configuring ADN Security Settings For information on setting device security, continue with the next section. For information on setting connection security, continue with “Securing Connections” on page 34.

Setting Device Security For maximum security, configure the ADN network for both device authentication and device authorization. Device authentication must be configured first. Note: If the device being configured for authentication has Internet access, acquisition of the SG appliance certificate is automatic. If you use your own appliance certificates and profile, or if the affected device does not have Internet access, manual device authentication is required.

For information on configuring device authentication, see Chapter 6: "Authenticating an SG Appliance" on page 87.

32

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network After the device authentication has been set up, point the ADN manager and ADN backup manager to the profile that is being used for authentication. Then enable authorization for maximum security. Note: You cannot enable device authorization before configuring the ADN manager and backup ADN manager. You can, however, configure the ADN manager and backup ADN manager and then, without pressing Apply, enable device authorization. Then press Apply to save both tabs.

To set device security: 1.

Select Configuration > ADN > General > Device Security.

2a 2b 2c

2c

2.

Configure the Device Security settings: a.

Device Authentication Profile: From the drop-down list, select the profile that you previously associated with the device authentication keyring. Note that only devices using the same profile are authenticated.

b.

Extracted Device ID: The device ID that was extracted based on the selected profile is automatically displayed. Note:

c.

The device ID is only used for security. The peer ID is the serial number.

To enable authorization, select the Validate ADN Peer Device IDs checkbox. •

If the primary or backup ADN manager is Self, the device ID is automatically displayed.

•

If the primary or backup ADN manager is a different system, click the Retrieve Manager IDs button to see the device ID. Click Accept to add the Manager device ID to the Authorization field.

Note: Authorization of devices is not complete until the devices have been approved to be part of the network. For more information on approving devices, see “ADN Node Authorization” on page 20.

33

Volume 5: Advanced Networking Section D: Securing the ADN Network 3.

Click Apply to commit the changes to the SG appliance.

Securing Connections Use the Connection Security tab to set: ❐

Manager and Tunnel Listening Mode.

❐

Secure Outbound Connections.

Listening Mode Options In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode to listen for routing and tunnel requests. By default, ADN routing and tunnel connection requests are unauthenticated and all ADN protocol messaging and compressed application data are transferred in plain text. You must enable the device authentication profile before setting any other security parameters. After the profile is configured, the following security modes are automatically set: ❐

Secure-outbound: (Secure Proxies) Both outbound routing and secure proxy

connections are secured. You can also select the radio button to: •

Not secure ADN connections.

•

Secure only ADN routing connections.

•

Secure all ADN and routing connections.

Note: ❐

❐

The secure-outbound feature is dependent upon an SSL license.

Manager-listening-mode: (Both) Listen for requests on two ports: plain and secure. If your deployment requires a different ADN manager listening mode, you must explicitly configure it. Other options available are:

•

Secure Only.

•

Plain Only.

•

Plain Read-Only. This mode is recommended if your network uses SG clients.

Tunnel-listening-mode: (Both) Listen for requests on two ports: plain and secure. Other

options are: •

Secure Only (Note that tunnel listening mode cannot be set to secure-only if SG Clients exist on the ADN network).

•

Plain Only.

Secure Outbound Connections When secure ADN is enabled, any existing plain outbound connections are dynamically secured by activating SSL according to the secure-outbound setting. Determine which outbound ADN connections are secured by changing the secure-outbound parameter. If you select: ❐

None: Neither routing nor tunnel connections are secured. Secure proxy connections

bypass ADN connections and go directly to the origin content sever.

34

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network ❐

Routing-only: Only routing connections are secured. Secure proxy connections bypass

ADN connections and go directly to the origin content sever. ❐

Secure Proxies: Routing connections and secure proxy connections are secured.

❐

ALL: All outbound connections are secured. Note:

Securing all outbound ADN connections should be done only if the platform has sufficient capacity to handle the extra overhead. The table below describes secure outbound behavior with various applications. Table 2-1. Secure Outbound Behavior Application Connections Secure-Outbound Setting

Routing Connections

CIFS

SSL Proxy Intercept Mode

SSL Proxy Tunnel Mode

None

Plain Text

Plain Text

Bypass ADN

Bypass ADN

Routing-only

Encrypted

Plain Text

Bypass ADN

Bypass ADN

Secure Proxies

Encrypted

Plain Text

Encrypted

Encrypted by application

All

Encrypted

Encrypted

Encrypted

Encrypted by application

To configure ADN manager and tunnel listening mode and ports: 1.

Select Configuration > ADN > General > Connection Security.

2 3

4

2.

To configure manager listening mode and ports: •

To change the manager listening mode, go to Configuration > ADN > General > Connection Security. The default is Plain-only before the device authentication profile is selected. After the device authentication profile is selected, the manager listening mode switches to Both by default.

•

To change the manager listening ports, go to Configuration > ADN > General > General. The default is plain port 3034 and secure port 3036.

35

Volume 5: Advanced Networking Section D: Securing the ADN Network 3.

To configure tunnel listening mode and ports: •

To change the tunnel listening mode, go to Configuration > ADN > General > Connection Security. The default is Plain-only before the device authentication profile is selected. After the device authentication profile is selected, the manager listening mode switches to Both by default.

•

To change tunnel listening ports, go to Configuration > ADN > Tunneling > Connection. The default is plain port 3035 and secure port 3037. The tunnel listening port is used only if there are explicit tunnel connections to this ADN node using the non-preserve-dest-port mode.

4.

Click Apply to commit the changes to the SG appliance.

Authorizing Devices to Join the Network After a node is configured for authentication (device security) and peer validation is enabled on the ADN manager, the node must be accepted by the ADN manager and the backup ADN manager, if configured, before the device is allowed to join the network (authorization). ❐

When an ADN node comes up, it contacts the ADN manager for routing information.

❐

If secure-outbound is None on the ADN node and the ADN manager's listening mode is not secure-only, the ADN node connects to the plain manager listening port and immediately joins the ADN network.

❐

If the ADN node connects to the secure manager listening port, the ADN manager extracts the device ID from connecting ADN node's appliance certificate and looks for the device ID in its approved list of ADN nodes. •

If the device is on the approved list, a REQUEST-APPROVED response is sent, followed by the route information, and the node joins the network.

•

If the device is not on the approved list, the ADN manager adds the connecting node's device ID to the pending-peers list and sends a REQUEST-PENDING response. After the peer is moved to the Approved list by the administrator, a REQUEST-APPROVED response is sent, followed by the route information, and the node joins the network.

•

If the Pending Peers option is not enabled and a peer is not on the approved list, the ADN manager sends a REQUEST-DENIED response and closes the connection. The connecting node closes the connection and updates its connection status.

•

If a peer is deleted from the approved list, the ADN manager broadcasts a REJECT-PEER to all nodes to delete this node and terminate any existing ADN

connections to it. No new connections are routed through the deleted ADN node. To have the denied peer rejoin the ADN network, go to ADN > Config > General > Reconnect to Managers. To approve a device to join the network: Note: Device security must be enabled on all ADN peers you want to join the network before you complete this procedure on the ADN manager and backup ADN manager. For more information, see “Setting Device Security” on page 32.

36

Chapter 2: Configuring an Application Delivery Network

Section D: Securing the ADN Network 1.

Go to Configuration > ADN > Manager > Approved Peers.

2.

To manage peers that you want to be approved to join the network or that have previously been approved to join the network:

3.

•

Add peers to the list by selecting Add; a dialog box displays that allows you to enter one or a group of peers by listing one to a line. Click OK when through. If the device contacts the ADN manager and is on the approved list, a REQUESTAPPROVED response is sent, followed by the route information, and the node joins the network.

•

Remove peers by highlighting the peer or peers and selecting Remove. If a peer is deleted from the approved list, the ADN manager broadcasts a REJECT-PEER to all nodes to delete this node and terminate any existing ADN connections to it. No new connections are routed through the deleted ADN node.

Click Apply to commit the changes to the SG appliance.

To manage devices not yet approved to join the network: If a peer is configured to contact the ADN manager on startup but has not been added to the approved list, the ADN manager adds the peer to the list of pending peers if the Allow Pending Peers checkbox is selected. The peer moves from the Pending Peers list to the Approved Peers list only through human action. 1.

Go to Configuration > ADN > Manager > Pending Peers.

37

Volume 5: Advanced Networking Section D: Securing the ADN Network 2.

Select the Allow Pending Peers checkbox.

3.

To manage pending peers:

4.

•

Highlight a peer and click Accept or Reject; alternatively, you can select or reject all peers in the list by clicking Accept All or Reject All. If accepted, the peer moves to the Approved list; if not, it is dropped from the Pending Peers list.

•

You can also leave peers in the pending list by not selecting them or selecting them and clicking Leave Pending.

Click Apply to commit the changes to the SG appliance.

Approved/Pending Notes ❐

Approved lists on the primary and backup ADN managers are not automatically kept in sync. You must approve peers on both the primary and backup ADN managers.

38

Chapter 2: Configuring an Application Delivery Network

Section E: ADN Network History, Statistics, and Health Metrics

Section E: ADN Network History, Statistics, and Health Metrics After ADN optimization has been enabled and is processing, you can review byte caching history and various byte caching statistics.

Reviewing ADN History Review the Traffic Mix and Traffic History tabs in Statistics to be sure that ADN is working. For more information on Traffic Mix and Traffic History, refer to the statistics information in Volume 9: Managing the Blue Coat SG Appliance. To review ADN history, select Statistics > ADN History. Blue is traffic on the WAN link/ ADN tunnel

Green is the traffic delivered/ received on the local network

Inbound Compression Gain represents traffic received from another peer. Outbound Compression Gain represents the traffic sent to other peers.

The values include both compression and byte-cache gain.

Reviewing Byte-Caching Statistics To review byte caching statistics, select Statistics > Advanced and select the ADN link from the list. Per connection real time statistics are provided. Each connection has the following details: ❐

Client IP address/port.

❐

Server IP address/port.

❐

Bytes received from the application: The total bytes received from the client/server/ application proxy.

39

Volume 5: Advanced Networking Section E: ADN Network History, Statistics, and Health Metrics ❐

Bytes sent to the application: The total bytes sent to the client/server/application proxy.

❐

Bytes received from the peer SG appliance: The bytes received on the ADN tunnel connection from the peer at the other end of the WAN link. (This is compressed unless byte caching is disabled).

❐

Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel connection to the peer at the other end of the WAN Link. (This is compressed unless byte caching is disabled).

❐

Duration: The lifetime of this connection.

Reviewing ADN Health Metrics You can see the state of the ADN network, specifically the ADN node, by checking the Statistics > Health > General tab. The status can have the values as shown in the following table. The information is meant for diagnostic and debugging purposes.

40

Chapter 2: Configuring an Application Delivery Network

Section E: ADN Network History, Statistics, and Health Metrics Table 2-2. Connectivity to ADN Routing Manager Health Metric Status

Message

Description

State

ADN Health Status

Connected

The ADN node is connected to the ADN manager, ready to receive any route/peer updates.

OK

If a backup manager exists, this state indicates the node is connected to both Managers. Functionality Disabled

ADN functionality is not enabled.

OK

Not operational

ADN functionality is not operational yet — components are starting up or shutting down.

OK

Connection Approved

The ADN node has been approved to connect to the ADN manager.

OK

Connecting

The ADN node is in process of connecting to ADN manager.

OK

Partially Connected

The ADN node is connected to one ADN manager but not the other.

Warning

Mismatching Approval Status

The ADN node is approved by the current active ADN manager but is rejected by the backup manager. This warning only exists if a backup ADN manager is configured.

Warning

Approval Pending

The ADN node is awaiting a decision from the active ADN manager for the node’s request to join the ADN network.

Warning

Disconnected

The ADN node is not connected to the ADN manager and cannot receive route/ peer information.

Critical

If a backup manager is configured, this state indicates the node is disconnected from both manager nodes.

ADN Manager Status

Connection Denied

The ADN node is rejected by the ADN managers in the node's request to join the ADN network.

Critical

Not an ADN manager

The ADN node is not an ADN manager.

OK

No Approvals Pending

All ADN nodes that are requesting to join the network are already on the approved list.

OK

Approvals Pending

ADN nodes are requesting to join the network. The approvals are made by the administrator.

Warning

41

Volume 5: Advanced Networking Section F: Advanced Tunnel Optimization

Section F: Advanced Tunnel Optimization Tunnel connections are between the branch and concentrator proxies and are made on demand. To reduce connection startup latency, tunnel connections are pooled and reused. If a route is present, proxies that support ADN optimization use an ADN tunnel connection. Data traveling over the tunnel connection is subject to byte caching, compression, and encryption, per the defined policies. The tunnel connection occurs independently of the ADN optimization options chosen for that connection. These options can be configured for specific services and can also be modified in policy. Note:

Encryption options cannot be set through policy.

Optimization options include byte caching and gzip compression; byte caching and gzip compression can be controlled separately for inbound and outbound traffic on the WAN. By default, ADN routing and tunnel connection requests are unauthenticated and all ADN protocol messaging and compressed application data are transferred in plaintext. For maximum security, you can configure the ADN network to secure ADN routing and tunnel connections using standard SSL protocol, which provides authentication, message privacy, and message authenticity security services, regardless of the application traffic that is being accelerated or tunneled. For information on securing the network, see Section D: "Securing the ADN Network" on page 32.

Setting Advanced Tunneling Parameters The tunneling parameters you set determine the behavior when you have special environmental needs where the default parameters are not adequate. These parameters generally do not need to be changed. Parameters that can be changed include: ❐

Connection Settings (see “To configure ADN manager and tunnel listening mode and ports:” on page 35).

❐

Network Settings (see “To configure network tunneling settings:” ).

❐

Load Balancing Settings (see “Transparent Load Balancing” on page 24 and “Explicit Load Balancing” on page 28).

❐

Proxy Processing Settings (see “To change parameters for proxy processing:” on page 43).

To configure network tunneling settings: 1.

Select Configuration > ADN > Tunneling > Network.

42

Chapter 2: Configuring an Application Delivery Network

Section F: Advanced Tunnel Optimization

2.

Determine the behavior of the concentrator proxy when a branch proxy requests client IP reflection (sending the client's IP address instead of the SG appliance IP address to the upstream server). This setting is based on whether the concentrator was installed in-line. If the concentrator proxy is in-line and can do IP reflection, you can allow client IP address reflection requests from clients. If not, set this option to either Reject the Request or Allow the request but connect using a local IP to accept the requests but ignore the client IP address and use a local IP address.

3.

In the TCP Settings panel, enter the TCP window size to be used on ADN optimization tunnel connections. This setting only needs to be changed for high bandwidth and high delay environments, such as satellite links. The range is between 8 KB and 4 MB (8192 to 4194304), depending on your bandwidth and the round-trip delay. Note: If you know the bandwidth and roundtrip delay, you can compute the value to use as, roughly, 2 * bandwidth * delay. For example, if the bandwidth of the link is 8 Mbits/sec and the round-trip delay is 0.75 seconds: window = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes

The setting in this example would be 1500000 bytes. This number goes up as either bandwidth or delay increases, and goes down as they decrease. You can increase the window size based on this calculation but do not decrease the window size if the result is less than 64K. The window-size setting is a maximum value; the normal TCP/IP behaviors adjust downward as necessary. Setting the window size to a lower value might result in an artificially low throughput. 4.

Click Apply to commit the changes to the SG appliance.

To change parameters for proxy processing: 1.

Select Configuration > ADN > Tunneling > Proxy Processing.

43

Volume 5: Advanced Networking Section F: Advanced Tunnel Optimization 2.

(Optional) If the concentrator is required to perform HTTP proxy processing on requests arriving over an ADN tunnel, select HTTP. For most deployments, this is not needed. All proxy processing always happens at the branch proxy; generally speaking, the concentrator proxy just compresses and decompresses bytes and forwards them to and from the server. If this setting is enabled, proxy processing happens at both the branch and concentrator. Note: If you enable this setting, do not duplicate any of the policy that exists at the branch, since the branch settings still apply. Depending on the policy involved, doing the processing twice can cause problems (such as doing URL rewrite multiple times) or it might just be unnecessary, taking up valuable resources.

3.

Click Apply to commit the changes to the SG appliance.

44

Chapter 2: Configuring an Application Delivery Network

Section G: Manually Re-Sizing a Byte-Cache Dictionary

Section G: Manually Re-Sizing a Byte-Cache Dictionary The size of a byte-cache dictionary is dynamically based on the amount of traffic between two peers. Generally, the dynamic settings are acceptable; you do not need to change the dictionary size. Only if you determine that the algorithm performance does not guarantee a sufficient dictionary size for a specific peer should you manually set the dictionary size. The byte cache itself, consisting of all data seen on the network, is stored on disk. However, byte caching stores index data in RAM. You cannot change the amount of memory allocated for a peer, but you can manually set the amount of disk space to be set aside. The amount of memory set aside is based on the disk space. A table of peer rankings and dictionary sizes is created and maintained by the SG appliance. Peers are allocated dictionary space in order starting with the highest ranking peer in the table until each peer has been allocated resources, or maximum available amount of byte cache memory is reached.

Note:

The rank table can track peers that are using SGOS 5.1.3, but these peers cannot dynamically re-size or delete their dictionary. After the maximum available resources are reached, any peers that have not been allocated a dictionary cannot use byte caching. If those peers have existing dictionaries, the tunnels are downgraded to gzip compression only and the existing dictionary is deleted. A node can re-negotiate a new shared dictionary size with one of its peers, and the dictionaries grow or shrink to their new resource levels. The final shared dictionary sizes between two peers is the minimum dictionary size that each peer tries to negotiate. To guarantee a minimum dictionary size, the value should be set on both peers. (See “To manually resize byte cache dictionaries from the Statistics tab:” on page 46.) When a peer joins the network, it is added to the peer ranking table. How much dictionary space the peer is allocated depends: ❐

If the maximum amount of resources have already been reached, the new peer can do gzip compression only.

❐

If the maximum amount of resources have not been reached: •

If no history exists for this peer, then the peer negotiates a default dictionary size based on its maximum memory and maximum disk space.

•

If history does exist for the peer and the peer's rank guarantees the peer a dictionary, the peer is allocated a dictionary based on that history.

The peer ranking table is persistent across system reboots; the dictionaries themselves are re-sized upon any of the following conditions: ❐

System restart.

❐

A full dictionary.

❐

If the dictionary size is set manually.

The re-ranking allows potentially unused dictionaries to be identified and removed, freeing resources.

45

Volume 5: Advanced Networking Section G: Manually Re-Sizing a Byte-Cache Dictionary You can manually resize an ADN byte-caching dictionary in two places in the Blue Coat appliance Management Console: From the Statistics > ADN History > Peer Dictionary Sizing tab, or from the Configuration > ADN > Byte Caching tab. You might find the Statistics tab easier to use, since you are not required to know the peer ID. Note, however, that only peers that are online are displayed in the Statistics tab. If a peer is offline, Configuration > ADN > Byte Caching can be used to configure manual dictionary size for any ADN peer. To manually resize byte cache dictionaries from the Statistics tab, continue with the next section. To manually resize byte cache dictionaries from the ADN tab, skip to “To manually resize byte cache dictionaries from the Configuration > ADN > Byte Caching tab:” on page 47. To manually resize byte cache dictionaries from the Statistics tab: 1.

Select Statistics > ADN History > Peer Dictionary Sizing.

2.

The Peer Dictionary Sizing tab gives you statistics relevant to the byte cache dictionary size of all peers on the network. •

Rank: The value of a peer’s dictionary. Manually-configured peers have a higher

rank than dynamically-configured peers. •

Peer ID: The serial number of the device.

•

Peer IP: The IP address of the device.

•

Byte Cache Score: The score of this peer relative to other peers. Score is based on the value of the dictionary and is used to determine rank.

•

Peer Traffic (GB/Day): The average amount of pre-byte-cache traffic per day.

•

Fill Rate (GB/Day): The average amount of data put into the dictionary per day over the last week.

46

Chapter 2: Configuring an Application Delivery Network

Section G: Manually Re-Sizing a Byte-Cache Dictionary •

Recommended Dict Size (GB): The dictionary size the Blue Coat appliance recommends, based on the peer traffic over the last week.

•

Actual Dict Size (GB): The actual size of the dictionary.

Click anywhere on the line of the device whose dictionary you want to re-size. The Edit Peer dialog displays.

3.

To select a dictionary size for the device, select the Manual Re-size radio button and enter the value you want in megabytes.

4.

Click OK to have the resizing take effect immediately

To manually resize byte cache dictionaries from the Configuration > ADN > Byte Caching tab: 1.

Select Configuration > ADN > Byte Caching.

2.

Click New. The Enable Manual Dictionary Sizing dialog displays.

3.

Enter the peer ID (serial number) of the device with whom you are sharing a dictionary.

4.

Enter the new value in megabytes.

5.

Click OK. The peer is added to the manually configured dictionary sizing list and is ranked at the top of the dictionary byte cache table.

Dynamic dictionary sizing is re-enabled through highlighting the peer and selecting Delete.

47

Volume 5: Advanced Networking Section H: Related CLI Syntax to Configure an ADN Network

Section H: Related CLI Syntax to Configure an ADN Network ❐

To enter configuration mode: SGOS#(config) adn SGOS#(config adn) Note:

For detailed information on using these commands, refer to Volume 11: Command Line Reference. ❐

The following subcommands are available: SGOS#(config adn) {enable | disable} SGOS#(config adn) exit SGOS#(config adn) byte-cache SGOS#(config adn byte-cache) peer-size peer-id {size_in_megabytes | auto} SGOS#(config adn byte-cache) exit SGOS#(config adn byte-cache) view SGOS#(config adn) load-balancing SGOS#(config SGOS#(config SGOS#(config SGOS#(config SGOS#(config disable} SGOS#(config SGOS#(config

adn adn adn adn adn

load-balancing) load-balancing) load-balancing) load-balancing) load-balancing)

{enable | disable} exit external-vip IP_address group group_name load-balance-only {enable |

adn load-balancing) no {external-vip | group} adn load-balancing) view

SGOS#(config adn) manager SGOS#(config adn manager) backup-manager {IP_address [ID] | self} SGOS#(config adn manager) exit SGOS#(config adn manager) no {backup-manager | primary-manager} SGOS#(config adn manager) port port_number SGOS#(config adn manager) primary-manager {IP_address [ID] | self} SGOS#(config adn manager) secure-port secure_port_number SGOS#(config adn manager) view [approved-peers | backup-manager-id | pending-peers | primary-manager-id] SGOS#(config adn manager) approved-peers SGOS#(config SGOS#(config SGOS#(config SGOS#(config

adn adn adn adn

approved-peers) approved-peers) approved-peers) approved-peers)

add peer-device-ID exit remove peer-device-ID view

SGOS#(config adn manager) pending-peers SGOS#(config SGOS#(config SGOS#(config SGOS#(config

adn adn adn adn

pending-peers) pending-peers) pending-peers) pending-peers)

{accept | reject} {enable | disable} exit view

SGOS#(config adn) routing SGOS#(config adn routing) exit SGOS#(config adn routing) prefer-transparent {enable | disable} SGOS#(config adn routing) view SGOS#(config adn routing) advertise-internet-gateway

48

Chapter 2: Configuring an Application Delivery Network

Section H: Related CLI Syntax to Configure an ADN Network SGOS#(config adn routing advertise-internet-gateway) {disable | enable} SGOS#(config adn routing advertise-internet-gateway) exemptsubnet {add {subnet_prefix[/prefix_length]} clear-all | remove {subnet_prefix[/prefix_length]} | view} SGOS#(config adn routing advertise-internet-gateway) exit SGOS#(config adn routing advertise-internet-gateway) view SGOS#(config adn routing) server-subnets SGOS#(config adn prefix length] SGOS#(config adn SGOS#(config adn prefix length] SGOS#(config adn SGOS#(config adn

routing server-subnets) add subnet_prefix [/ routing server-subnets) clear-all routing server-subnets) remove subnet_prefix [/ routing server-subnets) exit routing server-subnets) view

SGOS#(config adn) security SGOS#(config adn security) authorization {enable | disable} SGOS#(config adn security) device-auth-profile profile_name [noauthorization] SGOS#(config adn security) exit SGOS#(config adn security) manager-listening-mode {plain-only | plain-read-only | secure-only| both} SGOS#(config adn security) no device-auth-profile SGOS#(config adn security) secure-outbound {none | routing-only| secure-proxies | all} SGOS#(config adn security) tunnel-listening-mode {plain-only | secure-only | both} SGOS#(config adn security) view SGOS#(config adn) tunnel SGOS#(config adn SGOS#(config adn SGOS#(config adn SGOS#(config adn SGOS#(config adn SGOS#(config adn use-local-ip) SGOS#(config adn SGOS#(config adn SGOS#(config adn

tunnel) tunnel) tunnel) tunnel) tunnel) tunnel)

connect-transparent {enable | disable} exit preserve-dest-port {enable | disable} port port_number proxy-processing http {enable | disable} reflect-client-ip (deny | allow |

tunnel) secure-port secure_port_number tunnel) tcp-window-size window_size tunnel) view

49

Volume 5: Advanced Networking Section I: Policy

Section I: Policy The following gestures can be used for WAN optimization from either the VPM or CPL. Note:

For more information on using the VPM or CPL to configure policy, refer to Volume 6: VPM and Advanced Policy or Volume 10: Content Policy Language Guide. ❐

adn.server(yes | no) (Note that this property overrides all other routing and intercept decisions made by ADN based on configuration and routing information.)

❐

adn.server.optimize(yes | no)

❐

adn.server.optimize.inbound(yes | no)

❐

adn.server.optimize.outbound(yes | no)

❐

adn.server.optimize.byte-cache(yes | no)

❐

adn.server.optimize.inbound.byte-cache(yes | no)

❐

adn.server.optimize.outbound.byte-cache(yes | no)

❐

adn.server.optimize.compress(yes | no)

❐

adn.server.optimize.inbound.compress(yes | no)

❐

adn.server.optimize.outbound.compress(yes | no)

❐

adn.server.dscp

50

Chapter 2: Configuring an Application Delivery Network

Section I: Policy

51

Volume 5: Advanced Networking

52

Chapter 3: Attack Detection

The SGOS software 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 DDoStype of virus attack a specific Web site. As the attack progresses, the target host shows decreased responsiveness and often stops responding. Legitimate HTTP traffic is unable to proceed because the infected system is waiting for a response from the target host. Port scanning involves viruses attempting to self-propagate to other machines by arbitrarily attempting to connect to other hosts on the Internet. If the randomly selected host is unavailable or behind a firewall or does not exist, the infected system continues to wait for a response, thus denying legitimate HTTP traffic. The SG appliance prevents attacks by limiting the number of simultaneous TCP connections from each client IP address and either does not respond to connection attempts from a client already at this limit or resets the connection. It also limits connections to servers known to be overloaded. You can configure attack detection for both clients and servers or server groups, such as http://www.bluecoat.com. The client attack-detection configuration is used to control the behavior of virus-infected machines behind the SG appliance. The server attackdetection configuration is used when an administrator knows ahead of time that a virus is set to attack a specific host. This feature is only available through the CLI. You cannot use the Management Console to enable attack detection. This section discusses: ❐

“Configuring Attack-Detection Mode for the Client” on page 53

❐

“Configuring Attack-Detection Mode for a Server or Server Group” on page 57

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)

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

client limits enabled: true

❐

client interval: 20 minutes

53

Volume 5: Advanced Networking

❐

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 are not dropped. SGOS#(config client) enable-limits | disable-limits SGOS#(config client) interval minutes SGOS#(config client) block ip_address [minutes] | unblock ip_address SGOS#(config client) default block-action drop | send-tcp-rst SGOS#(config client) default connection-limit integer_between_1_and_65535 SGOS#(config client) default failure-limit integer_between_1_and_500 SGOS#(config client) default unblock-time minutes_between_10_and_1440 SGOS#(config client) default warning-limit integer_between_1_and_100 :

Table 3-1. Changing Global Defaults enable-limits | disable-limits

Toggles between enabled and disabled. The default is disabled. 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. 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 blockaction

drop | sendtcp-rst

Indicates the behavior when clients are at the maximum number of connections or exceed the warning limit: drop the connections that are over the limit or send TCP RST for connections over the limit. The default is drop. This limit can be modified on a perclient 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 perclient basis.

default failurelimit

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.

54

Chapter 3: Attack Detection

Table 3-1. Changing Global Defaults (Continued) default unblocktime

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. By default, the client is blocked until explicitly unblocked. This limit can be modified on a per-client basis.

default warninglimit

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: Client attack-detection configuration is used to control the behavior of virus-infected machines behind the SG appliance. 1.

Verify the system is 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 client submode. SGOS#(config client) edit client_ip_address

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

4.

Change the client limits as necessary. SGOS#(config client ip_address) SGOS#(config client ip_address) integer_between_1_and_65535 SGOS#(config client ip_address) integer_between_1_and_65535 SGOS#(config client ip_address) SGOS#(config client ip_address) integer_between_1_and_65535

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

Table 3-2. Changing the Client Limits 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.

55

Volume 5: Advanced Networking

Table 3-2. Changing the Client Limits (Continued) 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. By default, the client is blocked until explicitly unblocked.

warning-limit

integer

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

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

view 700 50 10 Drop unlimited

To view the configuration for all clients: 1.

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

2.

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

To view all settings: SGOS#(config client) view Client limits enabled: true Client interval: 20 minutes Default client limits: Client connection limit: 100 Client failure limit: 50 Client warning limit: 10 Blocked client action: Drop Client connection unblock time: unlimited Client limits for 10.25.36.47: Client connection limit: Client failure limit: Client warning limit: Blocked client action: Client connection unblock time:

700 50 10 Drop unlimited

To view the number of simultaneous connections to the SG appliance: SGOS#(config client) view connections Client IP Connection Count 127.0.0.1 1 10.9.16.112 1 10.2.11.133 1

56

Chapter 3: Attack Detection

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 Server attack-detection configuration is used when an administrator knows ahead of time that a virus is set to attack a specific host. 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. You must create a server group before you can make changes to the configuration. To create a server or server group: 1.

At the (config) prompt: SGOS#(config) attack-detection SGOS#(config attack-detection) server

The prompt changes to: SGOS#(config server)

2.

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

To edit a server or server group: At the (config server) prompt: 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

add | remove

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

Adds or removes a server from this server group.

57

Volume 5: Advanced Networking

request-limit

integer

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

To view the server or server group configuration: SGOS#(config server hostname) view Server limits for hostname: Request limit: 1500

58

Chapter 4: TCP Connection Forwarding

This chapter describes how to configure the SG appliance to join peer clusters that process requests in asymmetrically routed networks.

About Asymmetric Routing Environments It is common in larger enterprises to have multiple SG appliances residing on different network segments; for example, the enterprise receives Internet connectivity from more than one ISP. If IP spoofing is enabled, connection errors can occur because the SG appliance terminates client connections and makes a new outbound connection (with the source IP address of the client) to the server. The response might not return to the originating SG appliance, as illustrated in the following diagram.

Figure 4-1. Multiple SG appliances in an asymmetric routing environment

59

Volume 5: Advanced Networking

The TCP Connection Forwarding Solution Enabling TCP Connection Forwarding is a critical component of the following solutions: ❐

“About Bidirectional Asymmetric Routing” on page 60.

❐

“About Dynamic Load Balancing” on page 61.

❐

“About ADN Transparent Tunnel Load Balancing” on page 61.

About Bidirectional Asymmetric Routing To solve the asymmetric routing problem, at least one SG appliance on each network segment must be configured to perform the functionality of an L4 switch. These selected appliances form a cluster. With this peering relationship, the connection responses are able to be routed to the network segment where the originating client resides. In the 5.1.4.x release, cluster membership is manual; that is, SG appliances must be added to a cluster by enabling connection forwarding and adding a list of other peers in the cluster. After a peer joins a cluster, it begins sending and receiving TCP connections, and notifies the other peers about its connection requests.

Figure 4-2. SG appliances share TCP connection information

60

Chapter 4: TCP Connection Forwarding

About Dynamic Load Balancing In a deployment where one SG appliance receives all of the traffic originating from clients and servers from an external routing device and distributes connections to other SG appliances, TCP connection forwarding enables all of the appliances to share connection information (for each new connection) and the in-line SG appliance routes the request back to the originating appliance, thus lightening the load on the inline appliance.

Figure 4-3. An SG appliance serving inline as a load balancer

In the above network topography, SG appliance SG 1 is deployed inline to receive all traffic (by way of a switch) originating from the clients to the servers and servers to the clients and serves as a load balancer to the other four SG appliances. Appliances 2 through 5 also have independent connectivity to the clients and the servers. When all appliances belong to the same peering cluster and have connection forwarding enabled, appliance SG 1 knows which of the other appliances made a specific connection and routes the response to that appliance. In this deployment, a TCP acknowledgement is sent and retransmitted, if required, to ensure the information gets there, but each new connection message is not explicitly acknowledged. However, if the SG appliance receives packets for a connection that is unrecognized, the appliance retains those packets for a short time before deciding whether to forward or drop them, which allows time for a new connection message from a peer to arrive. While adding more peers to a cluster increases the connection synchronization traffic, the added processing power all but negates that increase. You can have multiple peer clusters, and if you are cognoscente of traffic patterns to and from each cluster, you can create an effective cluster strategy. The only limitation is that an SG appliance can only be a peer in one cluster. The Blue Coat load balancing solution is discussed in greater detail in earlier sections of this chapter.

About ADN Transparent Tunnel Load Balancing TCP connection forwarding is a critical component of the Blue Coat ADN transparent tunnel load balancing deployment. Achieving efficient load balancing is difficult when ADN transparent tunneling is employed and an external load balancer is distributing requests to multiple SG appliances.

61

Volume 5: Advanced Networking

A user-noticeable performance degradation occurs if the router, switch, or load balancer sends traffic to an SG appliance that has not been servicing a particular client long enough to build up substantial byte caching dictionary, thus the compression ratio is low. When the SG appliances connected to the routing device belong to the same peer cluster and connection forwarding is enabled, the ADN managers on each appliance know which of their peers has the best byte caching dictionary with the client and forwards the request. This is illustrated in the following diagram.

Figure 4-4. ADN Transparent Tunnel load balancing with Connection Forwarding enabled

Load balancing is based on the IP address of the remote ADN peer. This assures that all the traffic from a particular ADN peer to the local ADN cluster always goes to a specific local SG appliance, thus eliminating the inefficiency of keeping dictionaries for that remote peer on more than one local SG appliance. The Blue Coat ADN solution is discussed in greater detail in Chapter 2: "Configuring an Application Delivery Network" on page 13.

62

Chapter 4: TCP Connection Forwarding

TCP Configuration Forwarding Deployment Notes When configuring your network for TCP connection forwarding, consider the following: ❐

Peers can be added to clusters at any time without affecting the performance of the other peers. An SG appliance that joins a peer cluster immediately contacts every other peer in the cluster. Likewise, a peer can leave a cluster at anytime. This might be a manual drop or a forced drop because of a hardware or software failure. If this happens, the other peers in the cluster continue to process connection forwarding requests.

❐

Connections between peers are not encrypted and not authenticated. If you do not assign the correct local IP address on an SG appliance with multiple IP addresses, traffic sent peer to peer might be routed through the Internet, not the intranet, exposing your company-sensitive data.

❐

The peering port—the connection between SG appliance connection forwarding peers—cannot be configured with bypass services. This means an SG appliance cannot be deployed in transparent mode between two SG appliances that are peers.

❐

SG does not enforce a maximum number of appliances a peer cluster supports, but currently the deployment is designed to function with up to 20 SG appliances.

❐

Because TCP connection forwarding must function across different network segments, employing multicasting, even among SG appliance peers on the same network, is not supported.

❐

There might be a slight overall performance impact from enabling TCP connection forwarding, especially in deployments where traffic is largely already being routed to the correct SG appliance. If a substantial amount of traffic requires forwarding, the performance hit is equitable to processing the same amount of bridging traffic.

Configuring TCP Connection Forwarding As described in the previous concept sections, enabling TCP connection forwarding provides one component to a larger deployment solution. After you have deployed Blue Coat appliances into the network topography that best fits your enterprise requirements, enable TCP connection forwarding on each Blue Coat appliance that is to belong to the peering cluster, and add the IP address of the other peers. The peer lists on all of the cluster members must be the same, and an SG appliance cannot have a different local peer IP address than what is listed in another peers list. A peer list can contain only one local IP address. To enable TCP Connection Forwarding: 1.

Select Configuration > Network > Advanced > Connection Forwarding.

63

Volume 5: Advanced Networking

4 2

3b

3a

2.

From the Local IP drop-down list, select the IP address that is routing traffic to this SG appliance. Specify the port number (the default is 3030) that the SG appliance uses to communicate with all peers, which includes listening and sending out connection forwarding cluster control messages to all peers in the group. All peers in the group must use the same port number (when connection forwarding is enabled, you cannot change the port number).

3.

Add the cluster peers: a.

Click Add.

b.

In the Peer IPs field, enter the IP addresses of the other peers in the cluster that this SG appliance is to communicate connection requests with.; click OK.

4.

Select Enable Connection Forwarding.

5.

Click Apply.

This SG appliance joins the peer cluster and immediately begins communicating with its peers.

Copying Peers to Another SG Appliance in the Cluster If you have a larger cluster that contains several peer IP addresses, select all of the IP addresses in the Connection Forwarding Peer IPs list and click Copy To Clipboard; this action includes the local IP address of the peer you are copying from, and it will be correctly added as a remote peer IP address on the next appliance. When you configure connection forwarding on the next appliance, click Paste From Clipboard to paste the list of peers, and click Apply. Whichever peer IP address is the new appliance’s local IP address is pulled out of the list and used as the local IP address on the new appliance. If a local IP address is not found or if more than one local IP address is found, the paste fails with an error.

64

Chapter 4: TCP Connection Forwarding

Removing a Peer A network change or other event might require you to remove a peer from the cluster. Highlight a peer IP address and click Remove. The peer connection is terminated and all connections associated with the peer are removed from the local system. Note: A CLI command is available that allows you to disable a peer, which terminates the communication with other peers, but does not remove the peer from the cluster. See the next section.

Related CLI Syntax to Configure TCP Connection Forwarding ❐

To enter configuration mode: SGOS# (config) connection-forwarding

❐

The following subcommands are available: SGOS# SGOS# SGOS# SGOS# SGOS#

❐

(config (config (config (config (config

connection connection connection connection connection

forwarding) forwarding) forwarding) forwarding) forwarding)

add ip_address port number [enable | disable] [clear | remove ip_address] [view | exit]

The following configuration and statistics commands are available: SGOS# show connection-forwarding configuration SGOS# show connection-forwarding statistics

65

Volume 5: Advanced Networking

66

Chapter 5: Bandwidth Management

Bandwidth management (BWM) allows you to classify, control, and limit the amount of bandwidth used by different classes of network traffic flowing into or out of the SG appliance. Network resource sharing (or link sharing) is accomplished by using a bandwidth-management hierarchy where multiple traffic classes share available bandwidth in a controlled manner. Note: The SG appliance does not attempt to reserve any bandwidth on the network links that it is attached to or otherwise guarantee that the available bandwidth on the network can sustain any of the bandwidth limits which have been configured on it. The SG appliance can only shape the various traffic flows passing through it, and prioritize some flows over others according to its configuration.

By managing the bandwidth of specified classes of network traffic, you can accomplish the following: ❐

Guarantee that certain traffic classes receive a specified minimum amount of available bandwidth.

❐

Limit certain traffic classes to a specified maximum amount of bandwidth.

❐

Prioritize certain traffic classes to determine which classes have priority over available bandwidth.

Bandwidth Management Overview To manage the bandwidth of different types of traffic that flow into, out of, or through the SG appliance, you must do the following: ❐

Determine how many bandwidth classes you need and how to configure them to accomplish your bandwidth management goals. This includes determining the structure of one or more bandwidth hierarchies if you want to use priority levels to manage bandwidth.

❐

Create and configure bandwidth classes accordingly.

❐

Create policy rules using those bandwidth classes to identify and classify the traffic in the SG appliance.

❐

Enable bandwidth management.

Bandwidth management configuration consists of two areas: ❐

Bandwidth allocation This is the process of creating and configuring bandwidth classes and placing them into a bandwidth class hierarchy. This process can be done using either the Management Console or the CLI.

67

Volume 5: Advanced Networking

❐

Flow classification This is the process of classifying traffic flows into bandwidth management classes using policy rules. Policy rules can classify flows based on any criteria testable by policy. You can create policy rules using either the Visual Policy Manager (VPM), which is accessible through the Management Console, or by composing Content Policy Language (CPL).

Note: For more information about using VPM to create policy rules, refer to Volume 6: VPM and Advanced Policy. For information about composing CPL, refer to Volume 10: Content Policy Language Guide.

Allocating Bandwidth The process of defining bandwidth classes and grouping them into a bandwidth class hierarchy is called bandwidth allocation. Bandwidth allocation is based on: ❐

the placement of classes in a hierarchy (the parent/child relationships).

❐

the priority level of classes in the same hierarchy.

❐

the minimum and/or maximum bandwidth setting of each class.

For example deployment scenarios, see “Bandwidth Allocation and VPM Examples” on page 78.

Bandwidth Classes To define a bandwidth class, you create the class, giving it a name meaningful to the purpose for which you are creating it. You can configure the class as you create it or edit it later. The available configuration settings are: ❐

Parent: Used to create a bandwidth-management hierarchy.

❐

Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this class.

❐

Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this class.

❐

Priority: Relative priority level among classes in the same hierarchy.

Parent Class A parent class is a class that has children. When you create or configure a bandwidth class, you can specify another class to be its parent (the parent class must already exist). Both classes are now part of the same bandwidth-class hierarchy, and so are subject to the hierarchy rules (see “Class Hierarchy Rules and Restrictions” on page 70). Minimum Bandwidth Setting a minimum for a bandwidth class guarantees that class receives at least that amount of bandwidth, if the bandwidth is available. If multiple hierarchies are competing for the same available bandwidth, or if the available bandwidth is not enough to cover the minimum, bandwidth management is not be able to guarantee the minimums defined for each class.

68

Chapter 5: Bandwidth Management

Note: The SG appliance does not attempt to reserve any bandwidth on the network links that it is attached to or otherwise guarantee that the available bandwidth on the network can be used to satisfy bandwidth class minimums. The SG appliance can only shape the various traffic flows passing through it, and prioritize some flows over others according to its configuration.

Maximum Bandwidth Setting a maximum for a bandwidth class puts a limit on how much bandwidth is available to that class. It does not matter how much bandwidth is available; a class can never receive more bandwidth than its maximum. To prevent a bandwidth class from using more than its maximum, the SG appliance inserts delays before sending packets associated with that class until the bandwidth used is no more than the specified maximum. This results in queues of packets (one per class) waiting to be sent. These queues allow the SG appliance to use priority settings to determine which packet is sent next. If no maximum bandwidth is set, every packet is sent as soon as it arrives, so no queue is built and nothing can be prioritized. Unlike minimums and priority levels, the maximum-bandwidth setting can purposely slow down traffic. Unused bandwidth can go to waste with the maximum-bandwidth setting, while the minimum-bandwidth settings and priority levels always distributes any unused bandwidth as long as classes request it. However, priority levels are not meaningful without a maximum somewhere in the hierarchy. If a hierarchy has no maximums, any class in the hierarchy can request and receive any amount of bandwidth regardless of its priority level. Priority When sharing excess bandwidth with classes in the same hierarchy, the class with the highest priority gets the first opportunity to use excess bandwidth. When the highpriority class uses all the bandwidth it needs or is allowed, the next class gets to use the bandwidth, if any remains. If two classes in the same hierarchy have the same priority, then excess bandwidth is shared in proportion to their maximum bandwidth setting.

Class Hierarchies Bandwidth classes can be grouped together to form a class hierarchy. Creating a bandwidth class allows you to allocate a certain portion of the available bandwidth to a particular type of traffic. Putting that class into a bandwidth-class hierarchy with other bandwidth classes allows you to specify the relationship among various bandwidth classes for sharing available (unused) bandwidth. The way bandwidth classes are grouped into the bandwidth hierarchy determines how they share available bandwidth among themselves. You create a hierarchy so that a set of traffic classes can share unused bandwidth. The hierarchy starts with a bandwidth class you create to be the top-level parent. Then you can create other bandwidth classes to be the children of the parent class, and those children can have children of their own. To manage the bandwidth for any of these classes, some parent in the hierarchy must have a maximum bandwidth setting. The classes below that parent can then be configured with minimums and priority levels to determine how unused bandwidth is shared among them. If none of the higher level classes have a maximum bandwidth value set, then bandwidth flows from the parent to the child classes without limit. In that case, minimums and priority levels are meaningless, because all classes get all the bandwidth they need at all times. The bandwidth, in other words, is not being managed.

69

Volume 5: Advanced Networking

Class Hierarchy Rules and Restrictions Certain rules and restrictions must be followed to create a valid BWM class hierarchy: ❐

Each traffic flow can only belong to one bandwidth management class. You can classify multiple flows into the same bandwidth class, but any given flow is always counted as belonging to a single class. If multiple policy rules match a single flow and attempt to classify it into multiple bandwidth classes, the last classification done by policy applies.

❐

When a flow is classified as belonging to a bandwidth class, all packets belonging to that flow are counted against that bandwidth class.

❐

If a minimum bandwidth is configured for a parent class, it must be greater than or equal to the sum of the minimum bandwidths of its children.

❐

If a maximum bandwidth is configured for a parent class, it must be greater than or equal to the largest maximum bandwidth set on any of its children. It must also be greater than the sum of the minimum bandwidths of all of its children.

❐

The minimum bandwidth available to traffic directly classified to a parent class is equal to its assigned minimum bandwidth minus the minimum bandwidths of its children. For example, if a parent class has a minimum bandwidth of 600 kbps and each of its two children have minimums of 300 kbps, the minimum bandwidth available to traffic directly classified into the parent class is 0.

Relationship among Minimum, Maximum, and Priority Values Maximum values can be used to manage bandwidth for classes whether or not they are placed into a hierarchy. This is not true for minimums and priorities, which can only manage bandwidth for classes that are placed into a hierarchy. Additionally, a hierarchy must have a maximum configured on a high-level parent class for the minimums and priorities to manage bandwidth. This is because, without a maximum, bandwidth goes to classes without limit and there is no point to setting priorities or minimum guarantees. Bandwidth cannot be managed unless a maximum limit is set somewhere in the hierarchy. When a hierarchy has a maximum on the top-level parent and minimums, maximums and priorities placed on the classes related to that parent, the following conditions apply: ❐

If classes in a hierarchy have minimums, the first thing that happens with available bandwidth is that all the minimum requests are satisfied. If the amount requested is less than the minimum for any class, it receives the entire amount, and its priority level does not matter. Even though a minimum is considered to be a guaranteed amount of bandwidth, satisfying minimums is dependent on the parent being able to receive its own maximum, which is not guaranteed.

❐

When all of the classes in a hierarchy have had their minimums satisfied, any additional requests for bandwidth must be obtained. When a class requests more than its minimum, it must obtain bandwidth from its parent or one of its siblings. If, however, a class requests more than its maximum, that request is denied—no class with a specified maximum is ever allowed more than that amount.

❐

If a class does not have a minimum specified, it must obtain all of the bandwidth it requests from its parents or siblings, and it cannot receive any bandwidth unless all of the minimums specified in the other classes in its hierarchy are satisfied.

70

Chapter 5: Bandwidth Management

❐

Classes obtain bandwidth from their parents or siblings based on their priority levels—the highest priority class gets to obtain what it needs first, until either its entire requested bandwidth is satisfied or until it reaches its maximum. After that, the next highest priority class gets to obtain bandwidth, and this continues until either all the classes have obtained what they can or until the maximum bandwidth available to the parent has been reached. The amount available to the parent can sometimes be less than its maximum, because the parent must also participate in obtaining bandwidth in this way with its own siblings and/or parent if it is not a top-level class.

Flow Classification You can classify flows to BWM classes by writing policy rules that specify the bandwidth class that a particular traffic flow belongs to. A typical transaction has four traffic flows: 1.

Client inbound—Traffic flowing into the SG appliance from a client (the entity sending a request, such as a client at a remote office linked to the appliance).

2.

Server outbound—Traffic flowing out of the SG appliance to a server.

3.

Server inbound—Traffic flowing back into the SG appliance from a server (the entity responding to the request).

4.

Client outbound—Traffic flowing back out of the SG appliance to a client.

The figure below shows the traffic flows between a client and server through the SG appliance.

Some types of traffic can flow in all four directions. The following example describes different scenarios that you might see with an HTTP request. A client sends a GET to the SG appliance (client inbound). The SG appliance then forwards this GET to a server (server outbound). The server responds to the SG appliance with the appropriate content (server inbound), and then the appliance delivers this content to the client (client outbound). Policy allows you to configure different classes for each of the four traffic flows. See “Using Policy to Manage Bandwidth” on page 77 for information about classifying traffic flows with policy.

Configuring Bandwidth Allocation You can use either the Management Console or the CLI to do the following tasks: ❐

Enable or disable bandwidth management.

❐

Create and configure bandwidth classes.

71

Volume 5: Advanced Networking

❐

Delete bandwidth classes.

❐

View bandwidth management class configurations.

Note: If you plan to manage the bandwidth of streaming media protocols (Windows Media, Real Media, or QuickTime), you might want to use the streaming features instead of the bandwidth management features described in this section. For most circumstances, Blue Coat recommends that you use the streaming features to control streaming bandwidth rather than the bandwidth management features. For information about the differences between these two methods, refer to Volume 3: Web Communication Proxies.

Enabling Bandwidth Management The following procedures explain how to enable or disable bandwidth management. To enable bandwidth management: 1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

2.

Select or deselect Enable Bandwidth Management.

3.

Click Apply to commit the changes to the SG appliance.

Creating, Editing, and Deleting Bandwidth Classes The following procedure details how to create bandwidth management class. To create a BWM class: 1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

An existing parent class

3a 3b 3c 3d 3e 2

2.

To create a new BWM class, click New.

72

Chapter 5: Bandwidth Management

3.

Fill in the fields as appropriate: a.

Class name: Assign a meaningful name for this class. The name can be up to

64 characters long; spaces are not allowed. b.

Parent: (Optional) To assign the class as a child of another parent class in the

bandwidth class hierarchy, select an existing parent class from the drop-down list. c.

Min. Bandwidth: (Optional) Select Min. Bandwidth and enter a minimum

bandwidth value in the field (kilobits per second (kbps)). The default minimum bandwidth setting is unspecified, meaning the class is not guaranteed a minimum amount of bandwidth. d.

Max. Bandwidth: (Optional) Select Max. Bandwidth and enter a maximum

bandwidth value in the field. The default maximum bandwidth setting is unlimited, meaning the class is not limited to a maximum bandwidth value by this setting. e.

Priority: Select a priority level for this class from the Priority drop-down list— 0 is the lowest priority level and 7 is the highest. The default priority is 0.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Figure 5-1. A child bandwidth management class added to a parent class.

After you add a child class to a parent class, the parent class is denoted by a folder icon. Double-click the folder to view all of the child classes under that parent. To edit a BWM class: 1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

2.

Highlight the class and click Edit.

3.

Edit the fields as appropriate.

To delete a BWM class: Note: You cannot delete a class that is referenced by another class or by the currently installed policy. For instance, you cannot delete a class that is the parent of another class or one that is used in an installed policy rule. If you attempt to do so, a message displays explaining why this class cannot be deleted.

1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

2.

Highlight the class to delete and Delete.

3.

Click Yes to delete the class.

4.

Click Apply.

Viewing Bandwidth Management Configurations You can view the following bandwidth class configurations: ❐

Level in the hierarchy (parent/child relationships)

73

Volume 5: Advanced Networking

❐

Priority level

❐

Maximum bandwidth value

❐

Minimum bandwidth value

To view BWM configuration: 1.

Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. On this tab, you can view a class’s minimum, maximum and priority value. Top level classes are visible—classes with children have a folder icon on the left.

2.

To view the configurations of the child class(es) of a class, double-click the folder icon. The child classes become visible. A second double-click closes the folder.

Related CLI Syntax to Configure Bandwidth Management ❐

To enter configuration mode: SGOS#(config) bandwidth-management

❐

The following subcommands are available: SGOS#(config bandwidth-management) enable | disable SGOS#(config bandwidth-management) create | delete bwm_class

❐

To enter edit mode: SGOS#(config bandwidth-management) edit bwm_class

❐

The following subcommands are available: SGOS#(config bw-class bwm_class) min-bandwidth minimum_in_kbps SGOS#(config bw-class bwm_class) max-bandwidth maximum_in_kbps SGOS#(config bw-class bwm_class) priority value_from_0_to_7 bandwidth-management bwm_class) no {min-bandwidth | max-bandwidth} SGOS#(config bandwidth-management bwm_class) parent parent_class_name -orSGOS#(config bandwidth-management bwm_class) no parent SGOS#(config bandwidth-management bwm_class) view

Bandwidth Management Statistics The bandwidth management statistics tabs (Current Class Statistics and Total Class Statistics) display the current packet rate and total number of packets served, the current bandwidth rate, and the total number of bytes served and packets dropped.

Current Class Statistics Tab The Current Class Statistics tab displays the following information for each bandwidth class: ❐

Current Packet Rate: current packets-per-second (pps) value.

❐

Current Bandwidth: current bandwidth in kilobits per second (Kbps).

To view current bandwidth management class statistics: 1.

Select Statistics > Bandwidth Management > Current Class Statistics. The high level bandwidth classes and their statistics are visible.

74

Chapter 5: Bandwidth Management

2.

To view the statistics of child bandwidth classes, double-click the folder icon of the parent class. The child classes become visible. A second double-click closes the folder.

Total Class Statistics Tab The Total Class Statistics tab displays the following information for each bandwidth class: ❐

Packets: the total number of packets served.

❐

Bytes: the total number of bytes served.

❐

Drops: the total number of packets dropped.

To view total bandwidth management class statistics: 1.

Select Statistics > Bandwidth Management > Total Class Statistics. The high level bandwidth classes and their statistics are visible.

75

Volume 5: Advanced Networking

2.

To view the statistics of child bandwidth classes, double-click the folder icon of the parent class. A second double-click closes the folder.

Bandwidth Management Statistics in the CLI To view bandwidth management statistics: 1.

To view all bandwidth management statistics, enter the following commands at the prompt: SGOS#(config) bandwidth-management SGOS#(config bandwidth-management) view statistics

2.

To view the BWM statistics for a specific class, enter the following command at the (config) command prompt: SGOS#(config bandwidth-management) view statistics bwm_class

Example SGOS#(config bandwidth-management) view statistics http Class Name: http Parent: Minimum Bandwidth: unspecified Maximum Bandwidth: unlimited Priority: 0 Total Bytes: 0 bytes Total Packets: 0 pkts Dropped Packets: 0 pkts Current Bandwidth: 0 kbps Current Packet Rate: 0 pps Queue Length: 0 bytes Parent

The class name of the parent of this class.

Minimum Bandwidth

The maximum bandwidth setting for this class.

Maximum Bandwidth

The minimum bandwidth setting for this class.

Priority

The priority level for this class.

Total Bytes

The total number of bytes served.

Total Packets

The total number of packets served.

Dropped Packets

Total number of packets dropped (packets in the queue that are dropped because the queue length is reached).

Current Bandwidth

Current bandwidth value (in kilobits per second).

Current Packet Rate

Current packets-per-second value.

Queue Length

Maximum length allowed for the queue of packets that lack available bandwidth but are waiting for bandwidth to become available.

To clear bandwidth management statistics: 1.

To clear bandwidth management statistics for all bandwidth management classes, enter the following command at the prompt: SGOS# clear-statistics bandwidth-management

76

Chapter 5: Bandwidth Management

2.

To clear bandwidth management statistics for a particular class, enter the following command at the prompt: SGOS# clear-statistics bandwidth-management class bandwidth_class_name

Using Policy to Manage Bandwidth After creating and configuring bandwidth management classes, create policy rules to classify traffic flows using those classes. Each policy rule can only apply to one of four traffic flow types: ❐

Client inbound

❐

Client outbound

❐

Server inbound

❐

Server outbound

You can use the same bandwidth management classes in different policy rules; one class can manage bandwidth for several types of flows based on different criteria. However, any given flow is always be counted as belonging to a single class. If multiple policy rules match a flow and try to classify it into multiple bandwidth classes, the last classification done by policy applies. To manage the bandwidth classes you have created, you can either compose CPL (see “CPL Support for Bandwidth Management” on page 77 below) or you can use VPM (see “VPM Support for Bandwidth Management” on page 78). To see examples of policy using these methods, see “Bandwidth Allocation and VPM Examples” on page 78 or “Policy Examples: CPL” on page 85.

CPL Support for Bandwidth Management You must use policy to classify traffic flows to different bandwidth classes. Refer to Volume 10: Content Policy Language Guide for more information about writing and managing policy.

CPL Triggers You can use all of the CPL triggers for BWM classification (refer to Volume 10: Content Policy Language Guide for information about using CPL triggers). Basing a bandwidth decision on a trigger means that the decision does not take effect until after the information needed to make that decision becomes available. For example, if you set the CPL to trigger on the MIME type of the HTTP response, then the HTTP headers must be retrieved from the OCS before a classification can occur. The decision to retrieve those headers occurs too late to count any of the request bytes from the client or the bytes in the HTTP response headers. However, the decision affects the bytes in the body of the HTTP response and any bytes sent back to the client.

Supported CPL Bandwidth class can be set with policy on each of these four traffic flows: ❐

limit_bandwidth.client.inbound(none | bwm_class)

❐

limit_bandwidth.client.outbound(none | bwm_class)

❐

limit_bandwidth.server.inbound(none | bwm_class)

❐

limit_bandwidth.server.outbound(none | bwm_class)

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed.

77

Volume 5: Advanced Networking

VPM Support for Bandwidth Management You can manage bandwidth using VPM in the Action column of four policy layers: Web Access, DNS Access, Web Content, and Forwarding Layers. For more information about using VPM to manage bandwidth, refer to Volume 6: VPM and Advanced Policy. For examples of bandwidth management scenarios using VPM, see "Bandwidth Allocation and VPM Examples" below.

Bandwidth Allocation and VPM Examples This section illustrates how to use the VPM to allocate bandwidth, arrange hierarchies, and create policy. It describes an example deployment scenario and the tasks an administrator must accomplish to manage the bandwidth for this deployment. For specific instructions about allocating bandwidth, see “Configuring Bandwidth Allocation” on page 71. For examples of CPL bandwidth management tasks, see “Policy Examples: CPL” on page 85. Task One: Bandwidth Allocation The administrator is responsible for managing the bandwidth of three branch offices. He was told to ensure that each office uses no more than half of its total link bandwidth for Web and FTP traffic. The total link bandwidth of each office is as follows: ❐

Office A: 1.5 Mb

❐

Office B: 1 Mb

❐

Office C: 2 Mb

He creates one bandwidth class for each of the three offices and configures the maximum bandwidth to an amount equal to half of the total link bandwidth of each, as shown below. He also creates policy rules for each class, as described below in "Task One: VPM".

Each of the classes above has a maximum set at an amount equal to half of the total link bandwidth for each office. A hierarchy does not exist in this scenario. Task One: VPM The administrator has created one bandwidth class for each office, setting a maximum bandwidth on each one equal to the half of the total link bandwidth of each. Now he must create policy rules to classify the traffic flows.

78

Chapter 5: Bandwidth Management

The administrator launches the VPM and creates a new Web Access Layer, naming it FTP/ HTTP Limitations. He selects the Client IP Address/Subnet object in the Source column, filling in the IP address and mask of the subnet used by Office_A.

He selects a Combined Service Object in the Service column, naming it FTP/HTTP and adding a Client Protocol for FTP and for HTTP.

79

Volume 5: Advanced Networking

He adds both protocols to the At least one of these objects field.

In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it to manage the bandwidth of Office_A on the Client side in the Outbound direction. He adds two more similar rules for the other two offices. He is able to reuse the same Combined Service Object in the Service column, but must add new objects specific to each office in the Source and Action columns. The order of the rules does not matter here,

because each office, and thus each rule, is distinct because of its IP address/subnet mask configuration. Task Two: Bandwidth Allocation A few days later, the administrator gets a visit from the CEO of his company. She wants him to fix it so that she can visit any of the branch offices without having her own Web and FTP access slowed down unnecessarily. The administrator creates two more classes for each office: one for the CEO and another for everyone else (employees). He sets the parent class of each new class to the appropriate class that he created in Task One. For example, he creates Emp_A and CEO_A and sets their parent class to Office_A. He also sets a priority level for each class: 0 (the lowest) for employees and 1 for the CEO. He then uses VPM to create additional policy rules for the new classes (see "Task Two: VPM" below). This figure shows the hierarchical relationship among all of the classes.

80

Chapter 5: Bandwidth Management

The administrator now has three separate hierarchies. In each one, bandwidth is limited by the configuration of the parent class, and the two child classes are prioritized to determine how they share any unused bandwidth. Because no minimums have been set, the highest priority class has the first opportunity to use all of the available bandwidth; whatever is left then goes to the next priority class. Priority levels are only effective among the classes in the same hierarchy. This means that the priority levels for the Office_A hierarchy do not affect the classes in the Office_B or Office_C hierarchies. Task Two: VPM Because the CEO wants to prioritize FTP and HTTP access among employees and herself, the administrator must create additional bandwidth classes (as described above in "Task Two: Bandwidth Allocation") and write policy rules to classify the traffic for the new classes.

He first edits each of the three VPM rules for the three offices. He edits each the Manage Bandwidth objects, changing the name of the objects to Emp_A, Emp_B, and Emp_C and changes the bandwidth class to the corresponding employee class.

81

Volume 5: Advanced Networking

Next, he creates three more rules for the CEO, moving them above the first three rules. For the CEO rules, he selects the same combined FTP/HTTP object in the Service column; in the Action column, he selects a Manage Bandwidth object configured for client side/outbound, as before, but this time, he names the objects CEO_A, CEO_B, and CEO_C and selects the corresponding CEO bandwidth class. In the Source column, he creates a Combined Source Object, naming it for the CEO. He combines the Client IP/subnet object already created for each office with a User object that he creates for the CEO. The administrator places all three CEO rules above the employee rules, because the SG appliance looks for the first rule that matches a given situation and ignores the remaining rules. If he had placed the CEO rules below the employee rules, the SG appliance would never get to the CEO rules because the CEO’s Web surfing client IP address matches both the CEO rules and the employee rules, and the SG appliance would stop looking after the first match. With the CEO rules placed first, the SG appliance applies the CEO rules to the CEO’s Web surfing, and an employee’s Web surfing does not trigger the CEO rules and instead skips ahead to the appropriate employee rule. Task Three: Bandwidth Allocation It soon becomes apparent that CEO visits are causing problems for the branch offices. At times, she uses all of the available bandwidth, resulting in decreased productivity throughout the office she visits. Also, management has complained that they have been given the same priority for FTP and HTTP traffic as regular employees, and they are requesting that they be given priority over employees for this type of traffic. First, the administrator creates two new classes for each office. In this example, we look at the classes and configurations for the first office only. He creates a class called Staff_A and sets a minimum bandwidth of 500 kbps on it. He also creates a class called Mgmt_A, setting the priority to 1 and the parent to Staff_A. He edits the class Emp_A, setting the parent to Staff_A. Finally, he edits the class CEO_A, changing the priority to 2. The resulting hierarchy is illustrated below. To see what the administrator did to the policy rules, see “Task Three: VPM” on page 83.

82

Chapter 5: Bandwidth Management

In the example illustrated above, employees and management combined are guaranteed a total of 500 kbps. The CEO’s priority level has no effect until that minimum is satisfied. This means that the CEO can only use 250 kbps of bandwidth if the rest of the staff are using a total of 500 kbps. It also means that the CEO can use 750 kbps if no one else is using bandwidth at the time. In fact, any of the classes can use 750 kbps if the other classes use none. Priority levels kick in after all of the minimums are satisfied. In this example, if the staff requests more than 500 kbps, they can only receive it if the CEO is using less than 250 kbps. Now notice that the minimum setting for the staff is set on the parent class, Staff_A, and not on the child classes, Emp_A or Mgmt_A. This means that the two child classes, representing employees and management, share a minimum of 500 kbps. But they share it based on their priority levels. This means that management has priority over employees. The employees are only guaranteed a minimum if management is using less than 500 kbps. Task Three: VPM The administrator has added additional classes for each office and edited the existing employee classes, as described above in "Task Three: Bandwidth Allocation". One of the new classes he added for each office is a parent class that does not have traffic classified to it; it was created to provide a minimum amount of bandwidth to its child classes. Not every class in the hierarchy has to have a traffic flow. This means that he needs to add just three more rules for the three new management classes. For the management rules, he selects the same combined FTP/HTTP object in the Service column; in the Action column, he selects a Manage Bandwidth object configured for client side/outbound with the bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or Mgmt_C). In the Source column, he creates a Combined Source Object containing the subnet object for the office and the Group object for management. The management rules must go above the employee rules, although it does not matter where they are placed in relation to the CEO rules. This would not be true if the CEO was part of the same group as management, however. If that were true, the CEO rules would still need to go on top. Task Four: Bandwidth Allocation The administrator decided later that he needed to guarantee employees some bandwidth. He configures a minimum for the class Emp_A, as illustrated below.

83

Volume 5: Advanced Networking

He decides to leave the minimum on the parent class Staff_A and not to set a minimum for the class Mgmt_A. This is okay, because the minimum of the parent class is available to its children if the parent class does not use all of it, and the only way that the CEO can get more than 250 kbps is if the employees and management combined use less than 500. This last change does not require additional changes to policy; the administrator has added a minimum to a class that he has already classified for traffic using policy. In the above scenario, the class called Staff_A does not have traffic configured for it—it was created to guarantee bandwidth minimums for its child classes. However, if it were configured for traffic, it would have a practical minimum of 300 kbps. The practical minimum of a parent class is equal to its assigned minimum bandwidth minus the minimums of its children. In that case, if the parent class Staff_A used 300 kbps and the child class Emp_A used 200 kbps, the child class Mgmt_A would not receive any bandwidth unless the class CEO_A was using less than 250 kbps. Under those circumstances, the administrator probably also needs to create a minimum for management. Task Five: Bandwidth Allocation The CEO makes another request, this time for the main office, the one the administrator himself works from. This office uses the content filtering feature of the SG appliance to control the types of Web sites that employees are allowed to view. Although the office uses content filtering, access to sports sites is not restricted because the CEO is a big fan. The administrator creates a bandwidth management class called Sports with a maximum bandwidth of 500 kbps and launches VPM to create policy for this class as described below. Task Five: VPM To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access Layer, and sets the Destination column to the Category object that includes sports viewing (content filtering is already set up in VPM). He sets the Action column to the Manage Bandwidth object, selecting Server side/Inbound and the Sports bandwidth class he created. After installing the policy and verifying that bandwidth management is enabled, he is finished.

84

Chapter 5: Bandwidth Management

Policy Examples: CPL The examples below are complete in themselves. The administrator uses CLI to create and configure bandwidth management classes and writes CPL to classify traffic flow for these classes. These examples do not make use of a bandwidth class hierarchy. For examples of hierarchies, see “Bandwidth Allocation and VPM Examples” on page 78. Example One: CPL In this example, the administrator of a college is asked to prevent college students from downloading MP3 files during peak hours, while still allowing the music department to download MP3 files at any time. The CPL triggers used are authentication and/or source subnet and MIME type. The action taken is to limit the total amount of bandwidth consumed by students to 40 kbps. CLI commands: SGOS#(config) bandwidth-management SGOS#(config bandwidth-management) create mp3 SGOS#(config bandwidth-management) edit mp3 SGOS#(config bw-class mp3) max-bandwidth 40

CPL: define condition student_mp3_weekday client_address=student_subnet response_header.Content-Type="audio/ mpeg" \ weekday=1..5 hour=9..16 end condition condition=student_mp3_weekday limit_bandwidth.server.inbound(mp3)

Example Two: CPL In this example, an administrator must restrict the amount of bandwidth used by HTTP POST requests for file uploads from clients to 2 Mbps. The CPL trigger used is request method, and the action taken is to throttle (limit) the amount of bandwidth used by client side posts by limiting inbound client side flows. CLI: SGOS#(config) bandwidth-management bandwidth-management) create http_post SGOS#(config bandwidth-management) edit http_post SGOS#(config bw-class http_post) max-bandwidth 2000

CPL: define condition http_posts http.method=POST end condition condition=http_posts limit_bandwidth.client.inbound(http_post)

Example Three: CPL In this example, the administrator of a remote site wants to limit the amount of bandwidth used to pre-populate the content from headquarters to 50 kbps during work hours. The CPL triggers used are current-time and pre-population transactions. The action taken is to limit the total amount of bandwidth consumed by pre-pop flows. CLI:

85

Volume 5: Advanced Networking

SGOS#(config) bandwidth-management SGOS#(config bandwidth-management) create pre-pop SGOS#(config bandwidth-management) edit pre-pop SGOS#(config bw-class pre-pop) max-bandwidth 50

CPL: define condition prepop_weekday content_management=yes weekday=1..5 hour=9..16 end condition condition=prepop_weekday limit_bandwidth.server.inbound(pre-pop)

86

Chapter 6: Authenticating an SG Appliance

This chapter discusses device authentication, which is a mechanism that allows devices to verify each others’ identity; devices that are authenticated can be configured to trust only other authenticated devices. Note:

SG appliance authentication is always used in association with other SGOS features. For example, you can use appliance authentication with the ADN implementation of secure tunnels. The secure tunnels feature uses authentication, the process of verifying a device’s identity, with authorization, the process of verifying the permissions that a device has. For information on secure tunnels and appliance authentication, see Section D: "Securing the ADN Network" on page 32.

Introduction Device authentication is important in several situations: ❐

Securing the network. Devices that are authenticated have exchanged certification information, verified each others’ identity and know which devices are trusted.

❐

Securing protocols. Many protocols require authentication at each end of the connection before they are considered secure.

This chapter discusses the following topics: ❐

“SG Appliance Overview”

❐

“Appliance Certificates and Device Authentication Profiles” on page 88

❐

“Creating an Authentication Profile” on page 93

❐

“Related CLI Syntax to Manage Device Authentication” on page 95

❐

“Obtaining a Non Blue Coat Appliance Certificate” on page 93

❐

“Related CLI Syntax to Manage Device Authentication” on page 95

SG Appliance Overview The Blue Coat implementation allows devices to be authenticated without sending passwords over the network. Instead, a device is authenticated through certificates and profiles that reference the certificates. Both the profile and the referenced certificate are required for device authentication. ❐

Certificates: Certificates contain information about a specific device. Blue Coat runs an Internet-accessible Certificate Authority (CA) for the purpose of issuing appliance certificates to SGOS devices. You can also create your own appliance certificates.

❐

Profiles: A profile is a collection of information used for device-to-device authentication, including if the device has a certificate and if the certificates of other devices should be verified. The built-in profile is called bluecoat-appliance-certificate and references the appliance certificate on your SG appliance; you can create additional profiles.

87

Volume 5: Advanced Networking

Note:

Authenticating the SG appliance and authenticating the SG appliance server name are two different procedures that require two different certificates. For information on authenticating server names, refer to Volume 4: Securing the Blue Coat SG Appliance.

Appliance Certificates and Device Authentication Profiles In the Blue Coat implementation of device authentication, both an appliance certificate and a device authentication profile that references the appliance certificate keyring are required for device authentication to be successful. Each device to be authenticated must have an appliance certificate and a profile that references that certificate. Note that device authentication does not take effect unless the profile is enabled; for example, if you use WAN optimization, you enable the profile on the Configuration > App. Delivery Network > General > Device Security tab.

About SG Appliance Certificates SG appliances come with a cryptographic key that allows the system to be authenticated as an SG appliance when an appliance certificate is obtained. An appliance certificate is an X.509 certificate that contains the hardware serial number of a specific SG device as the CommonName (CN) in the subject field. This certificate then can be used to authenticate the SG appliance whose hardware serial number is listed in the certificate. Information from the presented certificate is extracted and used as the device ID. Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance certificates. The root certificate for the Blue Coat CA is automatically trusted by SGOS for device authentication. These Blue Coat-signed certificates contain no authorization information and are valid for five years. You can provide your own device authentication certificates for the SG appliances on your network if you prefer not to use the Blue Coat CA.

About Device Authentication Profiles A device authentication profile contains the information related to device authentication: ❐

The name of the keyring that contains the private key and certificate this device uses to authenticate itself. The default is appliance-key. (For information on private and public keys, refer to Volume 4: Securing the Blue Coat SG Appliance.)

❐

The name of the CA Certificate List (CCL) that contains the names of certificates of CAs trusted by this profile. If another device offers a valid certificate signed by an authority in this list, the certificate is accepted. The default is appliance-ccl.

❐

Verification of the peer certificate. When the SG appliance is participating in device authentication as an SSL client, the peer certificate verification option controls whether the server certificate is validated against the CCL. If verification is disabled, the CCL is ignored. When the SG appliance is participating in device authentication as an SSL server, the peer certificate verification option controls whether to require a client certificate. If verification is disabled, no client certificate is obtained during the SSL handshake. The default is verify-peer-certificate enabled.

88

Chapter 6: Authenticating an SG Appliance

❐

Specification of how the device ID authorization data is extracted from the certificate. The default is $(subject.CN).

❐

SSL cipher settings. The default is AES256-SHA.

Each Blue Coat appliance has an automatically-constructed profile called bluecoatappliance-certificate that can be used for device-to-device authentication. This profile cannot be deleted or edited. If you cannot use the built-in profile because, for example, you require a different cipher suite or you are using your own appliance certificates, you must create a different profile, and have that profile reference the keyring that contains your certificate. Note: If you do not want to use peer verification, you can use the built-in passiveattack-detection-only profile in place of the bluecoat-appliance-certificate profile.

This profile uses a self-signed certificate and disables the verify-peer option, so that no authentication is done on the endpoints of the connection. The traffic is encrypted, but is vulnerable to active attacks. This profile can be used only when there is no threat of an active man-in-the-middle attack. Like the bluecoat-appliance certificate profile, the passive-attack-detection-only profile cannot be edited or deleted. If you create your own profile, it must contain the same kind of information that is contained in the Blue Coat profile. To create your own profile, skip to “Creating an Authentication Profile” on page 93.

Obtaining an SG Appliance Certificate In many cases, if you have Internet connectivity, an appliance certificate is automatically fetched by the SG appliance, and no human intervention is required. In other cases, if the Internet connection is delayed or if you do not have Internet access, you might have to manually initiate the process of obtaining an appliance certificate. How you obtain an appliance certificate depends upon your environment: ❐

If the device to be authenticated has Internet connectivity and can reach the Blue Coat CA server, continue with “Automatically Obtaining an Appliance Certificate” on page 90.

❐

If the device to be authenticated cannot reach the Blue Coat CA server, you must acquire the certificate manually; continue with “Manually Obtaining an Appliance Certificate” on page 90.

After the certificate is obtained, you must configure the device to use the profile you choose to use. For information on configuring the device to use the profile, see Chapter 2: "Configuring an Application Delivery Network". If you are configuring device authorization as well as authentication, configure device authentication before authorization. For more information on device authorization, see Chapter 2: "Configuring an Application Delivery Network".

89

Volume 5: Advanced Networking

Important:

Only the following SG platforms support appliance certificates:

❐

SG200 (manufactured after August 1, 2006)

❐

SG210

❐

SG510

❐

SG810

❐

SG8100

If you attempt to obtain an appliance certificate for other platforms (through Configuration > SSL > Appliance Certificates > Request appliance certificate), the request fails with the following error message: ❐

Request failed: Signing server reported error: No such serial number serial number.

If you receive this message, you cannot use Blue Coat appliance certificates, but you can create your own appliance certificates for use in a secure network. For more information, see “Obtaining a Non Blue Coat Appliance Certificate” on page 93.

Automatically Obtaining an Appliance Certificate The appliance attempts to get the certificate completely automatically (with no user intervention) if it can connect to the Blue Coat CA server at boot time or within about five minutes of being booted. If the appliance does not have a certificate (for example, it had one until you did a restore-defaults factory-defaults command) it attempts to get one on every boot. Once the appliance gets a certificate, that certificate is used until another restore-defaults factory-defaults command is issued. If Internet connectivity is established more than five minutes after the system is booted, you might need to complete the following steps. To automatically obtain an appliance certificate: 1.

Select Configuration > SSL > Appliance Certificates > Request Certificate.

2.

Click Request appliance certificate. The Blue Coat CA server does validation checks and signs the certificate. The certificate is automatically placed in the appliance-key keyring. Note that the appliance-key keyring cannot be backed up. The keyring is re-created if it is missing at boot time.

Manually Obtaining an Appliance Certificate Complete the following steps to obtain an appliance certificate manually. The overview of the procedure is to: ❐

Generate a appliance certificate signing request and send it to the Blue Coat CA server for verification and signature.

❐

Import the signed certificate into the SG appliance.

To generate a CSR: 1.

Select Configuration > SSL > Appliance Certificates > Request Certificate.

2.

Select Create CSR.

90

Chapter 6: Authenticating an SG Appliance

3.

Copy the certificate request, including the certificate request signature. Be sure to include the “Begin Certificate” and “End Certificate” statements, as well as the “Begin CSR Signature” and “End CSR Signature” statements.

4.

Click OK.

5.

Go to the Blue Coat CA Server Website at https://abrca.bluecoat.com/sign-manual/ index.html.

6.

Paste the CSR and signature into the CSR panel.

91

Volume 5: Advanced Networking

7.

Click Generate Cert. The signed certificate displays, and can be pasted into the appliance-key keyring. -----BEGIN CERTIFICATE----MIIF/jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV BAoTF0JsdWUgQ29hdCBTeXN0ZW1zLCBJbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs IEFCUkNBMRswGQYDVQQDExJhYnJjYS5ibHVlY29hdC5jb20xJDAiBgkqhkiG9w0B CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMjkyMDM5NDdaFw0xMjAx MjkyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcT CVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd BgNVBAsTFkJsdWUgQ29hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTCjA1MDUwNjAw OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG DNLCvf7SyKK5+SBCJU2iKwP5+EfiQ5JsScWJghtIo94EhdSC2zvBPQqWbZAJXN74 k/yM4w9ufjfo+G7xPYcMrGmwVBGnXbEhQkagc1FH2orINNY8SVDYVL1V4dRM+0at YpEiBmSxipmRSMZL4kqtAgMBAAGjggLGMIICwjAJBgNVHRMEAjAAMAsGA1UdDwQE AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr BgEEAfElAQECAQYLKwYBBAHxJQEBAgIGCysGAQQB8SUBAQIDMB0GA1UdDgQWBBSF NqC2ubTI7OT5j+KqCPGlSDO7DzCB6wYDVR0jBIHjMIHggBSwEYwcq1N6G1ZhpcXn OTIu8fNe1aGBvKSBuTCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju aWExEjAQBgNVBAcTCVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3Rl bXMsIEluYy4xGTAXBgNVBAsTEEJsdWUgQ29hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AYmx1ZWNv YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB hj1odHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9jZ2ktYmluL2RldmljZS1hdXRo ZW50aWNhdGlvbi9vY3NwMEIGCCsGAQUFBzAChjZodHRwOi8vYWJyY2EuYmx1ZWNv YXQuY29tL2RldmljZS1hdXRoZW50aWNhdGlvbi9jYS5jZ2kwSAYDVR0fBEEwPzA9 oDugOYY3aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj YXRpb24vQ1JMLmNybDBfBgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRjBEBggrBgEF BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X d2/Qw7NiVsnqOlAy913QZlieFfVATJnCeSrH+M9B/2XtnRxVT0/ZWrf4GbsdYqTF hc9jR/IwKu6kZq32Dqo8qFU5OzbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK OeB2bYcjWtMvTvr50iDOV69BEQz+VXos8QiZmRHLVnebQSjl3bi1w3VjBw31tCmc clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq r23/+BsZlYKAeVMq3PEmxaA2zLzO+jf79a8ZvIKrF27nNuTN7NhFL/V6pWNE1o9A rbs= -----END CERTIFICATE-----

To import a certificate onto the SG appliance: 1.

Copy the certificate to your clipboard. Be sure to include the “Begin Certificate” and “End Certificate” statements.

2.

Select Configuration > SSL > Keyrings.

3.

Select the keyring that is used for device authentication. The keyring used by the bluecoat-appliance-certificate profile is the appliance-key keyring.

4.

Click Edit/View in the Keyrings tab.

92

Chapter 6: Authenticating an SG Appliance

5.

In the Certificate panel, click Import.

6.

Paste the certificate you copied into the dialog box. Click OK. The certificate should display in the SSL Certificates Pane, associated with the keyring you selected earlier.

Obtaining a Non Blue Coat Appliance Certificate If you run your own certificate signing authority for device authentication, complete the following steps: 1.

Create a keyring for the appliance's certificate. For information on creating a keyring, refer to Volume 4: Securing the Blue Coat SG Appliance.

2.

Generate the certificate signing request and get it signed. For information on creating a CSR, refer to Volume 4: Securing the Blue Coat SG Appliance. Note:

You cannot put a Blue Coat appliance certificate into a keyring you create yourself. 3.

Create a CA certificate list.For information on creating a CCL, refer to Volume 4: Securing the Blue Coat SG Appliance a.

Import the CA's root certificate.

b.

Add the certificate to the CCL.

4.

Create a device authentication profile. (To create a profile, see “Appliance Certificates and Device Authentication Profiles” on page 88.)

5.

Associate the profile with the keyring and CCL. The keyring and CCL must already exist. Adjust other parameters, including authorization data extractor (if the certificate is to be used for authorization), as needed.

Configure each application that uses device authentication to reference the newly created profile, and set up its whitelist. To associate the device with the profile, see Chapter 2: "Configuring an Application Delivery Network".

Creating an Authentication Profile An authentication profile only needs to be created if you cannot use the built-in bluecoatappliance-certificate profile without modification; note that the bluecoat-appliancecertificate profile cannot be deleted or edited. Additional profiles with different settings can be created; for example, if you require a different cipher setting than what the bluecoat-appliance-certificate profile uses, you can create a profile with the different cipher suite. To create a new authentication profile: 1.

Select Configuration > SSL > Device Authentication > Profiles.

2.

Click New.

93

Volume 5: Advanced Networking

3.

Name: Give the profile a meaningful name. The only valid characters are

alphanumeric, the underscore, and hyphen, and the first character must be a letter. 4.

Keyring: From the drop-down list, select the keyring you want to use for device

authentication. Note: You must create a new keyring for device authentication if you do not use the appliance-key keyring. The keyrings shipped with the Blue Coat SG are dedicated to

other purposes. For information on creating a new keyring, refer to Volume 4: Securing the Blue Coat SG Appliance. 5.

CCL: From the drop-down list, select the CA Certificate List you want to use.

6.

Device ID extractor: The field describes how device ID information is extracted from a presented certificate. The string contains references to the attributes of the subject or issuer in the form $(subject.attr[.n]) or $(issuer.attr[.n]), where attr is the short-form name of the attribute and n is the ordinal instance of that attribute, counting from 1 when the subject is in LDAP (RFC 2253) order. If n is omitted, it is assumed to be 1.

The default is $(subject.CN); many other subject attributes are recognized, among them OU, O, L, ST, C, and DC. 7.

Verify peer: This setting determines whether peer certificates are verified against the CCL or whether client certificates are required.

8.

Selected cipher suites: If you want to use a different cipher suite, click Edit cipher suites.

94

Chapter 6: Authenticating an SG Appliance

9.

Select the cipher suite or suites you want to use. Click Add to add the cipher suite to the list of selected cipher suites. Cipher suites that you do not want to use should be removed from the selected list.

10. Click OK when done. 11. Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Manage Device Authentication ❐

To enter configuration mode: SGOS#(config) ssl

❐

The following device-authentication commands are available: SGOS#(config ssl) create device-authentication-profile profile_name keyring_ID SGOS#(config ssl) edit device-authentication-profile test SGOS#(config device-auth test) cipher-suite cipher-suite SGOS#(config device-auth test) ccl ccl_name SGOS#(config device-auth test) device-id device_ID SGOS#(config device-auth test) exit SGOS#(config device-auth test) keyring-id keyring_ID SGOS#(config device-auth test) verify-peer [enable | disable] SGOS#(config device-auth test) view SGOS#(config ssl) request-appliance-certificate SGOS#(config ssl) view appliance-certificate-request SGOS#(config ssl) view device-authentication-profile

95

Volume 5: Advanced Networking

96

Chapter 7: 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, refer to Volume 1: Getting Started. Note: If you use the Pass-Through adapter for transparent proxy, you must create a software bridge rather than configuring failover. For information on using the PassThrough adapter, refer to Volume 1: Getting Started.

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

“About Failover”

❐

“Configuring Failover” on page 98

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 advertisement interval is included in protocol messages and is learned by the slaves.

❐

A virtual router identifier (VRID) is not used.

❐

Virtual MAC addresses are not used.

❐

MD5 is used for authentication at the application level.

Masters are elected, based on the following factors: ❐

If the failover mechanism is configured for a physical IP address, the machine owning the physical address have the highest priority. This is not configurable.

❐

If a machine is configured as a master using a virtual IP address, the master has a priority that is higher than the slaves.

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

97

Volume 5: Advanced Networking

Configuring Failover Before you begin, ensure that software bridges already exist. For information on configuring bridges, refer to Volume 1: Getting Started. You also must decide which machine is the master and which machines are the slaves, and whether you want to configure explicit proxy or transparent proxy network. When configuring the group, the master and all the systems in the group must have exactly the same failover configuration except for priority, which is used to determine the rank of the slave machines. If no priority is set, a default priority of 100 is used. If two appliances have equal priority, the one with the highest physical address ranks higher. Note: Configuring failover on an Application Data Network (ADN) is similar to configuring failover on other appliances, with the exception that you add a server subnet on multiple boxes instead of just one.

To configure failover: 1.

Select Configuration > Network > Advanced > Failover.

2.

Click New.

3f

3a

3b 3c 3d 3e

3.

Fill in the fields as appropriate: a.

Create a group using either a new IP address or an existing IP address. If the group has already been created, you cannot change the new IP address without deleting the group and starting over.

b.

Multicast address refers to a Class D IP address that is used for multicast. It is

not a virtual IP address.

98

Chapter 7: Configuring Failover

Note: Class D IP addresses (224 to 239) 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.

c.

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. (Optional) Master identifies the system with the highest priority (the priority value is greyed out).

4.

d.

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

e.

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

f.

Select enabled.

g.

Click OK.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Failover ❐

To enter configuration mode: SGOS#(config) failover

❐

The following subcommands are available: SGOS#(config failover) create group_address SGOS#(config failover) edit group_address SGOS#(config failover group_address) multicast-address multicast_address SGOS#(config failover group_address) master SGOS#(config failover group_address) priority number SGOS#(config failover group_address) interval seconds SGOS#(config failover group_address) secret secret -orSGOS#(config failover group_address) encrypted-secret encrypted_secret SGOS#(config failover group_address) enable

Viewing Failover Statistics At any time, you can view statistics for any failover group you have configured on your system. To view failover status: 1.

Select Statistics > System > Failover.

99

Volume 5: Advanced Networking

2.

From the drop-down list, select the group to view.

The information displayed includes the multicast address, the local address, the state, and any flags, where V indicates the group name is a virtual IP address, R indicates the group name is a physical IP address, and M indicates this machine can be configured to be the master if it is available.

100

Chapter 8: Configuring the Upstream Network Environment

To fill requests, the SG appliance must interact with both the local network and with the upstream network environment. This chapter includes the following sections: ❐

Section A: "Overview" on page 102

❐

Section B: "About Forwarding" on page 103

❐

Section C: "Configuring Forwarding" on page 106

❐

Section D: "Using Forwarding Directives to Create an Installable List" on page 114

101

Volume 5: Advanced Networking Section A: Overview

Section A: Overview To control upstream interaction, the SG appliance supports: ❐

The SG appliance forwarding system—Allows you to define the hosts and groups of hosts to which client requests can be redirected. Those hosts can be servers or proxies. Rules to redirect requests are set up in policy.

❐

SOCKS gateways—SOCKS servers provide application-level firewall protection for an enterprise. The SOCKS protocol provides a generic way to proxy HTTP and other protocols. For information on configuring SOCKS gateways, see Chapter 13: "SOCKS Gateway Configuration" on page 183.

❐

ICP—ICP handles ICP queries from other caching devices looking for cached data. The SG appliance also can use ICP. For information on configuring ICP, see Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 121.

102

Chapter 8: Configuring the Upstream Network Environment

Section B: About Forwarding

Section B: About Forwarding Forwarding allows you to redirect requests to IP addresses other than those specified in the URL. Forwarding also allows you to organize how the Web traffic flows around the network. Forwarding does not affect the URL that appears in the request. It only affects the IP address of the upstream device a request is sent to. The SG appliance forwarding system consists of forwarding, upstream SOCKS gateways, load balancing, host affinity, health checks, and ICP. The SG appliance forwarding system determines the upstream address where a request is sent, and is tied in with all the protocol agents, including HTTP, HTTPS, streaming, and FTP, and the network configuration. The combination of forwarding and the policy engine allows traffic management and flexible configuration. Note: The SG appliance forwarding system directly supports the forwarding of HTTP, HTTPS, FTP, Windows Media, RTSP, Telnet, and TCP tunnels.

About Load Balancing Load balancing is a way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host. Load-balancing methods include round robin, which selects the next system in the list, or least connections, which selects the system with the least number of connections among the selected group. You can configure load balancing two ways: ❐

For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that host's load-balancing method (round robin, least connections, or none) is applied to those IP addresses. The method is either explicitly set for that host or taken from the configurable global default settings.

❐

For groups: Load balancing for groups works exactly the same as load balancing for hosts with multiple IP addresses—the forwarding system collects all of the IP addresses for all of the hosts in the group and load balances over that set using the method that is specified. You can also use a domain or URL hash, as well.

About Host Affinity Host affinity is the attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important. For example, a Web site uses shopping carts to allow customers to purchase items. The site might use load balancing with a group of Web servers working in parallel, but only one server in the group has information on a single user. If the user connections are sent to a different server, the server has no previous information on the user and might start over. Host affinity forces the user’s connections to return to the same server until the user is idle. After a configurable period of inactivity, the host affinity times out and the association of multiple connections with that single user is lost. Host affinity allows you to use the following options: ❐

Use the client IP address to determine which group member was last used. When the same client IP sends another request, the host makes the connection is made to that group member.

103

Volume 5: Advanced Networking Section B: About Forwarding ❐

Place a cookie in the response to the client. When the client makes further requests, the cookie data is used to determine which group member the client last used. The host makes the connection to that group member.

❐

For HTTPS, extract the SSL session ID name from the connection information. The host uses the session ID in place of a cookie or client IP address to determine which group member was last used. The host makes the connection to that group member.

Using Load Balancing with Host Affinity By default, if you use load balancing, each connection is treated independently. The connection is made to whichever member of the load-balancing group that the loadbalancing algorithm selects. The load balancing responsibility is to distribute the connections among group members to share the load. If host affinity is configured, the system checks host affinity first to see if the request comes from a known client. If this is a first connection, the load-balancing algorithm selects the group member to make the connection. Host affinity records the result of the load balancing and uses it if that client connects again. Host affinity does not make a connection to a host that health checks report is down; instead, if host affinity breaks, the load-balancing algorithm selects a group member that is healthy and re-establishes affinity on that working group member. Note: You might find it necessary to disable caching for traffic sent to the load-balanced

groups (or hosts if DNS hides a group under one entry) to prevent copies of customized Web pages being served to a different user. It is not always necessary to disable caching; for example, load balancing can be used without host affinity or without disabling caching to distribute load among several proxies. However, if caching is enabled for traffic going through load balancing, retrieval of updated content by the cache is done according to load balancing rules; the cache does not support host affinity and ignores it if enabled. Host affinity methods are discussed in the table below. Table 8-1. Host Affinity Methods Setting

Description

Global Default

Use the default setting for all forwarding hosts on the system.

None

Disables host affinity.

Client IP Address

Uses the client IP address to determine which group member was last used.

Accelerator Cookie

Inserts a cookie into the response to the client.

HTTP

SSL

Other (TCP Tunnel or Telnet)

104

Chapter 8: Configuring the Upstream Network Environment

Section B: About Forwarding Table 8-1. Host Affinity Methods (Continued) SSL Session ID

Used in place of a cookie or client IP address. Extracts the SSL session ID name from the connection information.

105

Volume 5: Advanced Networking Section C: Configuring Forwarding

Section C: Configuring Forwarding High-level steps to configure forwarding are: ❐

Create the forwarding hosts and groups, including parameters such as protocol agent and port.

❐

Set Load Balancing and Host Affinity values.

Creating Forwarding Hosts and Groups You can create as many hosts, groups, or members of a group as you need. To create groups, see “To create forwarding groups:” on page 107 To create forwarding hosts: 1.

Click Configuration > Forwarding > Forwarding Hosts.

2.

Click New to create a new forwarding host.

.

3.

Enter the fields as follows: a.

In the Alias field, enter the name of the host as it will be named in policy.

106

Chapter 8: Configuring the Upstream Network Environment

Section C: Configuring Forwarding

The host alias cannot be a CPL keyword, such as no, default, or forward. Note:

b.

In the Host field, give the name of the host domain or its IP address.

c.

Define the host type by selecting either the Proxy or Server radio button. Terminated HTTPS, TCP tunnels, and Telnet can be forwarded to a server only; they cannot be forwarded to a proxy. Server specifies to use the relative path for URLs in the HTTP header because the next hop is a Web server, not a proxy server. The default is Proxy.

d.

Select the port you want to use. Port 80 is the default for HTTP. The rest of the host types default to their appropriate Internet default port, except TCP tunnels, which have no default and for which a port must be specified.

e.

In the Load Balancing and Host Affinity section, select a load-balancing method from the drop-down list. Global default (configured on the Configuration > Forwarding > Global Defaults tab), sets the default for all forwarding hosts on the system. You can also specify the load-balancing method for this system: Least Connections or Round Robin, or you can disable load balancing by selecting None.

f.

In the Host affinity methods drop-down list (see Table 8-1, “Host Affinity Methods,” on page 104), select the method you want to use.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

To create forwarding groups: An existing host can belong to one or more groups as needed. It can only belong once to a single group. 1.

Click Configuration > Forwarding > Forwarding Groups.

2.

Click New to create a new forwarding group.The Add Forwarding Group dialog displays, showing the available aliases.

107

Volume 5: Advanced Networking Section C: Configuring Forwarding

3.

Enter a name for the new group in the Alias field. The group alias cannot be a CPL keyword, such as no, default, or forward. Note:

4.

To add members to a group, highlight the hosts you want grouped and click Add. You can also create a group with no members.

5.

In the Load Balancing and Host Affinity section, select the load-balancing method from the drop-down list. Global default (configured on the Configuration > Forwarding > Global Defaults tab), are the defaults that were set for all forwarding groups on the system. To specify the load-balancing method for this system, select Least Connections, Round Robin, Domain Hash, URL Hash, or you can disable load balancing by selecting None.

6.

In the Host affinity methods drop-down list (see Table 8-1, “Host Affinity Methods,” on page 104), select the method you want to use.

7.

Click OK.

8.

Click Apply to commit the changes to the SG appliance.

108

Chapter 8: Configuring the Upstream Network Environment

Section C: Configuring Forwarding

Configuring Global Forwarding Defaults The global defaults apply to all forwarding hosts and groups unless the settings are specifically overwritten during host or group configuration. To configure global defaults: 1.

Select Configuration > Forwarding > Global Defaults.

2.

Configure General Settings as follows: a.

Determine how you want connections to behave if no forwarding is available. Note that failing open is an insecure option. The default is to fail closed. This setting can be overridden by policy, if it exists.

b.

Decide if you want to Use forwarding for administrative downloads. The default is to use forwarding in this case. This option determines whether forwarding is applied to requests generated for administrative reasons on the system, such as downloading policy files or new system images. If the option is on, meaning that forwarding is applied, you can control the forwarding in policy as needed. This option also affects the use of SOCKS gateways.

c.

3.

Enter the Timeout for integrated hosts interval: An integrated host is an Origin Content Server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts policy property, ages out after being idle for the specified time. The default is 60 minutes.

Configure Global Load Balancing and Host Affinity Settings.

109

Volume 5: Advanced Networking Section C: Configuring Forwarding a.

4.

Load-balancing methods: •

Forwarding hosts: Specify the load-balancing method for all forwarding hosts unless their configuration specifically overwrites the global settings. You can choose Least Connections or Round Robin, or you can disable load balancing by selecting None. Round Robin is specified by default.

•

Forwarding groups: Specify the load-balancing method for all forwarding groups unless their configuration specifically overwrites the global settings. You can choose to do a domain hash or a URL hash. You can also select Least Connections or Round Robin, or disable load balancing by selecting None. Round Robin is specified by default.

b.

In the Global Host Affinity methods (see Table 8-1, “Host Affinity Methods,” on page 104), select the method you want to use.

c.

Enter the Host Affinity Timeout interval, the amount of time a user's IP address, SSL ID, or cookie remains valid after its most recent use. The default is 30 minutes, meaning that the IP address, SSL ID or cookie must be used once every 30 minutes to restart the timeout period.

Click Apply to commit the changes to the SG appliance.

Configuring the Default Sequence The default sequence is the default forwarding rule, used for all requests lacking policy instructions. Failover is supported if the sequence (only one is allowed) has more than one member. Note: Creating the default sequence through the CLI is a legacy feature. You can set up sequences by using policy alone. The default sequence (if present) is applied only if no applicable forwarding gesture is in policy.

For information on using VPM, refer to Volume 6: VPM and Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy Language Guide. For information on using forwarding with policy, see Appendix B: "Using Policy to Manage Forwarding" on page 263. The default sequence (and any sequence specified in policy) works by allowing healthy hosts to take over for an unhealthy host (one that is failing its DNS Resolution or its health check). If more than one member is in the sequence, the sequence specifies the order of failover, with the second host taking over for the first host, the third taking over for the second, and so on. Note: In normal circumstances, only the first member of the sequence is ever used. Traffic is forwarded to the first member of the sequence until it fails, then traffic is sent to the second member of list until it fails or the first member becomes healthy again, and so on.

110

Chapter 8: Configuring the Upstream Network Environment

Section C: Configuring Forwarding To create a default sequence: 1.

Select Configuration > Forwarding > Default Sequence. The available aliases are displayed.

2.

To select an alias, highlight it and click Add. Note: Any host or group in the default sequence is considered in use by policy. As a result, if you try to delete a host or group while it is in the default sequence, you receive an error message. You must remove the host/group from the sequence first, then delete the host or group.

3.

Click Promote or Demote to change the order of the hosts in the failover sequence.

4.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure Forwarding ❐

To enter configuration mode for forwarding: SGOS#(config) forwarding SGOS#(config forwarding)

❐

The following subcommands are available: SGOS#(config) forwarding SGOS#(config forwarding) create host host_alias host_name [http[=port] [https[=port]] [ftp[=port]] [mms[=port]] [rtsp[=port]] [tcp[=port]] [telnet[=port]] [ssl-verify-server[=yes | =no]] [group=group_name] [server | proxy] SGOS#(config forwarding) create group group_name SGOS#(config forwarding) delete all SGOS#(config forwarding) delete group group_name SGOS#(config forwarding) delete host host_alias SGOS#(config forwarding) download-via-forwarding {disable | enable}

111

Volume 5: Advanced Networking Section C: Configuring Forwarding SGOS#(config forwarding) edit host_alias SGOS#(config forwarding host_alias) exit SGOS#(config forwarding host_alias) {ftp | http | https | mms | rtsp | tcp | telnet} [port]} SGOS#(config forwarding host_alias) host hostname SGOS#(config forwarding host_alias) host-affinity http {default | none | client-ip-address | accelerator-cookie} SGOS#(config forwarding host_alias) host-affinity ssl {default | none | client-ip-address | accelerator-cookie | ssl-session-id} SGOS#(config forwarding host_alias) host-affinity other {default | none | client-ip-address} SGOS#(config forwarding host_alias) load-balance method {default | least-connections | none | round-robin} SGOS#(config forwarding host_alias) no {ftp | http | https | mms | rtsp | ssl-verify-server | tcp | telnet} SGOS#(config forwarding host_alias) proxy | server SGOS#(config forwarding host_alias) ssl-verify-server SGOS#(config forwarding host_alias) view SGOS#(config forwarding) edit group_alias SGOS#(config forwarding group_alias) {add | remove} host_alias SGOS#(config forwarding group_alias) exit SGOS#(config forwarding group_alias) host-affinity http {default | none | client-ip-address | accelerator-cookie} SGOS#(config forwarding group_alias) host-affinity ssl {default | none | client-ip-address | accelerator-cookie | ssl-session-id} SGOS#(config forwarding group_alias) host-affinity other {default | none | client-ip-address} SGOS#(config forwarding group_alias) load-balance {default | domain-hash | least-connections | none | round-robin | url-hash} SGOS#(config forwarding group_alias) view SGOS#(config forwarding) exit SGOS#(config forwarding) failure-mode {closed | open} SGOS#(config forwarding) host-affinity http {default | none | clientip-address | accelerator-cookie} host_or_group_alias SGOS#(config forwarding) host-affinity http {none | client-ip-address | accelerator-cookie} SGOS#(config forwarding) host-affinity ssl {default | none | clientip-address | accelerator-cookie | ssl-session-id} host_or_group_alias SGOS#(config forwarding) host-affinity ssl {none | client-ip-address | accelerator-cookie | ssl-session-id} SGOS#(config forwarding) host-affinity other {default | none | clientip-address} host_or_group_alias SGOS#(config forwarding) host-affinity other {none | client-ipaddress} SGOS#(config forwarding) host-affinity timeout minutes

112

Chapter 8: Configuring the Upstream Network Environment

Section C: Configuring Forwarding SGOS#(config forwarding) integrated-host-timeout minutes SGOS#(config forwarding) load-balance group {default | none | domainhash | url-hash | round-robin | least-connections} group_alias SGOS#(config forwarding) load-balance group {none | domain-hash | urlhash | round-robin | least-connections} SGOS#(config forwarding) load-balance host {default | none | roundrobin | least-connections} host_alias SGOS#(config forwarding) load-balance host {none | round-robin | least-connections} SGOS#(config forwarding) no path SGOS#(config forwarding) path url SGOS#(config forwarding) sequence add host_or_group_alias SGOS#(config forwarding) sequence clear SGOS#(config forwarding) sequence demote host_or_group_alias SGOS#(config forwarding) sequence promote host_or_group_alias SGOS#(config forwarding) sequence remove host_or_group_alias SGOS#(config forwarding) view

Statistics To view forwarding statistics, select Statistics > Advanced > Forwarding.

113

Volume 5: Advanced Networking Section D: Using Forwarding Directives to Create an Installable List

Section D: Using Forwarding Directives to Create an Installable List You can use directives instead of using the Management Console or CLI to configure forwarding. Note that the Management Console offers the easiest method of configuration. Using directives, you can: ❐

Create the forwarding hosts and groups

❐

Provide load balancing and host affinity

Table 8-2. Forwarding Directives Directive

Meaning

See

fwd_fail

Determines whether the forwarding host should fail open or fail closed if an operation does not succeed.

“Setting Fail Open/Closed and Host Timeout Values” on page 116.

fwd_host

Creates a forwarding host and sets configuration parameters for it, including protocols and ports.

"Creating Forwarding Hosts" on page 115.

group

Creates a forwarding group and identifies members of the group.

"Creating Forwarding Groups Using Directives" on page 116.

host_affinity

Directs multiple connections by a single user to the same group member.

"Configuring Host Affinity Directives" on page 117.

integrated_host_ timeout

Manages an origin content server that has been added to the health check list. The host ages out after being idle for the specified time.

"Setting Fail Open/Closed and Host Timeout Values" on page 116.

load_balance

Manages the load among forwarding hosts in a group, or among multiple IP addresses of a host.

"Configuring Load-Balancing Directives" on page 117.

sequence

Sets the default sequence to the space separated list of one or more forwarding host and group aliases. (The default sequence is the default forwarding rule, used for all requests lacking policy instructions.)

"Creating a Default Sequence" on page 118.

Creating Forwarding Host and Group Directives A forwarding host directive creates a host along with all its parameters. You can include a group that the forwarding host belongs to. A group directive creates a group and identifies group members. For more information on group directives, skip to “Creating Forwarding Groups Using Directives” on page 116.

114

Chapter 8: Configuring the Upstream Network Environment

Section D: Using Forwarding Directives to Create an Installable List

Creating Forwarding Hosts To create a forwarding host, choose the protocols you want to use and add the forwarding host to a group, enter the following into your installable list. Create a fwd_host directive for each forwarding host you want to create. fwd_host host_alias hostname [http[=port]] [https[=port]] [ftp[=port]] [mms[=port]] [rtsp[=port]] [tcp=port] [telnet[=port]] [ssl-verifyserver[=yes | =no]] [group=group_name [server | proxy]] :

Table 8-3. Commands to Create Forwarding Host and Group Directives host_alias

This is the alias for use in policy. Define a meaningful name.

hostname

The name of the host domain, such www.bluecoat.com, or its IP address.

http

=port

At least one protocol must be selected

https

HTTPS and Telnet cannot be used with a proxy.

ftp

Note that HTTPS refers to terminated HTTPS, so it is used only for a server.

mms rtsp telnet tcp

=port

If you choose to add a TCP protocol, a TCP port must be specified. TCP protocols are not allowed if the host is a proxy.

ssl-verifyserver

=yes | =no

Sets SSL to specify that the SG appliance checks the CA certificate of the upstream server. The default for ssl-verify-server is yes. This can be overridden in the SSL layer in policy. To disable this feature, you must specify ssl-verifyserver=no in the installable list or CLI. In other words, you can configure ssl-verify-server=yes in three ways: do nothing (yes is the default), specify ssl-verify-server=no, or specify ssl-verifyserver=yes.

group

=group_name

Specifies the group (or server farm or group of proxies) to which this host belongs. If this is the first mention of the group group_name then that group is automatically created with this host as its first member. The SG appliance uses load balancing to evenly distribute forwarding requests to the origin servers or group of proxies.

server | proxy

server specifies to use the relative path for URLs in the HTTP header because the next hop is a Web server, not a proxy server. The default is proxy.

Example fwd_host www.bluecoat1.com 10.25.36.48 ssl-verify-server=no group=bluecoat

115

Volume 5: Advanced Networking Section D: Using Forwarding Directives to Create an Installable List

Creating Forwarding Groups Using Directives The forwarding groups directive has the following syntax: group group_name host_alias_1 host_alias_2...

where group_name is the name of the group, and host_alias_1, host_alias_2, and so forth are the forwarding hosts you are assigning to the forwarding group. Forwarding host parameters are configured through the forwarding host directives.

Setting Special Parameters After you configure the forwarding hosts and groups, you might need to set other special parameters to fine tune the hosts. You can configure the following settings: ❐

“Setting Fail Open/Closed and Host Timeout Values” .

❐

“Configuring Load-Balancing Directives” on page 117.

❐

“Configuring Host Affinity Directives” on page 117.

Setting Fail Open/Closed and Host Timeout Values Using directives, you can determine if the forwarding host fails open or closed, if an operation does not succeed, and the interval it takes for integrated hosts to be aged out. An integrated host is an Origin Content Server (OCS) that has been added to the health check list. If the policy property integrate_new_hosts applies to a forwarding request as a result of matching the integrate_new_hosts property., the SG appliance makes a note of each OCS and starts health checking to help future accesses to those systems. If the host is idle for the interval you specify, it is aged out. Sixty minutes is the default interval. The syntax is: fwd_fail {open | closed} integrated_host_timeout minutes Table 8-4. Commands to Set Fail Open/Closed and Host Timeout Values fwd_fail

{open | closed}

Determines whether the forwarding host should fail open or fail closed if an operation does not succeed. Fail open is a security risk, and fail closed is the default if no setting is specified. This setting can be overridden by policy, (using the forward.fail_open(yes|no) property).

integrated_host_timeout

minutes

An OCS that has been added to the health check list is called an integrated host. The host ages out after being idle for the specified time.

Examples fwd_fail open integrated_host_timeout 90

116

Chapter 8: Configuring the Upstream Network Environment

Section D: Using Forwarding Directives to Create an Installable List

Configuring Load-Balancing Directives Load balancing shares the load among a set of IP addresses, whether a group or a host with multiple IP addresses. The syntax is: load_balance group {none | domain-hash | url-hash | round-robin | least-connections} [group_alias] load_balance host {none | round-robin | least-connections} [host_alias] Table 8-5.

Load Balancing Directives

Command

Suboptions

Description

load_balance group

{none | domain-hash | urlhash | round-robin | least-connections} [group_alias]

If you use group for load balancing, you can set the suboption to none or choose another method. If you do not specify a group, the settings apply as the default for all groups.

load_balance host

{none | round-robin | least-connections} [host_alias]

If you use host for load balancing, you can set the suboption to none or choose another method. If you do not specify a host, the settings apply as the default for all hosts.

Example load_balance host least_connections

Configuring Host Affinity Directives Host affinity is the attempt to direct multiple connections by a single user to the same group member. The syntax is: host_affinity http {none | client-ip-address | accelerator-cookie} [host_or_group_alias] host_affinity ssl {none | client-ip-address | accelerator-cookie | ssl-session-id} [host_or_group_alias] host_affinity other {none | client-ip-address} [host_or_group_alias] host_affinity timeout minutes Table 8-6. Commands to Configure Host Affinity Directives Command

Suboption

Description

host_affinity http

{accelerator-cookie | client-ip-address | none} [host_or_group_alias]

Determines which HTTP host-affinity method to use (accelerator cookie or client-ip-address), or you can specify none. If you do not specify a host or group, the settings apply as the default for all hosts or groups.

117

Volume 5: Advanced Networking Section D: Using Forwarding Directives to Create an Installable List Table 8-6. Commands to Configure Host Affinity Directives (Continued) Command

Suboption

Description

host_affinity ssl

{accelerator-cookie | client-ip-address | none | ssl-session-id} [host_or_group_alias]

Determines which SSL host-affinity method to use (accelerator cookie, client-ip-address, or sslsession-id), or you can specify none. If you do not specify a host or group, the settings apply as the default for all hosts or groups.

host_affinity other

{none | client-ipaddress} [host_or_group_alias]

Determines whether client-ipaddress mode is used with TCP tunnels or Telnet.

host_affinity timeout

minutes

Determines how long a user's IP address, SSL ID, or cookie remains valid when idle

Example host_affinity ssl_method 10.25.36.48 host_affinity timeout 5

Creating a Default Sequence The default sequence is the default forwarding rule, used for all requests lacking policy instructions. Failover is supported if the sequence (only one is allowed) has more than one member. Note: The default sequence is completely overridden by policy.

A default failover sequence works by allowing healthy hosts to take over for an unhealthy host (one that is failing its DNS resolution or its health check). The sequence specifies the order of failover, with the second host taking over for the first host, the third taking over for the second, and so on). If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. This configuration is generally created and managed through policy. If no forwarding policy applies, you can create a default sequence through the CLI. This single default sequence consists of a single default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. The syntax is: sequence alias_list

where alias_list is a space-separated list of one or more forwarding host and group aliases. Example sequence bluecoat

118

Chapter 8: Configuring the Upstream Network Environment

Section D: Using Forwarding Directives to Create an Installable List

Creating a Forwarding Installable List You can create and install the forwarding installable list using one of the following methods: ❐

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

❐

A local file, created on your system; the SG appliance can browse to the file and install it.

❐

A remote URL, where you placed an already-created file on an FTP or HTTP server to be downloaded to the SG appliance.

❐

CLI inline command.

When the Forwarding Installable List is installed, it replaces the forwarding configuration on the SG appliance. The configuration remains in effect until overwritten by another installable list; the configuration can be modified or overwritten using CLI commands. Note: During the time that a forwarding installable list is being compiled and installed, forwarding might not be available. Any transactions that come into the SG appliance during this time might not be forwarded properly.

Installation of forwarding installable lists should be done outside peak traffic times. To create a forwarding installable list: 1.

Select Configuration > Forwarding > Install Forwarding File.

2.

From the drop-down list, select the method to use to install the forwarding installable list; click Install. Note: A message is written to the event log when you install a list through the SGOS software.

•

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

•

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

•

Text Editor:

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

119

Volume 5: Advanced Networking Section D: Using Forwarding Directives to Create an Installable List

Note: The Management Console text editor is a way to enter an installable list

for forwarding. It is not a way to enter CLI commands. The directives are understood only by the installable list parser for forwarding. 3.

Click Apply.

Note: You can create forwarding settings using the CLI #inline forwarding command.

You can use any of the forwarding directives. For more information on using inline commands, refer toVolume 11: Command Line Reference. To delete forwarding settings on the SG appliance: From the (config) prompt, enter the following commands to delete a host, a group, or all hosts and groups from the forwarding configuration: SGOS#(config) forwarding SGOS#(config forwarding) delete {all | group group_name | host host_alias} Note: : Any host or group in the default sequence (or the DRTR service configuration) is considered in use by policy. As a result, if you try to delete a host or group while it is in the default sequence or DRTR service configuration, you will receive an error message. You must remove the host/group from the sequence or service first, then delete.

120

Chapter 9: Internet Caching Protocol (ICP) Configuration

ICP is a communication protocol for caches. It allows a cache (not necessarily a SG appliance) to query other caches for an object, without actually requesting the object. By using ICP, the cache can determine if the object is available from a neighboring cache, and which cache provides the fastest response. Note: The SG appliance (assuming ICP is configured) does ICP queries only if no forwarding host or SOCKS gateway is identified as an upstream target. If ICP is used by the appliance, it prompts other cache devices for the item, and upon a positive response re-directs the upstream request to that cache device instead of the content origin server.

Only use ICP if you have ICP hosts available or to have the SG appliance support requests from other ICP hosts. By default, the ICP protocol requires the requesting host to wait up to two seconds for all ICP hosts to respond to the request for an object (the time is configurable). If the ICP service is configured and running, the service is used if no forwarding or SOCKS gateway target was specified. In other words, the policy rule icp(yes) is the default, assuming that the ICP service is available. You can disable ICP with the policy rule icp(no) to control ICP queries for requests.

Configuring ICP An ICP hierarchy is comprised of a group of caches, with defined parent and sibling relationships. A cache parent is one that can return the object if it is in the cache, or request the object from the source on behalf of the requester if the object is not in the cache. A cache sibling is a device that can only return the object if it is in the cache. One cache acting as a parent can also act as a sibling to other cache devices. ❐

When an object is not cached, the cache device sends an ICP query to its neighbors (parents and siblings) to see if any of its peers holds the object.

❐

Each neighbor that holds the requested object returns an ICP_HIT reply.

❐

Each neighbor that does not hold the object returns an ICP_MISS reply.

Based on the responses, the cache can determine where to request the object: from one of its neighbors or from the source. If an ICP_HIT reply is received, the request is sent to the host that returned the first reply. If no ICP_HIT reply is received, the request is forwarded to the first parent that replied. If no parents respond or are configured, the request is made directly to the source.

Using ICP Configuration Directives to Create an Installable List To configure ICP you must create an installable list and load it on the SG appliance. The ICP protocol contains a number of directives, commands used to create a list that can be installed on the SG appliance. For information on installing the file itself, see “Creating an ICP Installable List” on page 125. The ICP configuration includes directives that:

121

Volume 5: Advanced Networking

❐

Name the ICP hosts

❐

Restrict ICP access to only these hosts

Available directives are listed in Table 9-1. Table 9-1. ICP Directives Directive

Meaning

Where used

icp_host

The icp_host directive describes cache peers in the hierarchy. There should be one entry for each SG appliance you want to use.

“Naming the IP Hosts” on

icp_access_ domain

icp_access_ip

The icp_access_domain directive is used to control which ICP queries are accepted. The icp_access_domain directive requires a reverse DNS lookup of each ICP query to validate the IP address.

Names the ICP hosts. See page 123. Restricts access. See

“Restricting Access” on page 123.

The icp_access_ip directive works like the icp_access_domain command, except that you can specify an IP address and subnet mask rather than a domain.

See “Restricting Access” on page 123.

icp_port

The icp_port directive sets the port the SG appliance uses to listen for ICP requests. The default port is 3130. If you set the port to 0, ICP is disabled.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

neighbor_timeout

The neighbor_timeout directive sets the number of seconds the SG appliance waits for ICP replies. When the cache device sends an ICP request, it waits for all hosts to reply or for the neighbor_timeout to expire. The default timeout is two seconds.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

icp_failcount

The icp_failcount directive sets the number of consecutive failures the cache device can receive before considering the ICP host as failed. By default, the ICP failure count is set to 20. Each time a request fails, the failure count is incremented. When a request succeeds, the failure count is reset to zero.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

http_failcount

The http_failcount directive sets the number of consecutive failures the cache device can receive before considering the HTTP host as failed. By default, the HTTP failure count is set to five. The failure count increments each time a request fails. When a request succeeds, the failure count is reset to zero. When an HTTP host fails, the cache device waits five minutes before attempting to use it again as a forwarding target. If the next request fails, the cache device continues to wait five minutes between attempts until the cache becomes available.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

host_fail_notify

The host_fail_notify directive tells the cache device to send event notification e-mail when a connect fails persistently.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

host_recover_ notify

The host_recover_notify directive tells the cache device to send event notification e-mail when a failed host recovers.

Connects to other ICP hosts. See “Connecting to Other ICP Hosts” on page 124.

Restricts access.

122

Chapter 9: Internet Caching Protocol (ICP) Configuration

Naming the IP Hosts The icp_host directive describes peers in the hierarchy. One entry is required for each SG appliance you want to use. icp_host hostname peertype HTTPport ICPport [default | backup | feeder] Table 9-2. ICP_host Directive Command

Suboptions

hostname peertype

Description The host name of the SG appliance.

{parent | sibling}

Relationship of the SG appliance to the cache device you are configuring.

HTTPport

TCP port where the SG appliance accepts HTTP requests. The common HTTP port is 80 or 8080.

ICPport

UDP port where the SG appliance accepts ICP requests. The common ICP port is 3130.

default

If specified, designates a SG host parent to be the default ICP parent. If no ICP reply is received, all requests are forwarded to the default parent.

backup

If specified, designates the cache device host parent to be the backup default ICP parent. If the default parent is not available, the cache device uses the backup default parent.

feeder

If specified, designates the SG host sibling as a feeder-type host, using ICP request loops to populate the appliance.

The following are sample icp_host directives that can be entered into the ICP configuration: ; Define icp_host icp_host icp_host icp_host icp_host

ICP parent and sibling hosts. cm1.bluecoat.com parent 8080 3130 default cm2.bluecoat.com sibling 8080 3130 cm3.bluecoat.com sibling 8080 3130 cm4.bluecoat.com sibling 8080 3130 cm5.bluecoat.com parent 8080 3130

Restricting Access You can restrict access to SG appliances acting as caches by other ICP hosts using the icp_access_domain and icp_access_ip directives. By default, when ICP is configured, all ICP hosts are allowed access. You should deny access to all domains other than the ICP hosts you want to use.

icp_access_domain Directive The icp_access_domain directive defines which hosts can request objects from the Web cache using ICP. The default action is to allow all requests. When you use icp_access_domain, each ICP query requires a reverse DNS lookup to validate the IP address. Depending on the number of ICP requests, these lookups can consume SG appliance resources. icp_access_domain {allow | deny} domain

123

Volume 5: Advanced Networking

Table 9-3. ICP_Access_Domain Directive Directive Option

Description

allow | deny

Allows or denies ICP queries from neighbors that match the domain specification.

domain

The domain to match. All ICP queries from neighbors that match the specified domain are handled by the host. The special domain of all defines the default action when there is no domain match.

The following are sample icp_access_domain directives to be entered into the ICP configuration: ; allow ICP access to this Blue Coat Systems SG Appliance from the ; bluecoat.com domain icp_access_domain allow bluecoat.com icp_access_domain deny all ; the deny all option should always be specified to deny all other ; domains

icp_access_ip Directive The icp_access_ip directive works like the icp_access_domain command, except that you can specify an IP address and subnet mask rather than a domain. The following describes the parameters for the icp_access_ip command: icp_access_ip {allow | deny} subnet mask Table 9-4. ICAP_Access_IP Directive Directive Option

Description

allow | deny

Allow or deny ICP queries from neighbors that match the address specification.

address/subnet mask

The address and subnet mask to match. All ICP queries that match the specified address are handled by the ICP host. The special address of 0.0.0.0 defines the default action when there is no address match.

The following are sample icp_access_ip directives to be entered into the ICP configuration: ; allow ICP access to this Blue Coat Systems SG Appliance from the local subnet icp_access_ip allow 192.168.10.0/255.255.255.0 icp_access_ip deny 10.25.36.47 ; the deny all option should always be specified to deny all other domains

Connecting to Other ICP Hosts In addition to the ICP directives described in the sections above, you can specify the following directives in the ICP configuration: icp_port 0 neighbor_timeout 2 icp_failcount 20 http_failcount 5 host_fail_notify on host_recover_notify on

124

Chapter 9: Internet Caching Protocol (ICP) Configuration

Table 9-5. Connecting to Other ICP Hosts Directive

Description

icp_port

The default port is 3130. If you set the port to 0, ICP is disabled.

neighbor_timeout

When the cache device sends an ICP request, it waits for all hosts to reply or for the neighbor_timeout to expire. The default timeout is two seconds.

http_failcount

By default, the HTTP failure count is set to five. The failure count increments each time a request fails. When a request succeeds, the failure count resets to zero. When an HTTP host fails, the cache device waits five minutes before attempting to use it again as a forwarding target.

icp_failcount

By default, the ICP failure count is set to 20. Each time a request fails, the failure count is incremented. When a request succeeds, the failure count is reset to zero.

host_fail_notify

on tells the cache to send event notification e-mail when a connect fails persistently; off disables this setting.

host_recover_ notify

on tells the cache to send event notification e-mail when a failed host recovers; off disables this setting.

Creating an ICP Installable List You can create the ICP installable list using one of the following methods: ❐

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

❐

Local file, installed on your system; the SG appliance can browse to the file and install it.

❐

A remote URL, where you place an already-created file on an FTP or HTTP server to be downloaded to the SG appliance.

❐

The CLI inline command.

When the ICP installable list is created and installed, it overwrites any ICP settings on the SG appliance. To create an ICP installable list: 1.

Select Configuration > Forwarding > ICP.

2.

From the drop-down list, select the method you want to use to install the ICP configuration; then click Install. •

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

•

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

125

Volume 5: Advanced Networking

•

Text Editor:

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

Click Apply to commit the changes to the SG appliance.

Note: You can create ICP settings using the CLI inline commands.

For more information on using inline commands, refer to Volume 11: Command Line Reference.

Enabling ICP Before ICP can be used in the SG environment: ❐

ICP must be running

❐

At least one forwarding host must be configured

ICP can be enabled or disabled through the policy rule icp.The default is icp(yes). You can disable ICP with the policy rule icp(no) to control ICP queries for requests.

126

Chapter 10: Using RIP

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

“Installing RIP Configuration Files” on page 127

❐

“Configuring Advertising Default Routes” on page 128

❐

“RIP Commands” on page 129

❐

“RIP Parameters” on page 130

❐

“SG-Specific RIP Parameters” on page 131

❐

“Using Passwords with RIP” on page 131

Installing RIP Configuration Files No RIP configuration file is shipped with the appliance. For commands that can be entered into the RIP configuration file, see “RIP Commands” on page 129. After creating an RIP configuration file, install it using one of the following methods: ❐

Using the 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 SG appliance 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 SG appliance.

❐

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

❐

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

To install an RIP configuration file: Note: When entering RIP settings that affect current settings (for example, when switching from ripv1 to ripv2), disable RIP before you change the settings; re-enable RIP when you have finished.

1.

Select Configuration > Network > Routing > RIP.

2.

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

127

Volume 5: Advanced Networking

3.

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

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

•

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

•

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

4.

Click Apply to commit the changes to the SG appliance.

5.

Select Enable RIP.

6.

Click Apply.

Related CLI Syntax to Configure RIP SGOS#(config) rip {disable | enable} ❐

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

❐

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

Configuring Advertising Default Routes Default routes advertisements are treated the same as the static default routes; that is, the default route load balancing schemes also apply to the default routes from RIP. By default, RIP ignores the default routes advertisement. You can change the default from disable to enable and set the preference group and weight through the CLI only. To enable and configure advertising default gateway routes: 1.

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

Where group_number defaults to 1, and weight_number defaults to 100, the same as the static default route set by the ip-default-gateway command.

128

Chapter 10: Using RIP

2.

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

RIP Commands You can place any of the commands below into a Routing Information Protocol (RIP) configuration text file. You cannot edit a RIP file through the command line, but you can overwrite a RIP file using the inline rip-settings command. Once the file is complete, place it on an HTTP or FTP server accessible to the SG appliance and download it.

net net Nname[/mask] gateway Gname metric Value {passive | active | external} Table 10-1. net Commands Parameters

Description

Nname

Name of the destination network. It can be a symbolic network name, or an Internet address specified in dot notation.

/mask

Optional number between 1 and 32 indicating the netmask associated with Nname.

Gname

Name or address of the gateway to which RIP responses should be forwarded.

Value

The hop count to the destination host or network. A net Nname/32 specification is equivalent to the host Hname command.

passive | active | external

Specifies whether the gateway is treated as passive or active, or whether the gateway is external to the scope of the RIP protocol.

host host Hname gateway Gname metric Value {passive | active | external} Table 10-2. host Commands Parameters

Description

Hname

Name of the destination network. It can be a symbolic network name, or an Internet address specified in dot notation.

Gname

Name or address of the gateway to which RIP responses should be forwarded. It can be a symbolic network name, or an Internet address specified in dot notation.

Value

The hop count to the destination host or network. A net Nname/32 specification is equivalent to the host Hname command.

passive | active | external

Specifies whether the gateway is treated as passive or active, or whether the gateway is external to the scope of the RIP protocol.

129

Volume 5: Advanced Networking

RIP Parameters Lines that do not start with net or host commands must consist of one or more of the following parameter settings, separated by commas or blank spaces: Table 10-3. RIP Parameters Parameters

Description

if=[0|1|2|3]

Specifies that the other parameters on the line apply to the interface numbered 0,1,2, or 3 in SGOS terms.

passwd=XXX

Specifies an RIPv2 password included on all RIPv2 responses sent and checked on all RIPv2 responses received. The password must not contain any blanks, tab characters, commas or ‘#’ characters.

no_ag

Turns off aggregation of subnets in RIPv1 and RIPv2 responses.

no_super_ag

Turns off aggregation of networks into supernets in RIPv2 responses.

passive

Marks the interface to not be advertised in updates sent through other interfaces, and turns off all RIP and router discovery through the interface.

no_rip

Disables all RIP processing on the specified interface.

no_ripv1_in

Causes RIPv1 received responses to be ignored.

no_ripv2_in

Causes RIPv2 received responses to be ignored.

ripv2_out

Turns off RIPv1 output and causes RIPv2 advertisements to be multicast when possible.

ripv2

Is equivalent to no_ripv1_in and no_ripv1_out. This parameter is set by default.

no_rdisc

Disables the Internet Router Discovery Protocol. This parameter is set by default.

no_solicit

Disables the transmission of Router Discovery Solicitations.

send_solicit

Specifies that Router Discovery solicitations should be sent, even on point-to-point links, which by default only listen to Router Discovery messages.

no_rdisc_adv

Disables the transmission of Router Discovery Advertisements.

rdisc_adv

Specifies that Router Discovery Advertisements should be sent, even on point-topoint links, which by default only listen to Router Discovery messages.

bcast_rdisc

Specifies that Router Discovery packets should be broadcast instead of multicast.

rdisc_pref=N

Sets the preference in Router Discovery Advertisements to the integer N.

rdisc_interval=N

Sets the nominal interval with which Router Discovery Advertisements are transmitted to N seconds and their lifetime to 3*N.

trust_gateway=rname

Causes RIP packets from that router and other routers named in other trust_gateway keywords to be accept, and packets from other routers to be ignored.

redirect_ok

Causes RIP to allow ICMP Redirect messages when the system is acting as a router and forwarding packets. Otherwise, ICMP Redirect messages are overridden.

130

Chapter 10: Using RIP

SG-Specific RIP Parameters The following RIP parameters are unique to SG configurations: Table 10-4. SG-Specific RIP Parameters Parameters

Description

supply_routing_info

-s option: Supplying this option forces routers to supply routing information whether it is acting as an Internetwork router or not. This is the default if multiple network interfaces are present or if a point-to-point link is in use.

-oradvertise_routes

-g option: This flag is used on Internetwork routers to offer a route to the `default' destination. This is typically used on a gateway to the Internet, or on a gateway that uses another routing protocol whose routes are not reported to other local routers. -h option: Suppress_extra_host_routes advertise_host_route -m option: Advertise_host_route on multi-homed hosts -A option: Ignore_authentication // no_supply_ routing_info

-q option: opposite of -s.

no_rip_out

Disables the transmission of all RIP packets. This setting is the default.

no_ripv1_out

Disables the transmission of RIPv1 packets.

no_ripv2_out

Disables the transmission of RIPv2 packets.

rip_out

Enables the transmission of RIPv1 packets.

ripv1_out

Enables the transmission of RIPv1 packets.

rdisc

Enables the transmission of Router Discovery Advertisements.

ripv1

Causes RIPv1 packets to be sent.

ripv1_in

Causes RIPv1 received responses to be handled.

Using Passwords with RIP The first password specified for an interface is used for output. All passwords pertaining to an interface are accepted on input. For example, with the following settings: if=0 passwd=aaa if=1 passwd=bbb passwd=ccc

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. Interface 1 accepts passwords bbb and ccc, and transmits using password bbb. The other interfaces accept and transmit the password ccc.

131

Volume 5: Advanced Networking

132

Chapter 11: Configuring the SG Appliance as a Session Monitor

You can configure the SGOS software to monitor RADIUS accounting messages and to maintain a session table based on the information in these messages. The session table can then be used for logging or authentication. You can also, optionally, configure multiple appliances to act as a session monitor cluster. The session table is then replicated to all members of the cluster. Once configured and enabled, the session monitor maintains a session table that records which sessions are currently active and the user identity for each session.

Configuring the Session Monitor Three steps are required to configure the session monitor: ❐

Configure the RADIUS accounting protocol parameters for the session monitor.

❐

(Optional) Configure the session monitor cluster.

❐

Configure the session monitor parameters.

Configuring the RADIUS Accounting Protocol Parameters The configuration commands to create the RADIUS accounting protocol parameters can only be done through the CLI. If you are using session-monitor clustering, the commands must be invoked on each system in an already-existing failover group. (For information on configuring a failover group, see Chapter 7: "Configuring Failover"on page 97.) To configure the RADIUS accounting protocol parameters: ❐

To enter configuration mode: SGOS#(config) session-monitor

❐

The following subcommands are available: SGOS#(config session-monitor) radius acct-listen-port port_number SGOS#(config session-monitor) radius authentication {enable | disable} SGOS#(config session-monitor) radius encrypted-shared-secret encrypted_secret SGOS#(config session-monitor) radius no encrypted-shared-secret SGOS#(config session-monitor) radius response {enable | disable} SGOS#(config session-monitor) radius shared-secret plaintext_secret

133

Volume 5: Advanced Networking

t

Table 11-1. Session Monitor Accounting Command Descriptions Command

Option

Description

radius acct-listen-port

port_number

The port number where the SG appliance listens for accounting messages

radius authentication

enable | disable

Enable or disable (the default) the authentication of RADIUS messages using the shared secret. Note that the shared secret must be configured before authentication is enabled.

radius encrypted-sharedsecret

encrypted_shared_ secret

Specify the shared secret (in encrypted form) used for RADIUS protocol authentication. The secret is decrypted using the configuration-passwords-key.

radius no shared-secret

Clears the shared secret used for RADIUS protocol authentication.

radius response

enable | disable

Enable (the default) or disable generation of RADIUS responses.

radius shared-secret

plaintext_secret

Specify the shared secret used for RAIDUS protocol in plaintext.

Configuring a Session Monitor Cluster Configuring a session monitor cluster is optional. When a session monitor cluster is enabled, the session table is replicated to all members of the cluster. The cluster members are the SG appliances that are configured as part of the failover group referenced in the session monitor cluster configuration. The failover group must be configured before the session monitor cluster. (For information on configuring a failover group, see Chapter 7: "Configuring Failover"on page 97.) To replicate the session table to all the members of a failover group, you can use the following commands. Note: When using a session monitor cluster, the RADIUS client must be configured to

send the RADIUS accounting messages to the failover group's virtual IP address. Proxy traffic can be routed to any of the machines in the cluster. Note: Each member of the failover group must configured with the cluster commands to maintain the session table for RADIUS accounting messages.

To configure session monitor cluster parameters: SGOS#(config) session-monitor ❐

The following subcommands are available: SGOS#(config session-monitor) cluster {enable | disable} SGOS#(config session-monitor) cluster group-address IP_address SGOS#(config session-monitor) cluster port port_number SGOS#(config session-monitor) cluster grace-period seconds SGOS#(config session-monitor) cluster synchronization-delay seconds

134

Chapter 11: Configuring the SG Appliance as a Session Monitor

Table 11-2. Session Monitor Cluster Command Descriptions Command

Option

Description

cluster

enable | disable

Enable or disable (the default) clustering on a failover group. The group address must be set before the cluster can be enabled.

cluster group-address | no group-address

IP_address

Set or clear (the default) the failover group IP address. This must be an existing failover group address.

cluster port

port_number

Set the TCP/IP port for the session replication control. The default is 55555.

cluster synchronization-delay

seconds

Set the maximum time to wait for session table synchronization. The default is zero; the range is from 0 to 2 ^31 -1 seconds. During this time evaluation of $(session.username) is delayed, so proxy traffic might also be delayed.

cluster grace-period

seconds

Set the time to keep session transactions in memory while waiting for slave logins. This can be set to allow session table synchronization to occur after the synchronization-delay has expired. The default is 30 seconds; the range is 0 to 2^31-1 seconds.

Configuring the Session Monitor The session monitor commands set up session monitoring behavior. If using sessionmonitor clustering, these commands must be invoked on all systems in the failover group. To configure the session monitor: 1.

At the (config) prompt: SGOS#(config) session-monitor SGOS#(config session-monitor) disable | enable SGOS#(config session-monitor) max-entries integer SGOS#(config session-monitor) timeout minutes

Table 11-3. Session Monitor Configuration Command Descriptions Command

Option

enable | disable

Description Enable or disable (the default) session monitoring

max_entries

integer

The maximum number of entries in the session table. The default is 500,000; the range is from 1 to 2,000,000. If the table reaches the maximum, additional START messages are ignored.

timeout

minutes

The amount of time before a session table entry assumes a STOP message has been sent. The default is 120 minutes; the range is from 0 to 65535 minutes. Zero indicates no timeout.

135

Volume 5: Advanced Networking

2.

(Optional) To view the session-monitor configuration, you can either use the session-monitor view command or the config show session-monitor command. SGOS#(config) show session-monitor General: Status: enabled Entry timeout: 120 minutes Maximum entries: 500000 Cluster support: enabled Cluster port: 55555 Cluster group address: 10.9.17.159 Synchronization delay: 0 Synchronization grace period: 30 Accounting protocol: radius Radius accounting: Listen ports: Accounting: 1813 Responses: Enabled Authentication: Enabled Shared secret: ************

Creating the CPL Be aware that the examples below are just part of a comprehensive authentication policy. By themselves, they are not adequate. Note: Refer to Volume 10: Content Policy Language Guide for details about CPL and how transactions trigger the evaluation of policy file layers. ❐

In this example, the SG appliance is using the session table maintained by the session monitor for authentication. allow authenticate(session)

where session is a policy substitution realm that uses $(session.username) in building the username. (For information on creating a Policy Substitution realm, refer to Volume 4: Securing the Blue Coat SG Appliance.)

Notes ❐

The session table is stored entirely in memory. The amount of memory needed is roughly 40MB for 500,000 users.

❐

The session table is kept in memory. If the system goes down, the contents of the session table are lost. However, if the system is a member of a failover cluster, the current contents of the session table can be obtained from another machine in the cluster. The only situation in which the session table is entirely lost is if all machines in the cluster go down at the same time.

❐

The session replication protocol replicates session information only; configuration information is not exchanged. That means that each SG appliance must be properly configured for session monitoring.

❐

The session replication protocol is not secured. The failover group should be on a physically secure network to communicate with each other.

136

Chapter 11: Configuring the SG Appliance as a Session Monitor

❐

The session monitor requires sufficient memory and at least 100Mb-per-second network links among the cluster to manage large numbers of active sessions.

❐

The username in the session table is obtained from the Calling-Station-ID attribute in the RADIUS accounting message and can be a maximum of 19 bytes.

137

Volume 5: Advanced Networking

138

Chapter 12: Configuring and Using the SG Client

The Blue Coat SG Client enables users to benefit from accelerated application delivery directly to their desktops. This allows mobile users or users in small branch offices— where it might not be cost-justifiable to deploy an acceleration gateway—to enjoy improved networked application access. This chapter includes the following topics: ❐

“Overview” on page 140

❐

“About ADN Features” on page 143

❐

“Configuring Client Settings” on page 146

❐

“Configuring the Client Manager” on page 151

❐

“Configuring the SG Client from the Command Line” on page 155

❐

“Making the SG Client Software Available to Users” on page 158

❐

“Using the SG Client” on page 171

❐

“Troubleshooting Tips for Administrators” on page 171

❐

“Licensing” on page 181

139

Volume 5: Advanced Networking

Overview This section discusses the concepts you need to know to implement the SG Client in your enterprise: ❐

“About the Terminology” on page 140

❐

“SG Client Features and Benefits” on page 141

❐

“About SG Client Deployment” on page 142

About the Terminology The following figure illustrates the terminology discussed in this chapter:

Figure 12-1. Sample SG Client Deployment

The SG Client typically connects to a concentrator, which is a Blue Coat SG appliance that is usually located in a data center. The SG Client connection over the Internet is assumed to use Virtual Private Networking (VPN). The concentrator receives inbound Application Delivery Network (ADN) tunnels from the SG Client and serves as a front end for data center resources for which it provides acceleration services. To use the SG Client, you must configure SG appliances for the following roles: ❐

Concentrator An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

❐

Client Manager An SG appliance that provides the SG Client software to users, and maintains the software and the client configuration on all clients in the ADN network. You configure the Client Manager as discussed in “Configuring the Client Manager” on page 151.

140

Chapter 12: Configuring and Using the SG Client

❐

ADN manager and backup manager (not shown in the preceding figure) Every ADN network must have an ADN manager, which is responsible for publishing the routing table to SG Clients (and to other SG appliances). Although not required, Blue Coat recommends configuring an ADN backup manager, which takes over for the ADN manager in the event it becomes unavailable. Note:

The Client Manager can be any appliance in the ADN network, including a concentrator, the ADN manager, or backup manager. For example, the Client Manager could also be the ADN manager but that is not a requirement. To configure an ADN manager and backup manager, see “Defining the ADN Manager” on page 21.

SG Client Features and Benefits The following table discusses features and benefits of the SG Client: Table 12-1. SG Client Features and Benefits Feature

Benefit

Common Internet File System (CIFS) acceleration

The SG Client significantly enhances Wide Area Network (WAN) file service delivery, improving user productivity by implementing the following: • Client object caching, which enables clients to get previously obtained data from cache rather than across the WAN. • CIFS protocol optimization, which improves performance by consolidating data forwarded across the WAN.

Connect from anywhere

The SG Client enables any user to remotely connect to an ADN network.

ADN optimization

Uses gzip compression to improve bandwidth utilization for TCP applications.

Centralized management and distribution

Administrators use a particular SG appliance designated as the Client Manager to download to clients SG Client software and configuration updates.

Load balancing and failover

Enables you to efficiently use your ADN network as a robust infrastructure for clients.

Client statistics

Provides users with real-time performance data.

141

Volume 5: Advanced Networking

About SG Client Deployment The SG Client software is deployed in two basic steps: the administrator configures the Client Manager to install and configure the client, then the user (or administrator) installs the client. After installation, the client connects to an appliance in the ADN network. This section discusses administrator configuration tasks and client installation tasks.

Administrator Configuration Tasks The administrator: 1.

Sets up an ADN manager, backup manager, and configures the ADN network.

2.

Configures an SG appliance as the Client Manager, as discussed in “Configuring the Client Manager” on page 151. The Client Manager must be licensed, as discussed in “Licensing” on page 181. The Client Manager is the device from which users download the SG Client software, software updates, and configuration updates.

3.

Sets up the SG Client configuration (such as CIFS and ADN), as discussed in “Configuring General Client Settings” on page 146.

4.

Provides the SG Client software to users in one of the ways discussed in this chapter. For more information, see “Making the SG Client Software Available to Users” on page 158.

Client Installation Tasks The SG Client deployment process can be summarized as follows: 1.

A user obtains the SG Client software from the Client Manager or preinstalled by an administrator some other way. Note:

Installation methods are discussed in “Making the SG Client Software Available to Users” on page 158. To download the SG Client software from the Client Manager, the user must go to a URL provided by the administrator. When the user connects to the Client Manager using the URL, the user runs a setup application (SGClientSetup.exe) that in turn downloads and starts a Microsoft Installer (SGClientSetup.msi). Note:

To run SGClientSetup.exe and SGClientSetup.msi, the user must be in the Administrators group on the machine.

142

Chapter 12: Configuring and Using the SG Client

2.

After installing the SG Client software, the user must reboot the machine.

3.

Periodically, the SG Client polls the Client Manager for changes to the SG Client software and configuration.

Software and Hardware Requirements For information about software and hardware requirements, see the SG Client Release Notes.

About ADN Features This section discusses the ADN features supported by the SG Client in this release: ❐

“General ADN Feature Support” on page 143

❐

“Configuring Listening Modes” on page 144

❐

“About Internet Gateways” on page 146

General ADN Feature Support The SG Client supports the following ADN features: ❐

Gzip compression, which improves bandwidth utilization

❐

CIFS protocol optimization and CIFS caching on the client

❐

Load balancing and failover The SG Client makes two types of connections in the ADN network: the routing connection and the ADN tunneling connection. The routing connection obtains the routing table from the ADN manager or backup manager, and the tunneling connection transfers data to the ADN network. The SG Client first attempts to connect to the primary ADN manager to get routing information; if it is not available, the client attempts to connect to the backup ADN manager. If the backup ADN manager is also not available, the connection goes directly to its destination as a result of fail open, which is discussed in the next bullet. Assuming there is more than one active SG appliance in the ADN network, the SG Client randomly picks an appliance from the list of appliances in the routing table and iterates through the list until it finds an active appliance. Randomly choosing an appliance—assuming there is more than one—achieves simple load balancing. Iterating through the list of appliances achieves failover. If no appliance is active, the connection goes directly to its destination as a result of fail open, which is discussed next.

❐

Fail open, which means that if all client connections to concentrators fail for any reason, the client opens a connection directly to a destination, such as a CIFS server. Client connections that do not go through a concentrator are not accelerated and remain unaccelerated as long as the connection is open (that is, until the connection is closed by the application). After a concentrator becomes available, new connections are accelerated.

143

Volume 5: Advanced Networking

Configuring Listening Modes To use the SG Client in your ADN network, you must configure options for Manager Listening Mode and Tunnel Listening Mode as discussed in this section. The SG Client does not publish routes (instead, it gets routes from the ADN Manager), and it uses plain communications only. The options you select for Manager Listening Mode and Tunnel Listening Mode must be compatible with the SG Client. This section discusses the following topics: ❐

“Manager Listening Mode” on page 144

❐

“Tunnel Listening Mode” on page 145

❐

“Secure Outbound Mode” on page 145 Note: To select options for either Manager Listening Mode or Tunnel Listening Mode, you must have previously set up a device authentication profile on the SG appliance. For more information about device authentication profiles, see “About Device Authentication Profiles” on page 88.

Manager Listening Mode Manager Listening Mode determines the way routes are published in the ADN network: using the Plain Manager Port (non-secure communication) or the Secure Manager Port (secure communication), or both. Select Manager Listening Mode options on the ADN manager and backup manager only. Manager Listening Mode options are not available on other SG appliances. For more information about setting the Plain Manager Port and the Secure Manager Port, see “Defining the ADN Manager” on page 21. As discussed in “Securing Connections” on page 34, the following options are available: ❐

Secure Only

This option means that only SG appliances using secure connections can publish routes. However, because only the secure listener is active, you cannot select this option if you have SG Clients in your ADN network because SG Clients use only plain connections. ❐

Plain Read-Only

Select this option if all SG appliances in the ADN network use SGOS version 5.1.4 or later—where all appliances support secure routing, and you have chosen to utilize secure routing on those SG appliances. This option means that SG appliances that use secure connections can publish routes. Devices that use plain communications can get routes but cannot publish routes. Note:

Select this option only if all appliances in the ADN network run SGOS version 5.1.4 or later.

144

Chapter 12: Configuring and Using the SG Client

❐

Plain Only

Select this option in cases where you do not secure any ADN connections between SG appliances. This option means that only SG appliances that use plain connections can publish routes. ❐

Both

Select this option if you use the SG Client in your ADN network and some appliances in the network are not capable of using secure connections (for example, some appliances run SGOS version 5.1.3 or earlier). This option means that SG appliances that use either secure or plain connections can publish routes.

Tunnel Listening Mode Tunnel Listening Mode determines the type of incoming tunnel communications this SG appliance accepts: using the Plain Tunnel Port (non-secure communications) or the Secure Tunnel Port (secure communications). Select options for Tunnel Listening Mode on every concentrator to which you expect SG Clients to connect. For example, select a Tunnel Listening Mode option for the concentrator shown in Figure 12-1 on page 140. For more information about the Plain Tunnel Port and the Secure Tunnel Port, see “Securing Connections” on page 34. The following options are available: ❐

Secure Only

This option means this SG appliance accepts only secure tunneling connections. Because the SG Client uses only plain connections, you cannot select this option if you have SG Clients in your ADN network. ❐

Plain

Select this option to enable the SG Client to connect to the appliance in cases where you do not secure any ADN connections between SG appliances. This option means this SG appliance accepts only plain tunneling connections. ❐

Both

Select this option if you use the SG Client in your ADN network and some appliances in the network are not capable of accepting incoming secure tunneling connections (for example, some appliances run SGOS version 5.1.3 or earlier). This option means this SG appliance accepts both plain and secure tunneling connections.

Secure Outbound Mode The Secure Outbound Mode options have no impact on the SG Client because these options determine how SG appliances communicate with each other. For a tunneling connection to be established between two SG appliances, the initiating appliance’s secure outbound mode must be compatible with the tunnel listening mode of the receiving appliance.

145

Volume 5: Advanced Networking

About Internet Gateways The SG Client ignores Internet Gateway settings; however, if you want to route all SG Client traffic through a concentrator, you can configure the concentrator to publish all addresses, as discussed in “Managing Server Subnets and Enabling an Internet Gateway” on page 26.

Configuring Client Settings This section discusses how to configure the settings that affect SG Client configuration. Available settings include: ❐

General settings—Software update interval, TCP window size, and maximum percentage of client disk space to allocate for object caching. See the next section.

❐

CIFS settings—Disabling CIFS or enabling CIFS with options for write-back and directory cache time. See “Configuring Client CIFS Settings” on page 148.

❐

ADN settings—Primary and backup ADN manager IP addresses and port, excluded subnets, and included or excluded ports. See “Configuring Client ADN Settings” on page 149.

Configuring General Client Settings This section discusses how to configure the following client settings: ❐

SG Client software update interval

❐

TCP window size If you know the bandwidth and round-trip delay, the TCP window size you should use is approximately 2 * bandwidth * delay. For example, if the bandwidth of the link is 8 Mbits per second and the round-trip delay is 0.75 seconds: TCP window size = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes The setting in this example would be 1572864 bytes. This number goes up as bandwidth or delay increases, and goes down as they decrease. Because the bandwidth and delay for SG Client users can vary, Blue Coat recommends you test SG Client performance in a controlled environment before deciding on a TCP window size value to use in production.

❐

Maximum percentage of client disk space to use for object caching Regions of files that are read or written by the client are placed in the cache. Object caching applies to both read and write file activities. Note:

In this release, the object cache is not encrypted.

You can set the maximum percentage of total disk space (as opposed to available disk space) the SG Client allocates to the object cache. The SG Client always leaves at least 1GB of available disk space on the client machine’s system root volume.

146

Chapter 12: Configuring and Using the SG Client

Following is a summary of how object caching works on the client: a.

The SG Client starts.

b.

The user requests a cacheable object, such as a file.

c.

The SG Client allocates sufficient disk space on the system root volume to cache the object—up to the limit set by the administrator. In other words, if the client machine’s system root volume has 100GB of total space and the administrator configures the object cache to use a maximum of 10%, the SG Client allocates up to 10GB for the object cache. However, if the maximum cache size leaves less than 1GB of available disk space, the cache size is further limited. Continuing this example, if the client has only 9GB of available space, the maximum cache size is 8GB instead of 10GB.

d. If any single object (such as a file) exceeds the maximum cache size, that object is not cached. To continue the preceding example, if the maximum size of the object cache is 10GB, and the client requests a file that is 11GB in size, that file is not cached. e.

If the object cache is full, objects are expired from the cache based on a number of criteria, such as unopened files and oldest objects first.

To configure general client settings: 1.

Log in to the Management Console as an administrator.

2.

Select SG Client > Client Configuration.

3.

In the right pane, click the General tab.

4.

Enter the following information:

Table 12-2. Configuring General Client Settings Field

Description

Update interval

Enter the frequency, in minutes, for clients to check the Client Manager for updated SG Client software or configuration updates. The default is 120. Valid values are between 10–432000 (that is, 300 days).

TCP window size

Enter the number of bytes allowed before acknowledgement (the value must be between 8192 and 4194304). The default is 65536.

Maximum percentage of disk space to use for object caching

Maximum percentage of client disk space to use for caching objects, such as CIFS objects. Valid values are 1– 90; the default is 10. Note: The cache leaves at least 1GB available space on the system root volume. For more information, see “Configuring General Client Settings” on page 146.

5.

Click Apply to commit the changes to the SG appliance.

147

Volume 5: Advanced Networking

Configuring Client CIFS Settings This section discusses how to configure the following: ❐

Enable or disable CIFS acceleration

❐

Enable or disable write-back

❐

Set the directory cache time

To configure CIFS settings: 1.

Log in to the Management Console as an administrator.

2.

Select SG Client > Client Configuration.

3.

In the right pane, click the CIFS tab.

4.

Enter the following information:

Table 12-3. Configuring Client Settings for CIFS Item

Description

Enable CIFS acceleration check box

• Select the check box to enable CIFS acceleration for clients. • Clear the check box to disable CIFS acceleration. If you clear the check box, the other options on this tab page are unavailable. For more information about CIFS acceleration, see “SG Client Features and

Benefits” on page 141. Determines whether or not users can continue sending data to the appliance while the appliance is writing data on the back end.

Write back

• Select Full to enable write-back, which in turn makes the local SG Client proxy appear to the user as a file server; in other words, the local SG Client proxy constantly sends approval to the client and allows the client to send data while the back end takes advantage of the compressed TCP connection. • Select None to disable write-back. Disabling write-back can introduce substantial latency while clients send data to the appliance and wait for acknowledgement before sending more data. One reason to set this option to None is the risk of data loss if the link from the branch to the core server fails. There is no way to recover queued data if such a link failure occurs. Directory cache time field

5.

Number of seconds for directory listings to remain in the client’s cache.

Click Apply to commit the changes to the SG appliance.

148

Chapter 12: Configuring and Using the SG Client

Configuring Client ADN Settings This section discusses how to configure the following: ❐

❐

ADN manager settings: •

Primary and backup ADN manager IP addresses

•

ADN manager port

ADN rules settings: •

Excluded subnets Adds or removes subnets from the list of subnets not included in ADN tunnels. Assuming SG Clients can connect to an SG appliance that can optimize traffic to the destination address, this is the list of IP addresses and subnets that bypass ADN tunneling on the way to the destination.

•

Include and exclude ports Includes or excludes TCP ports in ADN tunnels. Assuming SG Clients can connect to an SG appliance that can optimize traffic to the destination address, this setting determines ports accelerated (or not accelerated) for clients. You can use either the excluded ports list or included ports list, but not both. The include and exclude ports list are advanced settings that limit the traffic that is accelerated by the ADN network. Because the ADN manager sets options for both its peers in the ADN network and for SG Clients, you can use the include or exclude ports list to fine-tune the way SG appliances interact with the SG Client. For example, if you know that SG Client traffic over particular ports is not compressible, you can put those ports in the exclude ports list. Blue Coat strongly recommends you test the include/exclude ports settings in a controlled environment before using them in production because improper settings can have an adverse impact on performance.

Configuring Client ADN Manager Settings To configure client ADN Manager settings: 1.

Log in to the Management Console as an administrator.

2.

Select SG Client > Client Configuration.

3.

In the right pane, click the ADN Manager tab.

149

Volume 5: Advanced Networking

4.

Enter the following information:

Table 12-4. Configuring Client Settings for ADN Manager Field

Description

ADN Manager

Enter the primary ADN manager’s IP address. The ADN manager tracks and advertises the routes to the appliances it knows about. The SG Client obtains the routing table from the ADN manager.

Backup Manager

Enter the backup ADN manager’s IP address. Configuring a backup ADN manager is optional but recommended. If the ADN manager becomes unavailable for any reason, the backup ADN manager takes over the task of advertising routes to all ADN nodes—including SG Clients. Enter the ADN manager plain listen port.

Port

5.

Click Apply to commit the changes to the SG appliance.

Configuring Client ADN Rules Settings This section discusses how to set ADN rules settings for clients, which consist of the list of excluded subnets, included ports, and excluded ports. To configure client ADN Manager settings: 1.

Log in to the Management Console as an administrator.

2.

Select SG Client > Client Configuration.

3.

In the right pane, click the ADN Rules tab.

4.

In the Excluded Subnets section, do one of the following: •

To add excluded subnets (in other words, to cause SG Client traffic from these subnets to bypass the ADN tunnel), click Add. In the Add IP/Subnet dialog, enter the following information and click OK when you are done: •

IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet in Classless Inter-Domain Routing (CIDR) notation (for example, 192.168.0.1/16).

•

Subnet Mask field: Use this field if you entered only an IP address in the

preceding field (in other words, if you used CIDR notation in the preceding field, you do not need to enter a value in this field). •

To remove excluded subnets, click the subnets to remove and click Remove. You are required to confirm the action.

•

To clear all excluded subnets (in other words, to cause SG Client traffic from all IP addresses and subnets to be tunneled), click Clear all. You are required to confirm the action.

150

Chapter 12: Configuring and Using the SG Client

5.

In the Ports section, enter the following information:

Table 12-5. Configuring Included or Excluded Ports Item

Description

Exclude

Client traffic from specified ports is not routed through the ADN tunnel. All other traffic is accelerated. Valid values: Comma-separated list of ports and port ranges (no spaces, separated by a dash character). Example: 22,88,443,993,995,1352,1494,1677, 3389,5900-5902

Include

Client traffic from specified ports is routed through the ADN tunnel and, therefore, accelerated. All other traffic bypasses the tunnel and is, therefore, not accelerated. Valid values: Comma-separated list of ports and port ranges (no spaces, separated by a dash character). Example: 80,139,445,8080-8088

Note: The include and exclude ports lists are advanced settings that limit the traffic that is accelerated by the ADN network. To cause all traffic to be accelerated by the ADN network, click either option and delete all the ports in the list.

6.

Click Apply to commit the changes to the SG appliance.

Configuring the Client Manager You must configure one SG appliance in your ADN network as the Client Manager, meaning it is responsible for providing the SG Client software, software updates, and client configuration to SG Clients. The Client Manager must be licensed as discussed in “Licensing” on page 181. Note: The Client Manager can be a different appliance than the ADN manager or the backup ADN manager. In other words, you can configure the ADN manager or the backup ADN manager as the Client Manager, but it is not required.

Setting an Appliance as the Client Manager This section discusses how to configure an appliance in the ADN network as the Client Manager. Before configuring the Client Manager, you must first specify an ADN manager as discussed in “Configuring Client ADN Manager Settings” on page 149. To set an SG appliance as the Client Manager: 1.

Log in to the Management Console as an administrator.

2.

Select SG Client > Client Manager.

3.

In the right pane, click the Client Manager tab.

4.

Select the Enable Client Manager check box.

151

Volume 5: Advanced Networking

5.

Enter or edit the following information: Note: Before you can enable an appliance to be the Client Manager, you must configure the ADN manager SG Clients will use. If you enable the Client Manager before you configure an ADN manager for clients, the following error displays when you attempt to apply the change: The ADN primary manager must be set prior to enabling the SG Client Manager. To configure the clients’ ADN manager, see “Configuring Client ADN Manager Settings” on page 149.

License information displays below the check box. For more information, see “Licensing” on page 181.

Table 12-6. Client Manager Section Item

Description

Host

Specify the host from which users get the SG Client software, configuration, and updates. Blue Coat recommends you specify a fully qualified host name, and not an unqualified (short) host name or IP address. If you use a fully qualified host name and the Client Manager’s IP address changes later, you need only to update DNS for the Client Manager’s new address and clients can continue to download the software and updates from the Client Manager. After you set this option, provide the appropriate URL to users in an e-mail or by some other means so they can download the SG Client software, configuration, and updates from that URL. You have the following options: • Use host from initial client request: (Recommended.) Select this option to enable clients to download the SG Client software, configuration, and updates from the host from which the clients originally obtained the software and configuration. This option is compatible with all methods of deploying the SG Client, including Windows Group Policy Object (GPO) and Microsoft Systems Management Server (SMS). For more information about these deployment options, see “Making the SG Client Software Available to Users” on page 158. • Use host: Select this option to download the SG Client software and configuration from the host name you specify. Enter a fully qualified host name or IP address only; do not preface it with http:// or https:// because downloads will fail. Use this option to migrate users from one Client Manager to another Client Manager. (Also see “Changing the Client Manager URL” on page 175.)

Port field

Enter the port on which the Client Manager listens for requests from clients. The default is 8084.

Keyring list

Select the keyring to use when clients connect to the Client Manager.

6.

Click Apply to commit the changes to the SG appliance.

152

Chapter 12: Configuring and Using the SG Client

After you apply the changes, the Client Components section displays a summary of the information you selected, as follows: Table 12-7. Client Components Section Item

Description

Client setup

Displays the URL from which users will download the SG Client setup application. The setup application (SGClientSetup.exe) downloads the Microsoft Installer (MSI)—named SGClientSetup.msi—to the client. If you want users to install the SG Client software from the Client Manager, provide this URL to them. To install the software this way, the user must have administrative privileges on the client machine.

Note: If you chose Use host from client request for Host as discussed in Table 12-6 on page 152, the URL displays as follows: https://host-from-client-request:8084/sgclient/ SGClientSetup.exe To download the SG Client using this URL, substitute the Client Manager’s host name or IP address for host-from-client-request. Client install MSI

Displays the URL from which SGClientSetup.exe downloads SGClientSetup.msi. To install the SG Client software on client machines silently or using Group Policy Objects (GPO) or the Microsoft Systems Management Server (SMS), use SGClientSetup.msi.

Client configuration

Displays the URL from which the SG Client installer downloads the client configuration file (SGClientConfig.xml).

Client configuration last modified

Displays the most recent date and time SGClientConfig.xml was updated on the Client Manager.

Uploading the SG Client Software to the Client Manager This section discusses how to upload updated SG Client software to the Client Manager so it can make the latest SG Client software available to install or to update on client machines. Important:

After you update the Client Manager’s SG Client software, whenever users connect using the SG Client, they must update their SG Client software. To upload the SG Client software to the Client Manager: 1.

If necessary, copy SGClient.car to a location that is accessible from the machine on which you are running the Management Console. That is, if you want to upload the SG Client software from your local file system or from a network share drive (as opposed to uploading it from a remote URL), you must copy SGClient.car to an accessible location.

2.

Log in to the Management Console as an administrator.

3.

Select SG Client > Client Manager.

4.

In the right pane, click the Client Software tab. On the Client Software tab page, the Current SG Client Software section displays information about the SG Client software this Client Manager is currently using.

153

Volume 5: Advanced Networking

5.

From the Install SG Client software from list, select one of the following: •

Remote URL: Upload SGClient.car from a location specified by a URL in the

following format: https://host:port/sgclient/SGClient_timestamp.car

For example, http://mysg.example.com:8004/sgclient/SGClient_timestamp.car

• 6.

Local file: Upload the SG Client software from a location accessible by the machine on which you are running the Management Console.

Click Install. You are required to confirm the action. Remember that any software or configuration updates require SG Client users to download the updates the next time they connect to the ADN network.

7.

Follow the prompts on your screen to complete the download. Note: A compatibility check is performed on the SG Client version you just uploaded. If the upload fails, you must upgrade your SGOS version before you can upload the SG Client .car file.

154

Chapter 12: Configuring and Using the SG Client

Configuring the SG Client from the Command Line This section includes the following topics: ❐

“Configuring General Client Settings (Command Line)” on page 155

❐

“Configuring Client CIFS Settings (Command Line)” on page 155

❐

“Configuring Client ADN Manager Settings (Command Line)” on page 156

❐

“Configuring Client ADN Rules Settings (Command Line)” on page 156

❐

“Setting the Client Manager (Command Line)” on page 157

❐

“Loading the Software (Command Line)” on page 157

Configuring General Client Settings (Command Line) For more information about general client settings, see “Configuring General Client Settings” on page 146. To configure general client settings: 1.

At the #(config) command prompt, enter sg-client.

2.

Configure general client settings: #(config #(config #(config #(config #(config

sg-client) sg-client) sg-client) sg-client) sg-client)

max-cache-disk-percent percentage software-upgrade-path url tcp-window-size bytes update-interval minutes view

Configuring Client CIFS Settings (Command Line) For more information about CIFS client settings, see “Configuring Client CIFS Settings” on page 148. To configure client CIFS client settings: 1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter cifs.

3.

Configure CIFS settings: #(config #(config #(config #(config #(config

sg-client sg-client sg-client sg-client sg-client

cifs) cifs) cifs) cifs) cifs)

directory-cache-time seconds {disable | enable} exit write-back {full | none} view

155

Volume 5: Advanced Networking

Configuring Client ADN Manager Settings (Command Line) For more information about client ADN Manager settings, see “Configuring Client ADN Manager Settings” on page 149. To configure client ADN manager settings: 1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter adn.

3.

Configure ADN manager settings: #(config sg-client adn) primary-manager ip-address #(config sg-client adn) backup-manager ip-address #(config sg-client adn) manager-port plain-port

Configuring Client ADN Rules Settings (Command Line) For more information about client ADN rules settings, see “Configuring Client ADN Rules Settings” on page 150. To configure client ADN rules settings: 1.

At the #(config) command prompt, enter sg-client.

2.

At the #(config sg-client) prompt, enter adn.

3.

Configure ADN rules settings: #(config sg-client adn) port-list {exclude-ports | include-ports} #(config sg-client adn) {exclude-ports | include-ports} {port-list | port-range} #(config sg-client adn) exclude-subnets #(config sg-client adn exclude-subnets) subnet_prefix[/prefix length] #(config sg-client adn exclude-subnets) #(config sg-client adn exclude-subnets) #(config sg-client adn exclude-subnets)

{add | remove} clear exit view

#(config sg-client adn) exit

156

Chapter 12: Configuring and Using the SG Client

Setting the Client Manager (Command Line) For more information about configuring the Client Manager, see “Configuring the Client Manager” on page 151. To configure the Client Manager: 1.

At the #(config) command prompt, enter sg-client.

2.

Enable this appliance as the Client Manager: #(config sg-client) enable Note:

Before you can enable an appliance to be the Client Manager, you must configure the ADN manager SG Clients will use. If you enable the Client Manager before you configure an ADN manager for clients, the following error displays: The

ADN primary manager must be set prior to enabling the SG Client Manager. To configure the clients’ ADN manager, see “Configuring Client ADN Rules

Settings” on page 150. 3.

Configure Client Manager settings: #(config sg-client) client-manager host {from-client-address | } #(config sg-client) client-manager install-port port #(config sg-client) client-manager keyring keyring

Loading the Software (Command Line) The following commands enable you to upload an updated SGClient.car file to the Client Manager. #(config sg-client) software-upgrade-path path-to-SGClient-car #(config) load sg-client-software

157

Volume 5: Advanced Networking

Making the SG Client Software Available to Users This section discusses how administrators can make the SG Client software available to users in the following ways: ❐

Interactive installations started from: •

A command line on the user’s machine

•

The Client Manager

For more information, see “Setting Up Interactive Installations” on page 159 ❐

Silent installations For more information, see “Setting Up Silent Installations and Uninstallations” on page 162

❐

Windows Group Policy Object distribution For more information, see “Using Group Policy Object Distribution” on page 168

❐

Windows Systems Management Server (SMS) distribution For more information about SMS, consult the documentation provided with your SMS server. Note:

For the user to run SGClientSetup.exe or SGClientSetup.msi, the user must be in the Administrators group on the client machine.

Important:

Do not rename SGClientSetup.msi; doing so causes future updates to fail.

Do not edit SGClientConfig.xml on the client machine; doing so causes unpredictable results in future configuration updates.

158

Chapter 12: Configuring and Using the SG Client

Setting Up Interactive Installations Users can install the SG Client software either by downloading SGClientSetup.exe from the Client Manager, or manually by running SGClientSetup.msi from a command line, as shown in the following table: Table 12-8. SG Client Installation Options Option

Description

Install from Client Manager

Provide users the URL to SGClientSetup.exe, which displays on the Client Manager tab page when you select SG Client > Client Manager. SGClientSetup.exe downloads and runs SGClientSetup.msi on the client machine. Users see the installation in progress and have the option of canceling the installation. For more information about this installation method, see

“Interactive Installations from the Client Manager” on page 159. Install from the command line

To install the SG Client using SGClientSetup.msi, users must first download it to the client machine, then execute it from the command line as discussed in “Interactive Manual Installations” on page 161. Note: For a complete discussion of SGClientSetup.msi command-line parameters, see “Setting Up Silent Installations and Uninstallations” on page 162.

Note:

Users who run the SG Client setup application must be in the Administrators group on the client machine.

Interactive Installations from the Client Manager To interactively install the SG Client software from the Client Manager, the user must be in the Administrators group on the client machine. To enable users to run SGClientSetup.exe from the Client Manager: Send users an e-mail with the URL to SGClientSetup.exe on the Client Manager. The URL displays when you select SG Client > Client Manager and click the Client Manager tab. To install the SG Client using this method: 1.

Get the URL or location from which you access SGClientSetup.exe.

2.

Click the URL in an e-mail or enter it in your browser’s address field.

3.

SGClientSetup.exe starts the setup application—SGClientSetup.msi—that installs

the SG Client software.

159

Volume 5: Advanced Networking

The following dialog displays if you use Internet Explorer 6:

4.

Click Run. The following dialog displays if you use Internet Explorer 6:

Note: The preceding dialog displays because SGClientSetup.exe is not signed. This is due to SGClientSetup.exe being unique to each Client Manager, which in turn makes signing it by a recognized certificate authority difficult.

5.

Click Run.

160

Chapter 12: Configuring and Using the SG Client

The SG Client software installation begins and while it is being downloaded, a progress dialog similar to the following displays:

When the installation is complete, a dialog displays two options: •

Click Now to reboot your machine immediately.

•

Click Later to reboot your machine at a later time. Select this option to save work before you reboot.

Interactive Manual Installations To enable users to manually install the SG Client software: Provide a location from which the user can download SGClientSetup.msi to the client machine; for example, provide the user the URL to the Client Manager. Important:

Do not rename SGClientSetup.msi; doing so causes future updates to fail.

Do not edit SGClientConfig.xml on the client machine; doing so causes unpredictable results in future configuration updates. To install the SG Client using this method: 1.

Download SGClientSetup.msi to a location on the local file system.

2.

Do either of the following: •

Click Start > Run, then enter the command shown in step 3.

•

Open a DOS command prompt window and change to the directory to which you downloaded SGClientSetup.msi

161

Volume 5: Advanced Networking

3.

Enter the following command: path\SGClientSetup.msi BCSI_UPDATEURL=url-to-config.xml

where path is the absolute file system path to SGClientSetup.msi (if necessary), urlto-config.xml is the URL to SGClientConfig.xml on the Client Manager. This URL displays when you select SG Client > Client Manager and click the Client Manager tab as discussed in “Configuring the Client Manager” on page 151. For example, SGClientSetup.msi BCSI_UPDATEURL=http://mysg.example.com:8084/ sgclient/SGClientConfig.xml Note:

Other command-line parameters are available. For a complete list, see “Setting Up Silent Installations and Uninstallations” on page 162. 4.

The installation proceeds as discussed in steps 12-14 and 5 in “Interactive Installations from the Client Manager” on page 159.

Setting Up Silent Installations and Uninstallations This section discusses how to silently install or uninstall the SG Client. See one of the following sections: ❐

“Parameters for Silent Installations” on page 163

❐

“Command for Silent Uninstallations” on page 165

❐

“Example Installations and Uninstallations” on page 165

Important:

Do not rename SGClientSetup.msi; doing so causes future updates to fail.

Do not edit SGClientConfig.xml on the client machine; doing so causes unpredictable results in future configuration updates. For information about distributing the SG Client software using Group Object Policy, skip this section and see “Using Group Policy Object Distribution” on page 168.

162

Chapter 12: Configuring and Using the SG Client

Parameters for Silent Installations The following table shows command-line parameters to use with SGClientSetup.msi for silent installations. For examples, see “Example Installations and Uninstallations” on page 165. Silent Installation Usage SGClientSetup.msi [/qr|/qn] BCSI_UPDATEURL=url REINSTALL=ALL REINSTALLMODE=vamus [AUTOUPDATEDISABLED=0|1] [AUTOUPDATEPROHIBITED=0|1] [FORCEREBOOT={yes|no} | {y|n}] [REBOOTTIME=secs] [/l*v logfile]

Silent Installation Parameters The following table shows the meanings of the parameters that can be used for silent installations; for examples, see “Example Installations and Uninstallations” on page 165: Table 12-9. Parameters for Silent SG Client Installations Parameter

Argument

Description /qr (interactive, default) enables the user to see and interact with the installer and to cancel the installation.

/qr|/qn

/qn (totally silent) prevents the user from seeing or interacting with the installer and from canceling the installation. Note: Because this is an msiexec command, other options are available. Enter msiexec at a command prompt for more information about other options. BCSI_UPDATEURL

url

URL to SGClientConfig.xml on the Client Manager, which you can find as discussed in “Configuring the Client Manager” on page 151, entered in the following format: https://client-manager-host:client-managerport/sgclient/SGClientConfig.xml

REINSTALL

ALL

Installs all SG Client components, whether they are already installed or not. ALL is the only supported parameter value in this release.

REINSTALLMODE

vamus

Blue Coat recommends using vamus as the parameter value. Because this is an msiexec command, other options are available. For more information, see the description of this parameter at: http://msdn2.microsoft.com/en-us/ library/aa371182.aspx

163

Volume 5: Advanced Networking

Table 12-9. Parameters for Silent SG Client Installations (Continued) Parameter

Argument

Description

AUTOUPDATEDISABLED

0|1

0 (default) means the SG Client automatically implements software and configuration updates at the frequency the administrator specified for software update interval in “Configuring General Client Settings” on page 146. 1 means the SG Client checks for software and configuration updates and does the following: • Implements configuration updates when they are available. • Implements software updates only if the user manually requests an update. This setting enables you to test the SG Client installation before deploying it in production. In other words, before you deploy the SG Client in your enterprise, you can test it in a controlled manner with a small number of users. Doing so keeps clients from requesting updates immediately after installation. (Users can manually update the software and configuration as discussed in the SG Client on-line help. After the user manually updates the software and configuration, the SG Client software checks for updates at the interval you specified in “Configuring General Client Settings” on page 146.)

AUTOUPDATEPROHIBITED

0|1

0 (default) means the SG Client automatically implements software and configuration updates at the interval the administrator specified for software update interval in “Configuring General Client Settings” on page 146. 1 means only the SG Client configuration can be updated (automatically or manually), but the SG Client software cannot be updated. Use this setting if you want to distribute software updates in some way other than the Client Manager. Note: AUTOUPDATEPROHIBITED=1 takes precedence over AUTOUPDATEDISABLED=1.

FORCEREBOOT

yes|no y|n

This setting controls whether or not Now or Later buttons display on the post-installation reboot dialog. yes or y mean the dialog displays without buttons. (However, if REBOOTTIME=0, no dialog displays.) no or n (default) mean a dialog displays with two options: Now and Later, enabling users to either reboot immediately, wait for the timer to expire (see the next parameter), or wait until a later time of their choosing.

REBOOTTIME

secs

Number of seconds after the SG Client installation completes before the user’s machine is rebooted. A value of 0 means there is no timer; to the user, a value of 0 has slightly different meanings, depending on the value of FORCEREBOOT. For more information, see “Example Installations and Uninstallations” on page 165. The default is 0.

164

Chapter 12: Configuring and Using the SG Client

Table 12-9. Parameters for Silent SG Client Installations (Continued) Parameter

Argument

Description

/l*v

logfile

If you want the installation to be logged, enter the absolute file system path and file name of the log file.

Command for Silent Uninstallations To silently uninstall the SG Client software, use the following command: msiexec /q /x {4214C5ED-CCED-4360-90C0-69764F3D0854}

The string {4214C5ED-CCED-4360-90C0-69764F3D0854} identifies the SG Client installer’s MSI product code. Note: ❐

If you changed the location of the CIFS cache as discussed in “Changing the Location of the CIFS Cache” on page 180, you must manually remove files from the new location after you uninstall the SG Client software. The SG Client uninstaller removes files only from the default CIFS cache folder.

❐

Users who have administrative privileges on their machines can also uninstall the SG Client using the Windows Control Panel’s Add or Remove Programs application.

Example Installations and Uninstallations This section shows the following examples: ❐

“Example Installations” on page 165

❐

“Example Uninstallation” on page 167

Important:

Do not rename SGClientSetup.msi; doing so causes future updates to fail.

Do not edit SGClientConfig.xml on the client machine; doing so causes unpredictable results in future configuration updates. Example Installations Example 1: Automated, interactive installation with manual software updates possible: SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/ sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus AUTOUPDATEDISABLED=1 FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration downloads from the Client Manager at https://mysg.example.com:8084. The user sees the installation in progress and can cancel it. AUTOUPDATEDISABLED=1 means that the SG Client does not implement software

updates after the initial installation (it will, however, implement configuration updates). This setting enables you to test the SG Client software on a small scale without having to plan for client updates. (To get software updates manually and thereafter enable automatic updates, click Check for Updates on the Advanced tab page in the SG Client dialog as discussed in

the SG Client on-line help.)

165

Volume 5: Advanced Networking

The REINSTALL and REINSTALLMODE parameters make sure that all SG Client components install, which is useful in cases where you are recovering from an incomplete or previously unsuccessful installation. After the installation is complete, the user has the following options: •

Wait 30 seconds for the machine to reboot

•

Click Later in the dialog to defer rebooting until a later time

•

Click Now in the dialog to reboot immediately

Example 2: Automated, interactive installation with no automatic software updates possible SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/ sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus AUTOUPDATEPROHIBITED=1 FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration downloads from the Client Manager at https://mysg.example.com:8084. The user sees the installation in progress and can cancel it. AUTOUPDATEPROHIBITED=1 means the SG Client cannot check for software updates after the initial installation; however, it will check for and implement configuration updates. Use this setting if you want to distribute software updates in some way other than the Client Manager.

The REINSTALL and REINSTALLMODE parameters make sure that all SG Client components install, which is useful in cases where you are recovering from an incomplete or previously unsuccessful installation. After the installation is complete, the user has the following options: •

Wait 30 seconds for the machine to reboot

•

Click Later in the dialog to defer rebooting until a later time

•

Click Now in the dialog to reboot immediately

Example 3: Automated, interactive installation SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/ sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus FORCEREBOOT=no REBOOTTIME=30

The SG Client configuration downloads from the Client Manager at https://mysg.example.com:8084. The user sees the installation in progress and can cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all SG Client components install, which is useful in cases where you are recovering from an incomplete or previously unsuccessful installation. After the installation is complete, the user has the following options: •

Wait 30 seconds for the machine to reboot

•

Click Later in the dialog to defer rebooting until a later time

•

Click Now in the dialog to reboot immediately

166

Chapter 12: Configuring and Using the SG Client

Example 4: Automated, interactive installation without a timer SGClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/ sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus FORCEREBOOT=no REBOOTTIME=0

The SG Client configuration downloads from the Client Manager at https://mysg.example.com:8084. The user sees the installation in progress and can cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all SG Client components install, which is useful in cases where you are recovering from an incomplete or previously unsuccessful installation. After the installation is complete, the user has the following options: •

Click Later in the dialog to defer rebooting until a later time

•

Click Now in the dialog to reboot immediately

Example 5: Totally silent installation, immediate reboot SGClientSetup.msi /qn BCSI_UPDATEURL=https://mysg.example.com:8084/ sgclient/SGClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus FORCEREBOOT=yes REBOOTTIME=0

The SG Client configuration downloads from the Client Manager specified at https:/ /mysg.example.com:8084. The user does not see the installation in progress and cannot cancel it. The user’s machine is rebooted immediately after the installation is complete. The REINSTALL and REINSTALLMODE parameters make sure that all SG Client components install, which is useful in cases where you are recovering from an incomplete or previously unsuccessful installation. Example Uninstallation msiexec /q /x {4214C5ED-CCED-4360-90C0-69764F3D0854}

The string {4214C5ED-CCED-4360-90C0-69764F3D0854} identifies the SG Client installer’s MSI product code.

167

Volume 5: Advanced Networking

Using Group Policy Object Distribution This section discusses how to distribute the SG Client software using Windows Group Policy Object (GPO). Important: Only an experienced Windows administrator should attempt to complete the tasks discussed in this section.

To distribute the SG Client software using GPO: 1.

Get an .msi transform tool, such as the Orca database editor. Orca is a table-editing tool available in the Windows Installer SDK that can be used to edit your .msi files. You can also use similar tools available from other vendors.

Note: Blue Coat does not recommend a particular transform tool.

For more information about Orca, see: http://support.microsoft.com/kb/255905/en-us

The remainder of this section assumes you use Orca. Consult the documentation provided with the transform tool you are using for vendor-specific instructions. 2.

Open SGClientSetup.msi.

3.

Make the following changes to the Property table:

Table 12-10. SGClientSetup Property Table Changes Property

Action

Value

BCSI_UPDATEURL

Add row

Required for all installations. URL to SGClientConfig.xml on the Client Manager, entered in the following format: https://client-manager-host:clientmanager-port/sgclient/SGClientConfig.xml

FORCEREBOOT

REINSTALL

Edit value

Required for all installations.

Add row

Add this row and set it to all only if you want to update the SG Client software and configuration using GPO.

Change the value from n to y. This value causes the user’s machine to reboot after the SG Client is downloaded, which is required to use the SG Client.

If clients get future SG Client software and configuration updates from the Client Manager, do not add this row. Also see the discussion of AUTOUPDATEPROHIBITED later in Table 12-11. REINSTALLMODE

Add row

Add this row and change it to vamus only if you want to update the SG Client software and configuration using GPO. If clients will get future SG Client software and configuration updates from the Client Manager, do not add this row. Also see the discussion of AUTOUPDATEPROHIBITED later in Table 12-11.

168

Chapter 12: Configuring and Using the SG Client

Table 12-10. SGClientSetup Property Table Changes Property

Action

Value

AUTOUPDATEDISABLED

Edit

Change the value from 0 to 1 only if you want to update the SG Client software using GPO. (Configuration updates are obtained from the Client Manager whose URL is specified by the BCSI_UPDATEURL parameter discussed earlier in this table.) 1 means the SG Client checks for software updates and does the following: • Implements configuration updates when they are available. • Implements software updates only if the user manually requests an update. This setting enables you to test the SG Client installation before deploying it in production.

AUTOUPDATEPROHIBITED

Edit value

Change the value from 0 to 1 only if you want to update the SG Client software using GPO. (Configuration updates are obtained from the Client Manager whose URL is specified by the BCSI_UPDATEURL parameter discussed earlier in this table.) 1 means only the SG Client configuration can be updated (automatically or manually), but the SG Client software cannot be updated. Use this setting if you want to distribute software updates in some way other than the Client Manager. Note: AUTOUPDATEPROHIBITED=1 takes precedence over AUTOUPDATEDISABLED=1. If clients will get future SG Client software updates from the Client Manager, leave this value at 0.

169

Volume 5: Advanced Networking

4.

Make the following changes to the InstallExecuteSequence table:

Table 12-11. SGClientSetup InstallExecuteSequence Table Changes Action

Action

Condition

FIX_REINSTALL

Edit condition

This change is required only if you used REINSTALL=all and REINSTALLMODE=vamus parameters. If required, replace the existing condition with the following: (NOT Installed) OR(REMOVE="ALL") This setting causes the SG Client to install and uninstall properly.

FIX_REINSTALLMODE

Edit condition

This change is required only if you used REINSTALL=all and REINSTALLMODE=vamus parameters. If required, replace the existing condition with the following: (NOT Installed) OR (REMOVE="ALL") This setting causes the SG Client to install and uninstall properly.

5.

Generate the transformation.

170

Chapter 12: Configuring and Using the SG Client

Using the SG Client After installing the SG Client, click the icon in the status bar and, from the pop-up menu, click Help. The SG Client on-line help system discusses how to use the SG Client software.

Troubleshooting Tips for Administrators For administrators to assist SG Client users with diagnosing errors, you need to be familiar with the topics discussed in this section: ❐

“Files and Folders Used by the SG Client” on page 171

❐

“SG Client Logging” on page 172

❐

“About Browser Proxies” on page 173

❐

“ADN Tunnels” on page 173

❐

“Clearing the Object Cache” on page 173

❐

“Client Manager Logging” on page 174

❐

“Advanced Troubleshooting Suggestions” on page 174

Files and Folders Used by the SG Client The following table summarizes the files and folders used by the SG Client software: Table 12-12. SG Client Files and Folders File or Folder Name

Description

system-root-volume\Program Files\Blue Coat\SG Client

Software binaries.

SGClientSetup.log SGClientSetup2.log SGClientUI.log sglog.etl sgdebug.etl sgautoupdate.log %windir%\system32\sgclient\cifs

SG Client log files, discussed in more detail in

“SG Client Logging” on page 172.

Object cache folder, which is the hidden folder in which CIFS objects are cached. For information about clearing the object cache, see “Clearing the Object Cache” on page 173. Note: Because the object cache is typically large and contains redundant data, you should exclude the object cache from being backed up. If the client machine has to be restored from backup, the object cache is rebuilt when the user performs an action such as opening or copying a file on a remote file system.

171

Volume 5: Advanced Networking

SG Client Logging The SG Client maintains the following logs in the user’s %TMP% folder: Table 12-13. SG Client Log Files File Name

Description

SGClientSetup.log

SGClientSetup.exe log; displays errors related to downloading SGClientConfig.xml or running SGClientSetup.exe.

SGClientSetup2.log

SGClientSetup.msi log; displays errors related to installing the SG Client software.

The SG Client maintains the following logs in the user’s %windir%\system32\sgclient\support folder: Table 12-14. SG Client Log Files File Name

Description

sglog.etl

SG Client application log. This file can reach a maximum of 20MB in size, after which the oldest log entries are deleted as new entries are written.

sgdebug.etl

SG Client trace log. This file can reach a maximum of 20MB in size, after which the oldest log entries are deleted as new entries are written. This log is in a compiled format that is readable only by Blue Coat Engineering.

The SG Client maintains the following log in the SG Client installation folder (for example, C:\Program Files\Blue Coat\SG Client): Table 12-15. SG Client Log Files File Name

Description

SGClientUI.log

Logs user interface actions.

sgautoupdate.log

Logs software updates but not configuration updates. Configuration update log messages are contained in sgautoupdate.log.

172

Chapter 12: Configuring and Using the SG Client

About Browser Proxies For users to download SG Client software and configuration updates, you might need to change proxy settings for SSL traffic. If you do not use a proxy for SSL traffic, you can skip this section. The following options are available: ❐

If users can connect directly to the Client Manager, change the browser’s proxy settings to exclude the Client Manager from being proxied.

❐

Change the proxy settings to allow connections to the Client Manager listen port (by default, 8084). You chose the Client Manager listen port as discussed in “Configuring the Client Manager” on page 151. This method works for all users—even those who cannot connect directly to the Client Manager. Note: The SG Client uses the Internet Explorer proxy settings to download software and configuration updates, so make sure you change Internet Explorer’s proxy settings.

ADN Tunnels On the General tab page of the SG Client dialog, clicking View ADN Tunnels displays detailed information about available tunnels, including whether a tunnel is idle or bypassed. An Idle tunnel is one that is not currently being used but for which connection information is preserved to decrease the amount of time required to use that connection later, if necessary. A Bypassed tunnel indicates an error with the connection to the indicated SG appliance.

Clearing the Object Cache To free disk space on the user’s system root volume, the user can clear the object cache by clicking Clear Cache on the SG Client dialog’s General tab page. The object cache is located in the user’s %windir%\system32\sgclient\cifs folder, which is a hidden folder. Clearing the cache affects the performance of file copies, listing directories, and opening files in different applications. Also, clearing the cache while the client is running does not delete files that are currently in use.

173

Volume 5: Advanced Networking

Client Manager Logging The Client Manager logs success or failure events related to users downloading the SG Client software and configuration. Each log should include timestamp, HTTP GET string (including the HTTP return code), and client machine name). To get Client Manager logs: Enter the following URL in your browser’s address field: https://host:port/sgclient/log

where host is the fully qualified host name or IP address of the Client Manager, and port is the SG appliance’s listen port.

Advanced Troubleshooting Suggestions This section discusses advanced troubleshooting tools and procedures for administrators. The tasks discussed in this section should be performed only by administrators, or by users with assistance from administrators. Following is a brief discussion of each troubleshooting tool: Tool

Description

Shortcut

For more information

Change the Client Manager URL

Enables you to connect to a Client Manager other than the one you initially downloaded the SG Client from. The typical use is for Blue Coat employees to run demonstrations, trials, and evaluations from different ADN networks.

Advanced tab page, left Control+Shift, click Check for Updates

“Changing the Client Manager URL” on page 175

Data collector

Collects diagnostic information useful to troubleshoot unexpected behavior and connectivity problems.

About tab page, left Control+Shift, click Help

“Using the SG Client Data Collector” on page 176

Diagnostic and configuration utility

Displays routing information for the ADN network, enables you to set SG Client software auto-update options, and enables you to create an SG Client service crash dump.

About tab page, left Control+Shift, click System Info

“Using the SG Client Diagnostics & Configuration Utility” on page 178

Change the location of the object cache filesa

Change the location of object cache files to a volume that has more space. By default, object cache files are stored on the user’s system root volume.

(No shortcut because it is a registry setting)

“Changing the Location of the CIFS Cache” on page 180

174

Chapter 12: Configuring and Using the SG Client

Changing the Client Manager URL When you download the SG Client or install it manually as discussed in the chapter on the SG Client in the Advanced Networking book, you are required to specify a Client Manager URL that is used to: ❐

Initially install the SG Client software from the Client Manager

❐

Download updates to the SG Client software

❐

Download updates to the SG Client configuration (the configuration includes the IP address of the ADN manager and backup manager, from which the SG Client obtains routing information for the ADN network)

You can change the Client Manager URL, for example, to run trials or demonstrations on a different ADN network than the one for which you initially configured the SG Client. Note: If the SG Client was installed with either automatic software updates or automatic configuration updates disabled, those options are not changed when you change the Client Manager URL. Be aware of the following: ❐

If automatic software updates are prohibited, you cannot download SG Client software update unless you manually change the auto-update option as discussed in “Using the SG Client Diagnostics & Configuration Utility” on page 178.

❐

If automatic configuration updates are prohibited, you must manually check for configuration updates after you connect to the new Client Manager. For more information, see the discussion of the following installation options in the chapter on the SG Client in the Advanced Networking book: AUTOUPDATEDISABLED and AUTOUPDATEPROHIBITED.

To change the Client Manager URL: 1.

Install the SG Client as discussed in the chapter on the SG Client in the Advanced Networking book.

2.

Double-click the SG Client icon in the system tray.

3.

Click the Advanced tab.

4.

On the Advanced tab page, hold down left Control+Shift and click Check for Updates. The Change SG Client Configuration dialog displays.

5.

In the New Config URL field, enter the URL to the new Client Manager in the following format: https://host-or-ip:port/path/SGClientConfig.xml where host-or-ip is the Client Manager’s fully-qualified host name or IP address, port is the Client Manager’s listen port, and path is the path to SGClientConfig.xml.

In other words, enter the URL to SGClientConfig.xml, which displays on the Client Manager tab page when you select SG Client > Client Manager. For example: https://mysg.example.com:8084/sgclient/SGClientConfig.xml

175

Volume 5: Advanced Networking

6.

Click OK. Messages display in the Change SG Client Manager dialog as the URL is verified, the SG Client service is stopped, and the service is restarted. After the service is restarted, configuration updates (if any) are downloaded to the SG Client. If automatic configuration updates are disabled, see step 7. If software updates are ready to download, you are notified before the updates are installed. If automatic software updates are disabled, the SG Client skips this step. To manually enable automatic updates on this machine, see “Using the SG Client Diagnostics & Configuration Utility” on page 178. When the operation is complete, the Advanced tab page displays the new Client Manager URL.

7.

If automatic configuration updates are disabled: a.

Double-click the SG Client icon in the system tray.

b.

Click the Advanced tab.

c.

On the Advanced tab page, click Check for Updates. Configuration updates, if any, are downloaded to the SG Client.

Using the SG Client Data Collector The SG Client Data Collector utility collects information that administrators or Blue Coat Support can use to diagnose problems with the SG Client application and network connectivity. The Data Collector gets following information, places it in a temporary directory, and optionally stores it in a .zip file: ❐

System information

❐

SG Client log files

❐

SG Client crash dumps

❐

SGClientConfig.xml

❐

Information about running processes

❐

Network information

❐

Other information about the SG Client

To run the SG Client Data Collector utility: 1.

Install the SG Client as discussed in the chapter on the SG Client in the Advanced Networking book.

2.

Double-click the SG Client icon in the system tray.

3.

Click the About tab.

4.

On the About tab page, hold down left Control+Shift and click Help. The SG Client Data Collector dialog displays.

5.

Click Start. A green check mark displays next to each task as it completes successfully. At any time, click Stop to stop the data collection process.

176

Chapter 12: Configuring and Using the SG Client

6.

7.

When all tasks are complete, the Collection Complete dialog gives you the following options: •

Click Save Data to save the data in a .zip file to a directory you select.

•

Click Open Folder to open the temporary folder that contains the collected data files.

•

Click Close.

Send the data to Blue Coat Support. After you close the Collection Complete dialog, the SG Client Data Collector dialog displays as follows:

8.

You have the following options: •

Click Open folder with collected data to view the files collected by the Data Collector.

•

Click Exit to close the SG Client Data Collector dialog.

177

Volume 5: Advanced Networking

Using the SG Client Diagnostics & Configuration Utility The Diagnostics & Configuration utility enables you to: ❐

View ADN network routing information

❐

View the list of excluded subnets and included ports defined by the Client Manager

❐

Enable or disable automatic software updates

❐

Create an SG Client service crash dump

To run the SG Client Diagnostics & Configuration utility: 1.

Install the SG Client as discussed in the chapter on the SG Client in the Advanced Networking book.

2.

Double-click the SG Client icon in the system tray.

3.

Click the About tab.

4.

On the About tab page, hold down left Control+Shift and click System Info. The Diagnostics & Configuration dialog displays similarly to the following:

178

Chapter 12: Configuring and Using the SG Client

5.

You have the following options: Task

Procedure

View ADN network and routing information

The SG Client Routing section at the top of the dialog box displays the following information: • Subnets: Displays routing information the SG Client obtained from the ADN manager. This information shows which locations are being accelerated. If a server does not appear to be accelerated (for example, if downloads from that server are slow), look at the routing table to see if the server is published as an accelerated destination. If not, the administrator should configure the concentrator to recognize the server as an accelerated destination. The routing table does not indicate whether a particular location is reachable, however. Look in the SG Client logs to determine whether the locations are reachable. To update routing information, click Refresh Routing Information. • Excluded subnets: Displays the list of excluded subnets defined by the Client Manager. • Included ports: Displays the list of included ports defined by the Client Manager. For more information about excluded subnets and included ports, see the chapter on the SG Client in the Advanced Networking book.

Change automatic update options

Click one of the following to determine whether or not the client can download updated software from the Client Manager: • Enabled: Users can download future SG Client software updates on this machine. • Disabled: Users cannot download future SG Client software updates on this machine. Choose this option to distribute software updates some other way (for example, using Windows Group Policy Object (GPO) distribution or Microsoft System Management Server (SMS) distribution).

Create an SG Client service crash dump file

In the event of problems with the SG Client application (such as crashes or freezes), click to create an SG Client service dump file named sgclientsvc.dmp file in the root directory of the system root volume (for example, C:\). Send the crash dump to Blue Coat Support as part of your service request.

6.

When you are finished, click Close.

179

Volume 5: Advanced Networking

Changing the Location of the CIFS Cache This section discusses how to change the location the SG Client stores CIFS cache files. (The SG Client CIFS cache is also referred to as the object cache.) Note: The SG Client uninstaller removes files only from the default CIFS cache folder. If you change the location of the CIFS cache, you must manually remove files from the new location after you uninstall the SG Client software. By default, the CIFS cache is stored in the following folder on the system root volume: %windir%\system32\sgclient\cifs

To optionally locate the files on a different volume (for example, a volume that has more available space): 1.

If the SG Client is already installed, perform the following tasks first: a.

Double-click the SG Client icon in the system tray.

b.

In the SG Client dialog box, click the General tab.

c.

On the General tab page, click Clear Cache. This deletes or expires all the files in the current CIFS cache.

d. Click Disable SG Client. e. 2.

Click Close.

Create a registry value named CacheDirectory of type REG_SZ (that is, String) in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Systems\SG Client

3.

Set the Value data of CacheDirectory to the location to store the object cache. Note: If the SG Client is not already installed, create the registry before you install the SG Client to avoid the user having to restart the SG Client service. Restarting the service stops ADN acceleration and CIFS protocol acceleration until an ADN tunnel can be re-established after the service starts.

4.

If you have not already done so, install the SG Client as discussed in the chapter on the SG Client in the Advanced Networking book.

5.

Reboot the client machine or restart the SG Client service for the registry key to take effect. To restart the SG Client service, right-click on its icon in the system tray. From the popup menu, click Disable SG Client. Right-click the icon again and, from the pop-up menu, click Enable SG Client.

6.

Optional. After the service restarts, manually remove any files remaining in the previous CIFS cache directory: %windir%\system32\sgclient\cifs

180

Chapter 12: Configuring and Using the SG Client

Licensing ❐

A new SG appliance has a 60-day trial license that permits you to use it with an unlimited number of clients.

❐

After the 60-day trial period, you are required to purchase a permanent license to continue using the SG Client. The license entitles you to support a certain number of clients in your enterprise; however, the license does not limit the number of ADN tunnels to which clients can have access. Client machines do not require a license to use the SG Client software; only the Client Manager appliance requires a license.

❐

You can upgrade your license to larger user counts.

For information about applying a permanent Client Manager license, see the chapter on licensing in Volume 1: Getting Started.

181

Volume 5: Advanced Networking

182

Chapter 13: SOCKS Gateway Configuration

The Blue Coat implementation of SOCKS includes the following: ❐

A SOCKS proxy server that supports both SOCKSv4/4a and SOCKSv5, running on the SG appliance.

❐

Support for forwarding through SOCKS gateways.

To configure a SOCKS proxy server on the SG appliance, refer to Volume 2: Proxies and Proxy Services. To use SOCKS gateways when forwarding traffic, continue with this chapter. This chapter contains the following sections: ❐

Section A: "Configuring a SOCKS Gateway" on page 184.

❐

Section B: "Using SOCKS Gateways Directives with Installable Lists" on page 192.

183

Volume 5: Advanced Networking Section A: Configuring a SOCKS Gateway

Section A: Configuring a SOCKS Gateway SOCKS servers provide application level firewall protection for an enterprise. SOCKS gateways, like ICP and forwarding, can use installable lists for configuration. You can configure the installable list using directives. You can also use the Management Console or the CLI to create a SOCKS gateways configuration. Using the Management Console is the easiest method. To configure a SOCKS gateway: 1.

Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateways.

2.

Click New to create a new SOCKS gateway.

3.

Configure the SOCKS gateway as follows: a.

Alias: Give the gateway a meaningful name. Note: SOCKS gateway aliases cannot be CPL keywords, such as no, default, forward, or socks_gateways.

184

Chapter 13: SOCKS Gateway Configuration

Section A: Configuring a SOCKS Gateway b.

Host: Add the IP address or the host name of the gateway where traffic is directed. The host name must DNS resolve.

c.

Port: The default is 1080.

d.

SOCKS version: Select the version that the SOCKS gateway can support from the drop-down list. Version 5 is recommended.

e.

Username (Optional, and only if you use version 5) The username of the user on the SOCKS gateway. The username already must exist on the gateway. If you have a username, you must also set the password.

f.

Set Password: The plaintext password or encrypted password of the user on the SOCKS gateway. The password must match the gateway’s information. The password can be up to 64 bytes long. Passwords that include spaces must be within quotes. You can enter an encrypted password (up to 64 bytes long) either through the CLI or through installable list directives.

g.

In the Load Balancing and Host Affinity section, select the load balancing method from the drop-down list. Global default (configured on the Configuration > Forwarding > Global Defaults tab), sets the default for all SOCKS gateways on the system. You can also specify the load balancing method for this system: Least Connections or Round Robin, or you can disable load balancing by selecting None.

h.

In the Host affinity methods drop-down list, select the method you want to use: •

HTTP: The default is to use the Global Defaults. Other choices are None, which disables host affinity, Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address

to determine which upstream SOCKS gateway was last used. By default, SOCKS treats all incoming requests destined to port 80 as HTTP, allowing the usual HTTP policy to be performed on them, including ICAP scanning. If the SOCKS connection is being made to a server on another port, write policy on the SG appliance to match on the server host and port and specify that it is HTTP using SOCKS. •

SSL: The default is to use the Global Defaults. Other choices are None, which disables host affinity, Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address

to determine which group member was last used. In addition, you can select SSL Session ID, used in place of a cookie or IP address, which extracts the SSL

session ID name from the connection information. •

Other. Other applies to any traffic that is not HTTP, terminated HTTPS, or intercepted HTTPS. You can attempt load balancing of any of the supported traffic types in forwarding and this host affinity setting can be applied as well. For example, you could load balance a set of TCP tunnels and apply the Other host affinity (client IP only).

The default is to use Global Defaults. Other choices are None, which disables host affinity, and Client IP Address, which uses the client IP address to determine which group member was last used. 4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

185

Volume 5: Advanced Networking Section A: Configuring a SOCKS Gateway To create groups: An existing gateway can belong to none, one, or more groups as desired (it can only belong once to a single group, however). 1.

Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateway Groups.

2.

Click New to create a new SOCKS gateway group.

3.

The Add SOCKS Gateway Group dialog displays, showing the available host aliases. To create an alias group, highlight the hosts and groups you want grouped, and click Add.

4.

Give the new group a meaningful name.

5.

In the Load Balancing and Host Affinity section, select the load balancing method from the drop-down list. Global default (configured on the Configuration > Forwarding > SOCKS Gateways > Global Defaults tab), sets the default for all forwarding hosts on the system. You can also specify the load balancing method for this system: Least Connections, Round Robin, Domain Hash, URL Hash, or you can disable load balancing by selecting None.

6.

In the Host affinity methods drop-down lists, select the method you want to use. Refer to the previous procedure for details on methods.You are selecting between the resolved IP addresses of all of the hosts in the group, not the resolved IP addresses of an individual host.

186

Chapter 13: SOCKS Gateway Configuration

Section A: Configuring a SOCKS Gateway •

HTTP: The default is to use the Global Defaults. Other choices are None, which disables host affinity, Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address to determine which group member was last used.

•

SSL: The default is to use the Global Defaults. Other choices are None, which disables host affinity, Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address to determine which group member was last used. In addition, you can select SSL Session ID,

used in place of a cookie or IP address, which extracts the SSL session ID name from the connection information. •

Other. Other applies to any traffic that is not HTTP, terminated HTTPS, or intercepted HTTPS. You can attempt load balancing of any of the supported traffic types in forwarding and this host affinity setting can be applied as well. For example, you could load balance a set of TCP tunnels and apply the Other host affinity (client IP only).

The default is to use Global Defaults. Other choices are None, which disables host affinity, and Client IP Address, which uses the client IP address to determine which group member was last used. 7.

Click OK.

8.

Click Apply to commit the changes to the SG appliance.

Configuring Global SOCKS Defaults The global defaults apply to all SOCKS gateways hosts and groups unless the settings are specifically overwritten during host or group configuration. To configure global defaults: 1.

Select Configuration > Forwarding > SOCKS Gateways > Global Defaults.

2.

Determine how you want connections to behave if the health checks fail: Connect Directly (fail open) or Deny the request (fail closed). Note that failing open is an insecure option. The default is to fail closed. This option can be overridden by policy, if it exists.

187

Volume 5: Advanced Networking Section A: Configuring a SOCKS Gateway 3.

Configure Global Load Balancing and Host Affinity Settings a.

b.

Load Balancing methods: •

SOCKS hosts: Specify the load balancing method for all forwarding hosts unless their configuration specifically overwrites the global settings. You can choose Least Connections or Round Robin, or you can disable load balancing by selecting None. Round Robin is specified by default.

•

SOCKS groups: Specify the load balancing method for all forwarding groups unless their configuration specifically overwrites the global settings. You can choose to hash the domain or the full URL. You can also choose Least Connections, Round Robin, Domain Hash, URL Hash, and you can disable load balancing by selecting None. Round Robin is specified by default.

Configure Global Host Affinity methods: •

HTTP: The default is to use None, which disables host affinity. Other choices are Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address to determine which group

member was last used. •

SSL: The default is to use None, which disables host affinity. Other choices are Accelerator Cookie, which places a cookie in the response to the client, and Client IP Address, which uses the client IP address to determine which group member was last used, and SSL Session ID, used in place of a cookie or IP

address, which extracts the SSL session ID name from the connection information. •

Other: Other applies to any traffic that is not HTTP, terminated HTTPS, or

intercepted HTTPS. You can attempt load balancing of any of the supported traffic types in forwarding and this host affinity setting can be applied as well. For example, you could load balance a set of TCP tunnels and apply the Other host affinity (client IP only). The default is to use None, which disables host affinity. You can also choose Client IP Address, which uses the client IP address to determine which group member was last used. c.

Host Affinity Timeout: This is the amount of time a user's IP address, SSL ID,

or cookie remains valid. The default is 30 minutes, meaning that the IP address, SSL ID or cookie must be used once every 30 minutes to restart the timeout period. 4.

Click Apply to commit the changes to the SG appliance.

Configuring the Default Sequence The default sequence defines what SOCKS gateways to use when no policy is present to specify something different. The system uses the first host or group in the sequence that is healthy, just as it does when a sequence is specified through policy. Only one default sequence is allowed. All members must be pre-existing hosts, and no member can be in the group more than once.

188

Chapter 13: SOCKS Gateway Configuration

Section A: Configuring a SOCKS Gateway A default failover sequence allow healthy hosts to take over for an unhealthy host (one that is failing its DNS Resolution or its health check). The sequence specifies the order of failover, with the second host taking over for the first host, the third taking over for the second, and so on. If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. This configuration is usually created and managed through policy. If no SOCKS-gateways policy applies, you can create a default sequence through the CLI. This single default sequence consists of a single default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. To create the default sequence: Note: Traffic is forwarded to the first member of the list until it fails, then traffic is sent to the second member of list until it fails or the first member becomes healthy again, and so on.

1.

Select Configuration > Forwarding > SOCKS Gateways > Default Sequence.

2.

The available aliases (host and group) display in the Available Aliases pane. To select an alias, highlight it and click Add. Note: Any host or group in the default sequence is considered in use by policy. As a result, if you try to delete a host or group while it is in the default sequence, you receive an error message. You must remove the host/group from the sequence first, then delete the host or group.

3.

You can use the Promote and Demote buttons to change the order of the hosts and groups in the sequence after you add them to the Selected Aliases pane.

4.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Configure SOCKS Gateways SGOS#(config) socks-gateways SGOS#(config socks-gateways) create gateway gateway_alias gateway_host SOCKS_port [group=group-alias] [version {=4 | =5}] [user=username {password=password | encrypted-password=encrypted-password}] SGOS#(config socks-gateways) create group group_name SGOS#(config socks-gateways) delete all

189

Volume 5: Advanced Networking Section A: Configuring a SOCKS Gateway SGOS#(config socks-gateways) delete gateway gateway_alias SGOS#(config socks-gateways) delete group group_name SGOS#(config socks-gateways) destroy-old-passwords SGOS#(config socks-gateways) edit gateway_alias SGOS#(config socks-gateways gateway_alias) encrypted-password encrypted_password SGOS#(config socks-gateways gateway_alias) host gateway_host SGOS#(config socks-gateways gateway_alias) host-affinity http {default | none | client-ip-address | accelerator-cookie} SGOS#(config socks-gateways gateway_alias) host-affinity ssl {default | none | client-ip-address | accelerator-cookie | sslsession-id} SGOS#(config socks-gateways gateway_alias) host-affinity other {default | none | client-ip-address} SGOS#(config socks-gateways gateway_alias) load-balance method {default | least-connections | none | round-robin} SGOS#(config socks-gateways gateway_alias) no password | user SGOS#(config socks-gateways gateway_alias) password password SGOS#(config socks-gateways gateway_alias) port socks_port SGOS#(config socks-gateways gateway_alias) user username SGOS#(config socks-gateways gateway_alias) version 4 | 5 SGOS#(config socks-gateways gateway_alias) view SGOS#(config socks-gateways) edit group_alias SGOS#(config socks-gateways group_alias) {add | remove} gateway_alias SGOS#(config socks-gateways group_alias) host-affinity http {default | none | client-ip-address | accelerator-cookie} SGOS#(config socks-gateways group_alias) host-affinity ssl {default | none | client-ip-address | accelerator-cookie | ssl-session-id} SGOS#(config socks-gateways group_alias) host-affinity other {default | none | client-ip-address} SGOS#(config socks-gateways group_alias) load-balance method {default | domain-hash | least-connections | none | round-robin | url-hash} SGOS#(config socks-gateways group_alias) view SGOS#(config socks-gateways) exit SGOS#(config socks-gateways) failure-mode {open | closed} SGOS#(config socks-gateways) host-affinity http {default | none | client-ip-address | accelerator-cookie} gateway_or_group_alias -orSGOS#(config socks-gateways) host-affinity ssl {default | none | client-ip-address | accelerator-cookie | ssl-session-id} gateway_or_group_alias -orSGOS#(config socks-gateways) host-affinity other {default | client-ipaddress | none} gateway_or_group_alias SGOS#(config socks-gateways) load-balance gateway {default | none | round-robin | least-connections} gateway_alias SGOS#(config socks-gateways) load-balance group {default | none | domain-hash | url-hash | round-robin | least-connections} group_alias

190

Chapter 13: SOCKS Gateway Configuration

Section A: Configuring a SOCKS Gateway SGOS#(config socks-gateways) no path SGOS#(config socks-gateways) path url SGOS#(config socks-gateways) sequence {add | demote | promote | remove} gateway-alias SGOS#(config socks-gateways) sequence clear SGOS#(config socks-gateways) view

Statistics SOCKS gateways statistics are available through the Statistics > Advanced > SOCKS Gateways menu item.

191

Volume 5: Advanced Networking Section B: Using SOCKS Gateways Directives with Installable Lists

Section B: Using SOCKS Gateways Directives with Installable Lists To configure a SOCKS gateway, you can use the Management Console (easiest), the CLI, or you can create an installable list and load it on the SG appliance. To use the Management Console, see Section A: "Configuring a SOCKS Gateway" on page 184. For information on installing the file itself, see “Creating a SOCKS Gateway Installable List” on page 196. The SOCKS gateways configuration includes SOCKS directives that: ❐

Names the SOCKS gateways, version, and port number

❐

Creates the SOCKS gateways groups

❐

Provide load balancing and host affinity

❐

Specifies the username

❐

Specifies the password

Available directives are described in the table below. Table 13-1. SOCKS Directives Directive

Meaning

gateway

Specifies the gateway alias and name, SOCKS port, version supported, usernames and password.

group

Creates a forwarding group directive and identifies member of the group.

host_affinity

Directs multiple connections by a single user to the same group member.

load_balance

Manages the load among SOCKS gateways in a group, or among multiple IP addresses of a gateway.

sequence alias_list

Adds a space-separated list of one or more SOCKS gateways and group aliases. (The default sequence is the default forwarding rule, used for all requests lacking policy instructions

socks_fail

In case connections cannot be made, specifies whether to abort the connection attempt or to connect to the origin content server.

Syntax for the SOCKS directives are: gateway gateway_alias gateway_name SOCKS_port [group=group_alias] [version={4 | 5}] [user=username] [password=password] [encryptedpassword=encrypted_password] group=group_alias [gateway_alias_list] host_affinity http {none | client-ip-address | accelerator-cookie} [gateway_or_group_alias] host_affinity ssl {none | client-ip-address | accelerator-cookie | ssl-session-id} [gateway_or_group_alias] host_affinity other {none | client-ip-address} [gateway_or_group_alias] host_affinity timeout minutes

192

Chapter 13: SOCKS Gateway Configuration

Section B: Using SOCKS Gateways Directives with Installable Lists load_balance group {none | domain-hash | url-hash | round-robin | least-connections} [group_alias] load_balance gateway {none | round-robin | least-connections} [gateway_alias] sequence alias_list socks_fail {open | closed}

For more information on SOCKS gateway directives, continue with the next section. For information on: ❐ ❐

group directives, continue with “Creating SOCKS Gateways Groups Using Directives” on page 194 load_balance directives, continue with “Configuring Load Balancing Directives” on

page 194 ❐

host_affinity directives, continue with “Configuring Host Affinity Directives” on

page 195 ❐

socks_fail directives, continue with “Setting Fail Open/Closed” on page 194

❐

sequence directives, continue with “Creating a Default Sequence” on page 196

Configuring SOCKS Gateways Using Directives SOCKS gateways can be configured using the gateways suboptions in the table below. Table 13-2. SOCKS Gateways Syntax Command

Suboptions

gateway

Description Configures the SOCKS gateway.

gateway_alias

A meaningful name that is used for policy rules.

gateway_name

The IP address or name of the gateway where traffic is directed. The gateway name must DNS resolve.

SOCKS_port

The port number of the SOCKS gateway.

version={4 | 5}

The version that the SOCKS gateway can support.

user=username

(Optional, if you use v5) The username of the user. It already must exist on the gateway.

password=password

(Optional, if you use v5) The password of the user on the SOCKS gateway. It must match the gateway’s information.

encryptedpassword=encrypted_ password

(Optional, if you use v5) The encrypted password of the user on the SOCKS gateway. It must match the gateway’s information.

Example gateway Sec_App1 10.25.36.47 1022 version=5 user=username password=password

193

Volume 5: Advanced Networking Section B: Using SOCKS Gateways Directives with Installable Lists

Creating SOCKS Gateways Groups Using Directives The SOCKS gateway groups directive has the following syntax: group group_name gateway_alias_1 gateway_alias_2...

where group_name is the name of the group, and gateway_alias_1, gateway_alias_2, and so forth are the gateways you are assigning to the SOCKS gateways group.

Setting Special Parameters After you configure the SOCKS gateways and groups, you might need to set other special parameters to fine tune gateways. You can configure the following settings: ❐

“Setting Fail Open/Closed”

❐

“Configuring Load Balancing Directives” on page 194

❐

“Configuring Host Affinity Directives” on page 195

Setting Fail Open/Closed Using directives, you can determine if the SOCKS gateways fails open or closed or if an operation does not succeed. The syntax is: socks_fail {open | closed}

where the value determines whether the SOCKS gateways should fail open or fail closed if an operation does not succeed. Fail open is a security risk, and fail closed is the default if no setting is specified. This setting can be overridden by policy, using the SOCKS_gateway.fail_open(yes|no) property. Examples socks_fail open

Configuring Load Balancing Directives Load balancing shares the load among a set of IP addresses, whether a group or a gateway with multiple IP addresses. The syntax is: load_balance group {none | domain-hash | url-hash | round-robin | least-connections} [group_alias] load_balance gateway {none | round-robin | least-connections} [gateway_alias] Table 13-3.

Load Balancing Directives

Command

Suboptions

Description

load_balance group

{none | domain-hash | urlhash | round-robin | least-connections} [group_alias]

If you use group for load balancing, you can set the suboption to none or choose another method. If you do not specify a group, the settings apply as the default for all groups.

194

Chapter 13: SOCKS Gateway Configuration

Section B: Using SOCKS Gateways Directives with Installable Lists Table 13-3.

Load Balancing Directives

Command

Suboptions

Description

load_balance gateway

{none | round-robin | least-connections} [gateway_alias]

If you use gateway for load balancing, you can set the suboption to none or choose another method. If you do not specify a gateway, the settings apply as the default for all gateways.

Example load_balance gateway least_connections

Configuring Host Affinity Directives Host affinity is the attempt to direct multiple connections by a single user to the same group member. The syntax is: host_affinity http {none | client-ip-address | accelerator-cookie} [gateway_or_group_alias] host_affinity ssl {none | client-ip-address | accelerator-cookie | ssl-session-id} [gateway_or_group_alias] host_affinity other {none | client-ip-address} [gateway_or_group_alias] host_affinity timeout minutes Table 13-4. Commands to Configure Host Affinity Directives Command

Suboption

Description

host_affinity http

{accelerator-cookie | client-ip-address | none} [gateway_or_group_alias]

Determines which HTTP host-affinity method to use (accelerator cookie or client-ip-address), or you can specify none. If you do not specify a gateway or group, the settings apply as the default for all gateways or groups.

host_affinity ssl

{accelerator-cookie | client-ip-address | none | ssl-session-id} [gateway_or_group_alias]

Determines which SSL host-affinity method to use (accelerator cookie, client-ip-address, or sslsession-id), or you can specify none. If you do not specify a gateway or group, the settings apply as the default for all gateways or groups.

host_affinity other

other {none | client-ipaddress} [gateway_or_group_alias]

Determines whether TCP tunnel and Telnet is used. Determines whether to use the client-ip-address hostaffinity method or specify none. If you do not specify a gateway or group, the settings apply as the default for all gateways or groups.

host_affinity timeout

minutes

Determines how long a user's IP address, SSL ID, or cookie remains valid when idle

195

Volume 5: Advanced Networking Section B: Using SOCKS Gateways Directives with Installable Lists Example host_affinity ssl accelerator-cookie 10.25.36.48 host_affinity timeout 5

Creating a Default Sequence The default sequence is the default SOCKS gateways rule, used for all requests lacking policy instructions. Failover is supported if the sequence (only one is allowed) has more than one member. Note: Creating the default sequence through the CLI is a legacy feature. You can set up sequences by using policy alone. The default sequence (if present) is applied only if no applicable command is in policy.

For information on using VPM, refer to Volume 6: VPM and Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy Language Guide. A default failover sequence works by allowing healthy SOCKS gateways to take over for an unhealthy gateway (one that is failing its DNS resolution or its health check). The sequence specifies the order of failover, with the second gateway taking over for the first gateway, the third taking over for the second, and so on). If all gateways are unhealthy, the operation fails either open or closed, depending upon your settings. This configuration is generally created and managed through policy. If no forwarding policy applies, you can create a default sequence through the CLI. This single default sequence consists of a single default gateway (or group) plus one or more gateways to use if the preceding ones are unhealthy. The syntax is: sequence alias_list

where alias_list is a space-separated list of one or more SOCKS gateways and group aliases. Example sequence gateway_alias

Creating a SOCKS Gateway Installable List You can create and install the SOCKS gateway installable list with the following methods: ❐

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

❐

Create a local file on your local system; the SG appliance can browse to the file and install it.

❐

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

When the SOCKS gateway installable list is created, it overwrites any previous SOCKS gateway configurations on the SG appliance. The installable list remains in effect until it is overwritten by another installable list; it can be modified or overwritten using Management Console or CLI commands.

196

Chapter 13: SOCKS Gateway Configuration

Section B: Using SOCKS Gateways Directives with Installable Lists

Note: During the time that a SOCKS gateways installable list is being compiled and installed, SOCKS gateways might not be available. Any transactions that come into the SG appliance during this time might not be forwarded properly.

Installation of SOCKS gateways installable-list configuration should be done outside peak traffic times. To create a SOCKS gateway installable list: 1.

Select Configuration > Forwarding > SOCKS Gateways > Install SOCKS Gateway File.

2.

If you use a SOCKS gateway server for the primary or alternate forwarding gateway, you must specify the ID for the Identification (Ident) protocol used by the SOCKS gateway in SOCKS server handshakes. The default is BLUECOAT SYSTEMS.

3.

From the drop-down list, select the method used to install the SOCKS gateway configuration; click Install. •

Remote URL:

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

Local File:

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

Text Editor:

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

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to specify the SOCKS Gateway Machine ID SGOS#(config) socks-machine-id machine_ID

197

Volume 5: Advanced Networking

198

Chapter 14: Health Checks

Blue Coat health checks allow you to determine the availability of external networking devices. This chapter includes the following sections: ❐

Section A: "Overview" on page 200

❐

Section B: "About Blue Coat Health Components" on page 202

❐

Section C: "Configuring Global Defaults" on page 207

❐

Section D: "Forwarding Host and SOCKS Gateways Health Checks" on page 214

❐

Section E: "Editing External Services" on page 218

❐

Section F: "Managing User-Defined Health Checks" on page 221

❐

Section G: "Statistics" on page 227

❐

Section H: "Using Policy" on page 229

❐

Section I: "Related CLI Syntax to Configure Health Checks" on page 230

199

Volume 5: Advanced Networking Section A: Overview

Section A: Overview Health checks are tests run on external resources, such as forwarding hosts, SOCKS gateways, and ICAP and Websense off-box services, to determine status. You can use health checks in conjunction with various failover mechanisms to handle a variety of failure scenarios. For example, you can use health checks with forwarding rules to redirect traffic from one server or proxy to another. If the health check for an individual host fails, the SG appliance can select a healthy host ahead of time or report the failure quickly. Health checks test for: ❐

Network connectivity

❐

Target responsiveness

❐

Basic functionality of the upstream system or service

Health checks fall into three broad categories: ❐

❐

❐

Determining if the IP address can be reached. Health check types that fall into this category are: •

Forwarding hosts

•

SOCKS gateways

•

Dynamic Real-Time Rating (DRTR) service

Determining if a service is responsive. Health check types that fall into this category are: •

ICAP services

•

Websense off-box services

Determining if a group is healthy. Group tests are compilations of individual health checks, and the health of the group is determined by the status of the group members. Health check types that fall into this category are: •

Forwarding groups

•

SOCKS gateway groups

•

ICAP service groups

•

Websense off-box service groups

Note: The health check module has been reorganized. For specific information about the differences between health checks for previous versions and SGOS 5.2, refer to the Blue Coat SGOS 5.x Upgrade Guide.

Health checks always have status. The status of any health check can be referenced in policy as a condition. For more information about using health checks in policy, see Section H: "Using Policy" on page 229.

200

Chapter 14: Health Checks

Section A: Overview

Note: You can run an immediate health check from the Configuration > Health Checks > General > Health Checks tab by selecting the health check and clicking Perform health check. You can also view the health check state on the Statistics > Health Check tab, but you cannot change settings in Statistics.

A number of health checks are automatically generated, based on: ❐

Forwarding configuration

❐

SOCKS gateways configuration

❐

ICAP configuration

❐

Websense off-box configurations

❐

Whether DRTR is enabled

You also can create user-defined health checks, including a composite health check that compiles the results of multiple other health check tests.

Background DNS Resolution Background testing of the DNS resolutions is done on all resolvable hostnames used in the health check system, including forwarding and SOCKS gateways. That way, the list of IP addresses associated with a hostname stays current. The DNS system is checked whenever the time-to-live (TTL) value of the DNS entry expires. Note:

If a hostname consists of a dotted IP address, no DNS resolution is done.

When a host is resolved by DNS to multiple IP addresses, health checks keep those addresses current through background updates, the timing of which you can configure on the Configuration > Health Checks > Background DNS tab. After the test or tests are conducted for each IP address, the results are combined. If the result for any of the resolved IP addresses is healthy, then the host is considered healthy because a healthy connection to that target can be made.

Querying Health Checks A network device can query the state of any health check, automatically generated or user-defined, as long as you know the name of the health check to use as part of the URL. The URL is https://SG_appliance/health_check//test?health_check_name, where SG_appliance is the IP address of the system. If the health check is: ❐

Not found, a 400 (bad request) HTML response is sent

❐

Healthy, a 200 response is sent

❐

Unhealthy, a 404 response is sent

In the latter two cases, a text string is sent back in the HTML response body more precisely describing the state of health.

201

Volume 5: Advanced Networking Section B: About Blue Coat Health Components

Section B: About Blue Coat Health Components Health checks have two components: ❐

❐

Health check type: The kind of device or service the specific health check tests. The following types are supported: •

Forwarding host and forwarding group

•

SOCKS gateway and SOCKS gateway group

•

ICAP service and ICAP service group

•

Websense off-box service and Websense off-box service group

•

DRTR rating service

•

User-defined host and composite

Health check tests: The method of determining network connectivity, target responsiveness, and basic functionality. •

•

Health checks (external targets) •

Internet Control Message Protocol (ICMP)

•

TCP

•

SSL

•

HTTP

•

HTTPS

•

ICAP

•

Websense

•

DRTR rating service

Health checks (group targets) •

Groups

•

Composite

Note: Some health checks (forwarding hosts and SOCKS gateways) can be configured to report the result of some composite health check instead of their own test.

Some health check types only have one matching test, while others have a selection. For more information about health check types and tests, see Table 14-1, “Health Check Tests,” on page 203.

Health Check Types Most health checks are automatically created and deleted when the underlying entity being checked is created or deleted. When a forwarding host is created, for example, a health check for that host is created. Later, if the forwarding host is deleted, the health check for it is deleted as well. User interaction is not required, except to change or customize the health check behavior if necessary.

202

Chapter 14: Health Checks

Section B: About Blue Coat Health Components In addition to the above health checks that are automatically generated, run, and deleted, Blue Coat also supports two kinds of user-defined health checks. These health checks are manually created, configured, and deleted. ❐

Composite health checks: A method to take the results from a set of health checks (automatically generated or user-defined health checks) and combine the results.

❐

Host health checks: A method to test a server, using a selection of ICMP, TCP, SSL, HTTP, and HTTPS tests. Note:

Although a host health check tests an upstream server, it can also be used to test whether a proxy is working correctly. To test HTTP/HTTPS proxy behavior, for example, you can set up a host beyond the proxy, and then use forwarding rules so the health check passes through the proxy to the host, allowing the proxy to be tested. User-defined health checks allow you to test for things that Blue Coat does not test automatically. For example, for a forwarding host, you could do an HTTP test, an HTTPS test, and a TCP test of other ports. Then you can use the composite health check to combine the results of all the tests into one and have that reported as the forwarding host's health. All health check types are given standardized names. If a health check is created automatically by the Blue Coat appliance, names are based on the name of the target. For example: ❐

Forwarding hosts and groups have a prefix of fwd

❐

SOCKS gateways and gateway groups have a prefix of socks

❐

External services have prefixes of icap, ws, and drtr

❐

User-defined or composite health checks have a prefix of user.

Health Check Tests Based on the health check type, the SG appliance periodically tests the health status, and thus the availability, of the host. You can configure the time interval between tests. If the health check test is successful, the appliance considers the host available. The health check tests are described in the table below. Table 14-1. Health Check Tests Health Check Test

Description

Used With Health Check Type

Response Times

The minimum, maximum, and average response times are tracked, with their values being cleared whenever the health check changes state.

All

203

Volume 5: Advanced Networking Section B: About Blue Coat Health Components Table 14-1. Health Check Tests (Continued) Health Check Test

Description

Used With Health Check Type

ICMP Test (Layer 3)

The basic connection between the Blue Coat appliance and the origin server is confirmed. The server must recognize ICMP echoing, and any intervening networking equipment must support ICMP. The Blue Coat appliance sends a ping (three ICMP echo requests) to the host.

Forwarding hosts, SOCKS gateways, or user-defined hosts

ICMP tests do not support policy for SOCKS gateways or forwarding. TCP Socket Connection Test (Layer 4)

A TCP test establishes that a TCP layer connection can be established to a port on the host. Then the connection is dropped. TCP tests for a SOCKS gateway do not support policy for SOCKS gateways or forwarding.

Forwarding hosts, SOCKS gateways, or user-defined hosts

TCP tests for a forwarding host or a user-defined health check support SOCKS gateways policy but not forwarding policy. SSL Test

A connection is made to a target and the full SSL handshake is conducted. Then, much as a TCP test, the connection is dropped.

Forwarding hosts or user-defined hosts

For a forwarding host, a terminating HTTPS port must be defined or the test fails. SSL tests for a forwarding host or a user- defined health check support SOCKS gateways policy. The SSL tests do not support forwarding policy. An SSL test executes the SSL layer in policy and obeys any settings that apply to server-side certificates, overriding any settings obtained from a forwarding host.

204

Chapter 14: Health Checks

Section B: About Blue Coat Health Components Table 14-1. Health Check Tests (Continued) Health Check Test

Description

Used With Health Check Type

HTTP/HTTPS Tests for Servers and Proxies

HTTP/HTTPS tests execute differently depending on whether the upstream target is a server or a proxy. For a forwarding host, the server or a proxy is defined as part of the forwarding host configuration. For a user-defined health check, the target is always assumed to be a server.

Forwarding hosts or user-defined hosts.

For a server: • The HTTP test sends an HTTP GET request containing only the URL path to an HTTP port. • The HTTPS test sends an HTTPS GET request containing only the URL path over an SSL connection to a terminating HTTPS port. If an appropriate port is not available on the target, the test fails. For a proxy: • The HTTP test sends an HTTP GET request containing the full URL to an HTTP port. • Since a server is required to terminate HTTPS, the HTTPS test sends an HTTP CONNECT request to the HTTP port. If an appropriate HTTP port is not available on the proxy, either test fails. An HTTP/HTTPS test requires a full URL for configuration. The HTTP/HTTPS tests for a forwarding host support SOCKS gateway policy but not forwarding policy. The HTTP/HTTPS tests for a user-defined health check support SOCKS gateway and forwarding policy. An HTTPS test executes the SSL layer in policy and obeys any settings that apply to server-side certificates, overriding any settings obtained from a forwarding host. HTTP/HTTPS Authentication

For HTTP/HTTPS tests, you can test authentication using a configured username and password. The passwords are stored securely in the registry.

Forwarding hosts or user-defined hosts.

HTTP/HTTPS Allowed Responses

For an HTTP or HTTPS test, this is the set of HTTP response codes that indicate success. The default is to accept only a 200 response as successful. You can specify the sets of response codes to be considered successful.

Forwarding hosts or user-defined hosts.

External Services Tests

The tests for external services are specialized tests devised for each particular kind of external service. The health check system conducts external service tests by sending requests to the external services system, which reports back a health check result.

ICAP, Websense off-box, DRTR rating service.

205

Volume 5: Advanced Networking Section B: About Blue Coat Health Components Table 14-1. Health Check Tests (Continued) Health Check Test

Description

Used With Health Check Type

Group

Individual tests that are combined for any of the four different available groups (forwarding, SOCKS gateways, ICAP, and Websense off-box). If any of the members is healthy, then the group as a whole is considered healthy.

Forwarding groups, SOCKS gateways groups, and ICAP and Websense off-box external service groups.

Note: Blue Coat supports a composite test, used only with composite (user-defined) health checks, that is similar to a group test except that, by default, all members must be healthy for the result to be healthy. These settings are configurable. By default, group health tests are used for two purposes: • Monitoring and notification • Policy

206

Chapter 14: Health Checks

Section C: Configuring Global Defaults

Section C: Configuring Global Defaults In general, all health checks are initially configured to use global defaults. Note: The DRTR rating service is initially configured to override two of the default settings. The healthy interval is set to 10800 seconds (3 hours), and a failure trigger is set to 1.

About Health Check Defaults You can change the defaults on most health checks. These defaults override global defaults, which are set from the Configuration > Health Checks > General > Default Settings tab. For information about setting or changing defaults, see Section D: "Forwarding Host and SOCKS Gateways Health Checks" on page 214. You can edit health check intervals, thresholds, and notifications for automatically generated health checks, but these health checks are automatically deleted if the health check target is deleted. You can configure health check intervals, thresholds, and notifications two ways: ❐

Setting the global defaults. These settings affect all health checks, unless overridden by explicit settings.

❐

Setting explicit values on each health check.

The default health check values are: ❐

Ten seconds for healthy and sick intervals (an interval is from the completion of one health check to the start of the next health check)

❐

One for healthy and sick thresholds. A healthy threshold is the number of successful health checks before an entry is considered healthy; a sick threshold is the number of unsuccessful health checks before an entry is considered sick

To configure intervals and thresholds, continue with “Changing Health Check Default Settings” on page 208.

Enabling and Disabling Health Checks You can enable or disable health checks and configure them to report as healthy or unhealthy during the time they are disabled. If a group health check is disabled but reporting healthy, all members of the group are treated as healthy regardless of the status of the members’ individual health checks. Note:

Individual health checks for group members are still active; they can be used apart from the group. Setting a health check as disabled but reporting sick is useful to remove an upstream device for servicing, testing, or replacement. This setting takes the device offline after preexisting traffic completes. Then the device can be safely disconnected from the network without altering any other configuration. You cannot enable or disable all health checks at once.

207

Volume 5: Advanced Networking Section C: Configuring Global Defaults

Notifications and SNMP Traps If you configure notifications, e-mail and event log notifications can be sent when a change of health check state occurs. By default, all notifications are disabled. To set notifications, you can change them globally, for all health checks, or explicitly, for specific checks. You can separately enable notifications of transitions to healthy and transitions to sick. A transition to healthy occurs as soon as the target is sufficiently healthy to be sent a request, even though this might not mean complete health. For example, if you have multiple IP addresses resolved and only one (or a few) of them work, that is healthy enough to be classified as healthy. The health can continue to improve. In the event log, state changes can be logged as either informational or severe logs. You can enable notifications for each resolved IP address of a target device (if applicable), in addition to the overall health of the device. An SNMP trap can also be used for notification of health check state changes. It is part of the Blue Coat Management Information Base (MIB) as blueCoatMgmt 7.2.1. To change notifications, continue with “Configuring Health Check Notifications” on page 211.

Changing Health Check Default Settings You can set the default settings for all health checks on the Configuration > Health Checks > General > Default Settings tab or you can override the default settings for a health check by going to Configuration > Health Checks > General > Health Checks tab, selecting the health check, and clicking Edit. Explicit health settings override the global defaults. To change default settings: 1.

Select Configuration > Health Checks > General > Default Settings.

208

Chapter 14: Health Checks

Section C: Configuring Global Defaults 2.

Change the settings as appropriate: a.

Specify the healthy interval, in seconds, between health checks. The default is 10. The healthy interval can be between 1 second and 31536000 seconds

(about one year). b.

Specify the healthy threshold for the number of successful health checks before an entry is considered healthy. Valid values can be between 1 and 65535. The default is 1.

c.

Specify the sick interval, in seconds, between health checks to the server that has been determined to be sick or out of service. The default is 10. The sick interval can be between 1 second and 31536000 seconds (about 1 year).

d. Specify the sick threshold, or the number of failed health checks before an entry is considered sick. Valid values can be between 1 and 65535. The default is 1. e.

Specify the failure threshold for the number of failed connections to the server before a health check is triggered. Valid values can be between 1 and 2147483647. By default, no value is set. The failures are reported back to the health check as a result of either a connection failure or a response error. The number of these external failures is cleared every time a health check is completed. If the number of failures listed meets or exceeds the threshold and the health check is idle and not actually executing, then the health of the device or service is immediately checked.

f.

Specify the maximum response time threshold, in milliseconds. The threshold time can be between 1 and 65535.

3.

Click OK.

4.

Click Apply to commit the changes to the SG appliance.

To override default settings: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the test you want to modify.

3.

Click Edit. The example below uses a SOCKS gateway.

209

Volume 5: Advanced Networking Section C: Configuring Global Defaults

4. 5.

To substitute special values for this test, click Override the default settings. Select the check boxes to override. You can cancel your choices by clicking Clear all overrides.

a.

Specify the healthy interval, in seconds, between health checks to the server. The default is 10. The healthy interval is between 1 second and 31536000 seconds (about one year).

b.

Specify the healthy threshold for the number of successful health checks before an entry is considered healthy. Valid values are 1-65535. The default is 1.

c.

Specify the sick interval, in seconds, between health checks to the server that has been determined to be sick or out of service. The default is 10. The sick interval is between 1 second and 31536000 seconds (about 1 year).

d. Specify the sick threshold, or the number of failed health checks before an entry is considered sick. Valid values are 1-65535. The default is 1.

210

Chapter 14: Health Checks

Section C: Configuring Global Defaults e.

Specify the failure trigger for the number of failed connections to the server before a health check is triggered.Valid values are between 1 and 2147483647. The failures are reported back to the health check as a result of either a connection failure or a response error. The number of these external failures is cleared every time a health check is completed. If the number of failures listed meets or exceeds the threshold, and the health check is idle and not actually executing, then the health of the device or service is immediately checked.

f.

Specify the maximum response time threshold, in milliseconds. The threshold time can be between 1 and 65535.

6.

Click OK.

7.

Click Apply to commit the changes to the SG appliance.

Configuring Health Check Notifications By default, notifications of health check events and status are disabled. You can set up health check notifications globally, on the Configuration > Health Checks > General > Default Notifications tab, or explicitly by going to the Configuration > Health Checks > General > Health Checks tab, selecting the health check, and clicking Edit. Explicit health settings override the global defaults. To configure health check notifications globally: 1.

2.

Select Configuration > Health Checks > General > Default Notifications.

Select the check boxes to enable notifications. a.

E-mail notification: Select the appropriate check boxes to enable the email notifications you require. Recipients are specified in Maintenance > Event Logging > Mail.

b.

Event logging: Select the appropriate check boxes to enable the event logging

you require. Messages can be logged as either informational or severe. c.

SNMP traps: Select the situations for which you require SNMP traps to be

sent. 3.

Click Apply to commit the changes to the SG appliance.

211

Volume 5: Advanced Networking Section C: Configuring Global Defaults To override health check notification default settings: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the test you want to modify.

3.

Click Edit. The example below uses a forwarding host.

4.

To change default notifications for this test, click Override the default notifications. By default, notifications are not sent for any health checks.

5.

Select the check boxes to override. You can cancel your choices by clicking Clear all overrides.

212

Chapter 14: Health Checks

Section C: Configuring Global Defaults a.

Override E-mail notification: Select the appropriate check boxes to enable the email notifications you required. Specify recipients in Maintenance > Event Logging > Mail.

b.

Event logging: Select the appropriate check boxes to enable the event logging

you need. Messages can be logged as either informational or severe. c.

SNMP traps: Select the situations in which you want SNMP traps to be sent.

d. Click OK. e. 6.

Click OK.

Click Apply to commit the changes to the SG appliance.

213

Volume 5: Advanced Networking Section D: Forwarding Host and SOCKS Gateways Health Checks

Section D: Forwarding Host and SOCKS Gateways Health Checks Before you can edit forwarding or SOCKS gateways health check types, you must configure forwarding hosts or SOCKS gateways. For information about configuring forwarding, see Chapter 8: "Configuring the Upstream Network Environment" on page 101; for information about configuring SOCKS gateways, see Chapter 13: "SOCKS Gateway Configuration" on page 183. This section discusses managing automatically generated health checks. To create health checks using the user-defined health check type, continue with Section F: "Managing User-Defined Health Checks" on page 221.

Forwarding Hosts and SOCKS Gateways Configurations The forwarding host health check configuration defines whether the target being tested is a server or a proxy, which ports are available, and provides the setting for the server certificate verification. The SOCKS gateways health check configuration defines the SOCKS port, the version (4 or 5), and possibly a username and password.

Forwarding Hosts Health Checks The default for a newly created forwarding host is a TCP health check using the first port defined in the forwarding host's port array (typically the HTTP port). You can change the port setting. The TCP test can support forwarding policy ( SOCKS gateways policy).The URL uses the forwarding host hostname, such as tcp://:/.

SOCKS Gateways Health Checks The default for a newly created SOCKS gateway is a TCP health check using the SOCKS port in the SOCKS gateways configuration.

Forwarding and SOCKS Gateways Groups Health Checks Specific tests are not done for groups. Health check test results are determined from examining and combining the health of the group members. Note:

You can create groups in the Configuration > Forwarding > Forwarding Hosts tab or Configuration > Forwarding > SOCKS Gateways tab. By default, if any of the members of the group are healthy, then the group is considered healthy. You can specify the number of group members that must be healthy for the group to be considered healthy.

Configuring Forwarding and SOCKS Gateways Health Checks You can edit, but not delete, the automatically generated forwarding tests and groups. You can create, edit, copy, and delete user-defined tests.

214

Chapter 14: Health Checks

Section D: Forwarding Host and SOCKS Gateways Health Checks

Editing Automatically Generated Tests for Forwarding and SOCKS Gateways The settings you can change on automatically generated forwarding hosts, SOCKS gateways, and forwarding and SOCKS gateways group tests are: ❐

Enabled state

❐

Override default notifications

❐

Type of test

❐

Settings specific to the type of test

❐

Override default settings

❐

Minimum number of healthy group members

To edit automatically generated forwarding and SOCKS gateways tests: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the forwarding host test or SOCKS gateways test to modify.

3.

Click Edit.

4.

Make the necessary changes: a.

Select the Type of Test from the drop-down list.

b.

Select the Enabled state radio button as required.

215

Volume 5: Advanced Networking Section D: Forwarding Host and SOCKS Gateways Health Checks c.

Select the port setting you require. If you select Use Port, enter the new port number.

d. To change the default settings for this test, click Override the default settings.

e.

f. 5.

•

Select the check boxes to override. Cancel your choices by clicking Clear all overrides. For detailed information about configuring healthy and sick intervals and thresholds, see “Changing Health Check Default Settings” on page 208.

•

Click OK.

To change default notifications, click Override the default notifications. By default, no notifications are sent for any health checks. •

Select the check boxes to override. You can cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211.

•

Click OK .

Click OK.

Click Apply to commit the changes to the SG appliance.

To edit automatically generated forwarding or SOCKS gateway group tests: Note: The only way to add or delete group members to the automatically generated health check tests is to add and remove members from the actual forwarding or SOCKS gateway group. The automatically generated health check is then updated.

1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the forwarding or SOCKS gateways group health check you need to modify.

3.

Click Edit.

4.

Make the necessary changes: a.

Select the Enabled state radio button as required.

216

Chapter 14: Health Checks

Section D: Forwarding Host and SOCKS Gateways Health Checks b.

Select the Minimum number of users that must be healthy for group to be healthy from the drop-down list.

c.

To create notification settings, click Override the default notifications. •

Select the check boxes. Cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211.

•

Click OK.

d. Click OK. 5.

Click Apply to commit the changes to the SG appliance.

217

Volume 5: Advanced Networking Section E: Editing External Services

Section E: Editing External Services External Services include ICAP, Websense off-box, and the DRTR rating service. While external service health checks are created and deleted automatically, the service itself must be created before health checks can be used. For more information about creating ICAP and Websense off-box services, refer to Volume 7: Managing Content. The DRTR rating service is automatically created if you use Blue Coat Web Filter (BCWF) and have the rating service enabled. Note: The names of the ICAP and Websense off-box services and service groups can be a maximum of 64 characters long, a change from previous releases, which allowed names to be a maximum of 127 characters. If a previously existing name exceeds 64 characters, the service or service group continues to function normally but no corresponding health check type is created.

The tests for each of the external services are specialized tests devised for each particular kind of external service. The health check system conducts external service tests by sending requests to the external services system, which reports back a health check result. Note: You can run a health check on any health check on the Configuration > Health Checks > General > Health Checks tab by selecting the health check and clicking Perform health check.

The settings you can change on automatically generated ICAP, Websense off-box, and DRTR rating service tests are: ❐

Enabled state

❐

Override default settings

❐

Override default notifications

To edit automatically generated external services tests: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the external service to modify. External services have prefix names of drtr, icap, and ws.

3.

Click Edit.

218

Chapter 14: Health Checks

Section E: Editing External Services

4.

Make the necessary changes: a.

Change the Enabled state radio button as required.

b.

(Websense only): If you do not want to use the default URL, select the Use user defined URL option and enter the test URL to use.

c.

To change default settings, click Override the default settings. •

Select the check boxes to override. Cancel your choices by clicking Clear all overrides. For detailed information about configuring healthy and sick intervals and thresholds, see “Changing Health Check Default Settings” on page 208. Note:

DRTR has settings that differ from the defaults for other external services: 10800 seconds (3 hours) for the interval, and 1 for the failure trigger. •

Click OK.

d. To change default notifications, click Override the default notifications. By default, no notifications are sent for any health checks.

e. 5.

•

Select the check boxes. Cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211.

•

Click OK.

Click OK.

Click Apply to commit the changes to the SG appliance.

219

Volume 5: Advanced Networking Section E: Editing External Services To edit automatically generated Websense off-box or ICAP group tests: Note: The only way to add or delete group members to the automatically generated health check tests is to add and remove members from the ICAP or Websense off-box services. The automatically generated health check type is then updated.

1. 2.

Select Configuration > Health Checks > General > Health Checks. Select the external service group health check to modify. Groups are identified in the Type column.

3.

Click Edit.

4.

Make the necessary changes: a.

Select the Enabled state radio button as required.

b.

Select the Minimum number of users that must be healthy for group to be healthy from the drop-down list. The default is that one member of the group

c.

To create notification settings, click Override the default notifications.

must be healthy. •

Select the check boxes. Cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211.

•

Click OK.

d. Click OK. 5.

Click Apply to commit the changes to the SG appliance.

220

Chapter 14: Health Checks

Section F: Managing User-Defined Health Checks

Section F: Managing User-Defined Health Checks You can manually create and manage ICMP, TCP, HTTP/HTTPS, or SSL health check tests for any upstream TCP/IP device. You can use these user-defined health check types to send notifications of health check state changes. The composite check is made up of any set of checks, including other composite health checks, health checks for user defined hosts, and any automatically generated health checks. Under most circumstances, you do not need to create user-defined health checks; the automatically generated health checks meet most needs, and you can modify the default sick/healthy parameters, change the default test type, or add notification settings. For information about configuring parameter and notification settings for automatically generated health check types, see Section C: "Configuring Global Defaults" on page 207. However, you might need tests to check for things that Blue Coat does not test automatically. For example, you can control traffic based on the apparent health of the Internet. Using user-defined health check types, you can target known Internet sites, accepting that so long as a certain number of the sites are healthy, then the Internet is considered healthy. Note:

Frequent testing of specific Internet sites by a large number of systems can result in that Internet site objecting to the number of hits. Blue Coat supports two types of user-defined health checks: ❐

Host: This health check type is for any upstream TCP/IP device. For more information, continue with the next section.

❐

Composite: This health check type is meant to compile the results of any kind of health check. For more information, continue with “About User-Defined Composite Health Checks” on page 222.

About User-Defined Host Health Checks You can create, configure, and delete user-defined host health checks are health checks. These health checks support everything an automatically generated health check contains, including background DNS resolution monitoring and support for multiple addresses. User-defined host health check tests can include: ❐

ICMP: The basic connection between the Blue Coat appliance and the origin server is confirmed. The server must recognize ICMP echoing, and any intervening networking equipment must support ICMP.

❐

TCP: Establishes that a TCP layer connection can be made to a port on the host. Then the connection is dropped.

❐

SSL: A connection is made to a target and the full SSL handshake is confirmed. Then the connection is dropped.

❐

HTTP/HTTPS: An HTTP or HTTPS test is defined by the URL supplied. The port used for this test is as specified in that URL. If no port is explicitly specified in the URL, the port defaults to the standard Internet value of 80 or 443.

221

Volume 5: Advanced Networking Section F: Managing User-Defined Health Checks When configuring user-defined host health check types, keep in mind the following: ❐

User-defined host health checks are created and deleted manually.

❐

All individual user-defined tests consider the target to be a server.

❐

To conduct proxy HTTP/HTTPS tests, a proxy must be defined as a forwarding host, set up between the originating device and the target, and forwarding policy must cause the test to be directed through the proxy.

❐

For an ICMP test, a hostname is specified in the health check configuration.

❐

The TCP and SSL tests support SOCKS gateway policy, based on a URL of tcp:// :/ and ssl://:/, respectively, using a hostname and port supplied in health check configuration.

❐

An HTTP/HTTPS test requires a full URL. The port used for this test is as specified in that URL. If no port is explicitly specified in the URL, the port defaults to the standard value for these protocols of 80 or 443. The server being tested is assumed to support whatever port is indicated. Forwarding and SOCKS gateway policy is applied based on the URL. The HTTPS or SSL tests use all the server certificate settings in the SSL layer in policy. For a forwarding host, all the sever certificate settings in the SSL layer also apply, and if present, override the forwarding host configuration setting. Note:

None of the above tests apply to user-defined composite health checks, which only consist of a set of members and a setting to combine the results.

About User-Defined Composite Health Checks User-defined composite health checks can be used to collect together a set of health checks. You can define a composite health check that is made up of the results of other existing health checks. The forwarding host and SOCKS gateway health checks can have a test that references the result of some composite health check. The composite health check allows you to combine results of tests of one device or tests of multiple devices. You can also define how many member health checks must be healthy for the composite result to be considered healthy. By default, all members of composite tests must be healthy for the combination to be healthy. User-defined composite health checks with no members always appear unhealthy. Note: Automatically generated group tests and user-defined composite tests are not the same.

Group tests are automatically generated; they cannot be deleted. Some editing is permitted, but you cannot add or remove members of the group through the health checks module (you must modify the forwarding or SOCKS gateways groups to update the automatically generated group tests). For a group's test, the default is for the group to be healthy if any member is healthy. For a composite’s test, the default is for the group to be healthy if all members are healthy. (The default is configurable.)

222

Chapter 14: Health Checks

Section F: Managing User-Defined Health Checks

Creating User-Defined Host and Composite Health Checks You can create user-defined host and composite health checks for arbitrary targets. Note:

You cannot create user-defined health checks for external service tests, such as ICAP, Websense off-box, and the DRTR rating service. The following procedure explains how to create a user-defined host health check. To create a user-defined composite health check, continue with “To create a user-defined composite health check:” on page 224. To create a user-defined host health check: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Click New.

3.

Select the type of test to configure from the Type of test drop-down list. To configure a composite test, see “To create a user-defined composite health check:” on page 224.

223

Volume 5: Advanced Networking Section F: Managing User-Defined Health Checks The options you can select vary with the type of health check. The example above uses the HTTP/HTTPS options. Options for other tests are explained in this procedure, as well. a.

Enter a name for the health check.

b.

Select the Enabled state radio button to the required setting.

c.

If you are configuring an SSL or TCP health check, enter the port to use.

d. If you are configuring an ICMP, SSL, or TCP health check, enter the hostname of the health check’s target. e.

For HTTP/HTTPS only: •

Enter the URL address of the target.

•

To use Basic user authentication, select the check box and enter the username and password of the target.

•

To use Basic proxy authentication because intermediate proxies might be between you and the target, select the check box and enter the username and password of the target.

•

To manage a list of HTTP/HTTPS response codes that are considered successes, enter the list in the Allowed Response Code field, separated by semi-colons. If one of them is received by the health check then the health check considers the HTTP(S) test to have been successful. Note:

The 200 response code is added by default. The list must always have at least one member. f.

g.

To change the default settings for this test, click Override the default settings. •

Select your override settings. Cancel your choices by clicking Clear all overrides. For detailed information about configuring healthy and sick intervals and thresholds, see “Changing Health Check Default Settings” on page 208.

•

Click OK.

To change the default notifications for this test, click Override the default notifications. By default, no notifications are sent for any health checks. •

Select the check boxes to override. You can cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211

•

Click OK.

h. Click OK. 4.

Click Apply to commit the changes to the SG appliance.

To create a user-defined composite health check: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Click New.

224

Chapter 14: Health Checks

Section F: Managing User-Defined Health Checks

3.

Make the necessary changes: a.

Select Composite from the Type of Test from the drop-down list.

b.

Select the Enabled state radio button as required.

c.

Select the Minimum number of members that must be healthy for the group to be healthy from the drop-down list. The default is All.

d. Add the health check members to the composite test from the Available Aliases list by selecting the health check to add and clicking Add to move the alias to the Selected Alias list. e.

f. 4.

To change the default notifications for this test, click Override the default notifications. By default, no notifications are sent for any health checks. •

Select the check boxes to override. You can cancel your choices by clicking Clear all overrides. For detailed information about configuring notifications, see “Configuring Health Check Notifications” on page 211

•

Click OK.

Click OK.

Click Apply to commit the changes to the SG appliance.

225

Volume 5: Advanced Networking Section F: Managing User-Defined Health Checks

Copying and Deleting User-Defined Health Checks Only user-defined health checks can be copied and deleted. Automatically generated health checks cannot be copied or deleted. ❐

❐

If the source health check is user-defined host or a composite and the target alias name does not exist: •

A new health check of the same kind with that alias name is created

•

The new health check has identical configuration settings to the source health check.

If the target alias does exist and the target is of the same kind (that is, both are userdefined hosts or both are composite), then the complete configuration is copied from the source to the target.

To copy or delete user-defined host or composite health checks: 1.

Select Configuration > Health Checks > General > Health Checks.

2.

Select the user-defined host or composite health check to copy.

3.

Click Copy.

If the target does not match the source type, the copy operation fails and sends an error message.

226

Chapter 14: Health Checks

Section G: Statistics

Section G: Statistics You can view but not edit the health check state from the Statistics > Health Check tab. To manage health checks, go to the Configuration > Health Checks > General tab. To view the health check state: Select Statistics > Health Check.

Table 14-2. Status Messages for Health Checks Status Message

Description

Health State

Unknown health

Health has not yet been tested successfully.

Healthy

Functioning properly

The target device or service is completely healthy.

Healthy

Functioning with errors (multiple IP addresses)

One or more IP addresses have errors but none are down.

Healthy

Functioning only for some addresses (multiple IP addresses)

One or more IP addresses are down but not all.

Healthy

Functioning but going down (single IP address)

Failures are occurring, but the IP address is not yet down.

Healthy

Health check failed

Device or service cannot be used.

Sick

DNS resolution failed

The hostname cannot be DNS resolved.

Sick

227

Volume 5: Advanced Networking Section G: Statistics In addition to status messages, you can see whether the health check is enabled. Enabled states are: ❐

Enabled

❐

Disabled, reporting success

❐

Disabled, reporting failure

228

Volume 5: Advanced Networking Section H: Using Policy

Section H: Using Policy The results of a health check can be affected through forwarding, SOCKS gateway, or SSL certificate policy. The health check transactions execute the layer and (for SSL or HTTPS tests) the layer to determine applicable policy. This allows health check behavior to match as closely as possible that of the SSL traffic that the health check is monitoring. Health checks cannot be deleted while referenced in policy. If a health check is automatically deleted when its target is deleted, a reference to the health check in policy can block deletion not only of the health check but of its target. Two policy conditions exist for health checks: ❐

health_check= This condition tests whether the current transaction is a health check transaction. Optionally, the condition tests whether the transaction is that of a specific health check.

❐

is_healthy.health_check_name= This condition tests whether the specified health check is healthy.

For more information about using policy, refer to Volume 6: VPM and Advanced Policy and Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

229

Volume 5: Advanced Networking Section I: Related CLI Syntax to Configure Health Checks

Section I: Related CLI Syntax to Configure Health Checks ❐

To enter health check mode: SGOS#(config) health-check SGOS#(config health-check) Note:

For detailed information about using these commands, refer to Volume 11: Command Line Reference. ❐

The following subcommands are available: SGOS#(config health-check) copy source-alias target-alias SGOS#(config health-check) create {composite alias_name | http alias_name url | https alias_name url | icmp alias_name hostname| ssl alias_name hostname [port]| tcp alias_name hostname [port]} SGOS#(config health-check) default e-mail {healthy {enable |disable} | report-all-ips {enable | disable} | sick {enable | disable}} SGOS#(config health-check) default event-log {healthy {enable |disable} | report-all-ips {enable | disable} | sick {enable | disable}} SGOS#(config health-check) default failure-trigger {none | count} SGOS#(config health-check) default interval {healthy seconds| sick seconds} SGOS#(config health-check) default snmp {healthy {enable |disable} | report-all-ips {enable | disable} | sick {enable | disable}} SGOS#(config health-check) default threshold {healthy count | response-time milliseconds | sick count} SGOS#(config health-check) delete alias_name SGOS#(config health-check) disable {healthy alias_name | sick alias_name} SGOS#(config health-check) edit composite_health_check (config health-check user.composite_health_check) subcommands SGOS#(config health-check) edit drtr.test_name (config health-check drtr.test_name) subcommands SGOS#(config health-check) edit fwd.group_name (config health-check fwd.group_name) subcommands SGOS#(config health-check) edit fwd.host_name (config health-check fwd.host_name) subcommands SGOS#(config health-check) edit health_check_name (config health-check user.health_check_name) subcommands SGOS#(config health-check) edit icap.test_name (config health-check icap.test_name) subcommands SGOS#(config health-check) edit socks.test_name (config health-check socks.test_name) subcommands SGOS#(config health-check) edit ws.test_name (config health-check ws.test_name) subcommands SGOS#(config health-check) edit ws.group_name (config health-check ws.group_name) subcommands SGOS#(config health-check) enable alias_name SGOS#(config health-check) exit

230

Volume 5: Advanced Networking Section I: Related CLI Syntax to Configure Health Checks SGOS#(config health-check) perform-health-check alias_name SGOS#(config health-check) view {configuration | quick-statistics | statistics}

231

Volume 5: Advanced Networking Section I: Related CLI Syntax to Configure Health Checks

232

Chapter 15: TCP/IP Configuration

Use the TCP/IP configuration options to enhance the performance and security of the SG appliance. Except for IP Forwarding (refer to Volume 2: Proxies and Proxy Services), these commands are only available through the CLI. ❐

RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and longdelay operation of the SG appliances over very high-speed paths, ideal for satellite environments.

❐

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

❐

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

❐

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

❐

TCP Window Size: Configures the amount of unacknowledged TCP data that the SG appliance can receive before sending an acknowledgement.

❐

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

To view the TCP/IP configuration, see “Viewing the TCP/IP Configuration” on page 236. This section discusses ❐

"RFC-1323" on page 233

❐

"TCP NewReno" on page 234

❐

"ICMP Broadcast Echo Support" on page 234

❐

"ICMP Timestamp Echo Support" on page 234

❐

"TCP Window Size" on page 235

❐

"PMTU Discovery" on page 235

❐

"TCP Time Wait" on page 235

❐

“TCP Loss Recovery Mode” on page 236

❐

"Viewing the TCP/IP Configuration" on page 236

RFC-1323 The RFC-1323 TCP/IP option enables the SG appliance 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. RFC1323 support can be configured through the CLI and is enabled by default.

233

Volume 5: Advanced Networking To enable or disable RFC-1323 support: 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 enabled by default. To enable or disable TCP NewReno support: 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 SG appliance from participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service (DoS) attack, where the attacker sends an ICMP echo request packet to an IP broadcast address. This is the same type of packet sent in the ping command, but the destination IP is broadcast instead of unicast. If all the hosts on the network send echo reply packets to the ICMP echo request packets that were sent to the broadcast address, the network is jammed with ICMP echo reply packets, making the network unusable. By disabling ICMP broadcast echo response, the SG appliance does not participate in the Smurf Attack. This setting is disabled by default. To enable or disable ICMP broadcast echo support: 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 Chapter 3: "Attack Detection" on page 53.

ICMP Timestamp Echo Support By disabling the ICMP timestamp echo commands, you can prevent an attacker from being able to reverse engineer some details of your network infrastructure. For example, disabling the ICMP timestamp echo commands prevents an attack that occurs when the SG appliance 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: At the (config) command prompt, enter the following command: SGOS#(config) tcp-ip icmp-timestamp-echo {enable | disable}

234

Chapter 15: TCP/IP Configuration

TCP Window Size Adjusting the TCP window-size regulates the amount of unacknowledged data that the SG appliance receives before sending an acknowledgement. To configure the TCP window size: At the (config) command prompt, enter the following command: SGOS#(config) tcp-ip window-size window_size

where window_size indicates the number of bytes allowed before acknowledgement (the value must be between 8192 and 4194304).

PMTU Discovery PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the largest packet size sent that is not fragmented anywhere along the path between two communicating appliances that are not directly attached to the same link. An SG appliance 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. An SG appliance 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 SG appliance, 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 SG appliance. The first SG appliance then reduces the PMTU size and retransmits the transmissions. The discovery period temporarily ends when the SG appliance estimates the PMTU is low enough that its packets can be delivered without fragmentation or when the SG appliance stops setting the Do-Not-Fragment bit. 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. To configure PMTU discovery: At the (config) command prompt: SGOS#(config) tcp-ip pmtu-discovery enable | disable

TCP Time Wait When a TCP connection is closed (such as when a user enters quit for an FTP session), the TCP connection remains in the TIME_WAIT state for twice the Maximum Segment Lifetime (MSL) before completely removing the connection control block. The TIME_WAIT state allows an end point (one end of the connection) to remove remnant packets from the old connection, eliminating the situation where packets from a previous connection are accepted as valid packets in a new connection. The MSL defines how long a packet can remain in transit in the network. The value of MSL is not standardized; the default value is assigned according to the specific implementation.

235

Volume 5: Advanced Networking

To change the MSL value, enter the following commands at the (config) command prompt: SGOS#(config) tcp-ip tcp-2msl seconds

where seconds is the length of time you chose for the 2MSL value. Valid values are 1 to 16380 inclusive.

TCP Loss Recovery Mode A new TCP algorithm helps to recover throughput efficiently after packet losses occur and also addresses performance problems due to a single packet loss during a large transfer over long delay pipes. The feature is enhanced by default. To enable the algorithm: SGOS#(config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive}

To disable the algorithm: SGOS#(config) tcp-ip tcp-loss-recovery-mode {normal}

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: TCP 2MSL timeout: TCP window size: TCP Loss Recovery Mode:

enabled disabled disabled disabled disabled disabled 120 seconds 65535 bytes Aggressive

236

Chapter 16: Virtual IP Addresses

Virtual IP (VIP) addresses are addresses assigned to a system (but not an interface) that are recognized by other systems on the network. Up to 255 VIPs can be configured on each SG appliance. They have several uses: ❐

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

❐

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

❐

Direct authentication challenges to different realms.

❐

Set up failover among multiple SG appliances on the same subnet.

Note: For information on creating an HTTPS Console, refer to Volume 2: Proxies and Proxy Services; for information on using VIPs with authentication realms, refer to Volume 4: Securing the Blue Coat SG Appliance; to use VIPs with failover, see Chapter 7: "Configuring Failover" on page 97.

To create a VIP: 1.

Select Configuration > Network > Advanced > VIPs.

2.

Click New.

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: You cannot create a VIP address that is the IP address used by the origin content server. You must assign a different address on the SG appliance, and use DNS or forwarding to point to the origin content server's real IP address.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

The VIP address can now be used. Related CLI Syntax to manage a VIP SGOS#(config) virtual address ip_address SGOS#(config) virtual no address ip_address SGOS#(config) virtual clear SGOS#(config) show virtual

237

Volume 5: Advanced Networking

238

Chapter 17: WCCP Settings

The SGOS software can be configured to participate in a WCCP (Web Cache Control Protocol) scheme, in which a WCCP-capable router collaborates with a set of WCCPconfigured SG appliances to service requests.

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

❐

Redirection safeguards. If no appliances are available, redirection stops and the router forwards traffic to the original destination address.

WCCP has two versions, version 1 and version 2, both of which are supported by Blue Coat. However, only one protocol version can be active on the SG appliance at a time. The active WCCP protocol set up in the SG configuration file must match the version running on the WCCP router. For information on using WCCP Version 1, see Appendix C: "Using WCCP" on page 267.

Using WCCP and Transparent Redirection A WCCP-capable router operates in conjunction with the appliances to transparently redirect traffic to a set of caches that participate in the specified WCCP protocol. IP packets are redirected based on fields within each packet. For instance, WCCP version 1 only redirects destination TCP port 80 (default HTTP traffic) IP packets. WCCP version 2 allows you to redirect traffic from other ports and protocols. Load balancing is achieved through a redirection hash table to determine which SG appliance receives the redirected packet.

WCCP Version 2 For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 12.0(4). Release 12.0(5) and later releases support WCCP versions 1 and 2. Ensure that you use the correct IOS software for the router and that you have a match between the SG configuration WCCP version number and router protocol version number. WCCP version 2 protocol offers the same capabilities as version 1, along with increased protocol security and multicast protocol broadcasts. Version 2 multicasting allows caches and routers to discover each other through a common multicast service group and matching passwords. In addition, up to 32 WCCP-capable routers can transparently redirect traffic to a set of up to 32 appliances. Version 2 WCCP-capable routers are capable of redirecting IP traffic to a set of appliances based on various fields within those packets.

239

Volume 5: Advanced Networking

Version 2 allows routers and caches to participate in multiple, simultaneous service groups. Routers can transparently redirect IP packets based on their formats. For example, one service group could redirect HTTP traffic and another could redirect FTP traffic. Note: Blue Coat recommends that WCCP-compliant caches from different vendors be kept separate and that only one vendor’s routers be used in a service group.

One of the caches participating in the WCCP service group is automatically elected to configure the home router’s redirection tables. This way, caches can be transparently added and removed from the WCCP service group without requiring operator intervention. WCCP version 2 supports multiple service groups. The figure below illustrates a WCCP version 2 implementation using multiple routers and appliances. In this scenario, routers 1 through n and caches 1 through m participate in the same service group. As in version 1, an appliance from the group is selected to define the redirection hash table in all routers for all caches. All caches periodically communicate with all routers to verify WCCP protocol synchronization and appliance and router availability within the service group. In return, each router responds to caches with information as to what caches and discovered routers are available in the service group.

Figure 17-1. A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches

Procedure Overview Two tasks must be completed to get WCCP running: ❐

Configuring the router

❐

Configuring the SG appliance

To do initial router configuration: 1.

From the router (config) mode, tell WCCP which service group you want use. The Web-cache service group redirects port 80 (HTTP) traffic only. Router(config) #ip wccp web-cache

2.

Enter the (config-if) submode by telling WCCP which IP address to use. Router(config)# int interface

where interface is the adapter interface with an IP address. The prompt changes to configuration interface submode.

240

Chapter 17: WCCP Settings

3.

Enable packet redirection on an outbound (Internet facing) interface. Router(config-if)# ip wccp web-cache redirect out

4.

Prevent packets received on an adapter interface from being checked for redirection

and allow the use of Blue Coat bypass lists. Router(config-if)# ip wccp redirect exclude in

For more information on WCCP router configuration, see “Configuring a WCCP Version 2 Service on the Router” on page 270. To create an SG appliance WCCP configuration file and enable WCCP: 1.

Create a WCCP configuration file through either the SG appliance’s CLI inline commands or through a text editor. Make sure that the home router you enter here is the home router that was named in the router’s configuration. If you do have a mismatch, you must correct it before continuing. See “Identifying a Home Router/ Router ID Mismatch” on page 281. For more information on creating a configuration file, see “Creating an SG Appliance WCCP Configuration File” on page 241. If you used the inline commands, you have completed WCCP configuration for both the router and the SG appliance and you have enabled WCCP on the SG appliance. No further steps are needed.

2. 3.

If you used a text editor, copy the file to an HTTP server accessible to the SG appliance. Enable WCCP and download the configuration file to the SG appliance. SGOS#(config) wccp enable SGOS#(config) wccp path http://205.66.255.10/files/wccp.txt SGOS#(config) load wccp-settings Note: You can also use the Management Console > Configuration > Network > Advanced > WCCP to install the WCCP configuration file and enable WCCP.

The rest of this chapter discusses the SG appliance WCCP configuration file. For detailed information on using WCCP, see Appendix C: "Using WCCP" on page 267.

Creating an SG Appliance WCCP Configuration File Once you have the router global and adapter interface settings complete, you must create a WCCP configuration file for the SG appliance. Note:

The appliance does not ship with a default WCCP configuration file.

These configurations should include the following: ❐

Identify the service group.

❐

Identify the queuing priorities for all defined service groups.

❐

Identify the protocol.

❐

Load balancing caches in a service group.

❐

Identify ports.

❐

Identify the home router as defined in the router configuration.

241

Volume 5: Advanced Networking

❐

Identify the packet forwarding method.

Before you can install the WCCP configuration, you must create a WCCP configuration file for the SG appliance. The appliance does not ship with a default WCCP configuration file.

Understanding Packet Forwarding By default, Cisco’s GRE encapsulation (Generic Routing Encapsulation) is used to forward packets from the WCCP router to the caches. If you have a version 2 WCCP router, you can alternatively use Layer 2 (L2) rewrites to forward packets, which is faster than GRE and saves network bandwidth. Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header. Using L2, redirected packets are not encapsulated; the MAC address of the target cache replaces the packet’s destination MAC address. This different way of directing packets saves you the overhead of creating the GRE packet at the router and decoding it at the cache. Also, it saves network bandwidth that would otherwise be consumed by the GRE header. The SG appliance also supports the L2 packet return method if the router software does. In this release, the packet return method always matches the packet forward method. If you want to continue using GRE, you need not change any settings. To use L2 packet redirection, you must add the forwarding option to the SG configuration file. If WCCP version 2 is supported, the router sends out a list of forwarding mechanisms supported by the router in the first WCCP2_I_SEE_YOU message. The cache responds with a WCCP2_HERE_I_AM message. If the router does not send the list, the cache aborts its attempt to join the WCCP service group. If the method of forwarding mechanism is not supported by the router, the WCCP2 messages from the cache are ignored. Caveats for using L2 redirection: ❐

You must use WCCP version 2.

❐

If a cache is not connected directly to a router, the router does allow the cache to negotiate the rewrite method.

❐

The same rewrite method must be used for both packet forwarding and packet return.

Understanding Cache Load Balancing If you use WCCP version 2, you can balance the load on the caches in a service group. When a router receives an IP packet for redirection, it hashes fields within the packet to yield an index within the hash table. The packet then is forwarded to the owner SG appliance for servicing. The proportion of redirection hash table assigned to each SG appliance can be altered to provide a form of load balancing between caches in a service group. A hash table is configured by a dynamically elected SG appliance participating in a service group, enabling the simultaneous interception of multiple protocols on multiple ports. You can configure up to 100 dynamic or standard service groups plus standard service groups. A single service can intercept up to eight port numbers. Each element in this 256-entry hash table refers to an active SG appliance within the service group. By default, each SG appliance is assigned roughly an even percentage of the 256-element redirection hash table. Multiple network cards within an SG appliance can participate in the same service group. To the routers and other caches, each adapter interface appears as a unique cache. Using this strategy, redirected traffic can be better distributed among network interfaces in a cache.

242

Chapter 17: WCCP Settings

Using Figure 17-2, below, all caches would be assigned 1/m of the redirection hash table, but since Cache 2 and Cache 3 are physically located within the same appliance, that appliance is actually assigned 2/m of the redirection hash table.

Figure 17-2. A Version 2 Configuration Using Multicast Packet Redirection to Multiple Routers, Multiple Caches, and a Service Group

Assigning Percentages You can override the default of each SG appliance being assigned roughly an even percentage; the relative distribution of the redirection hash table can be specified for each cache. Multiple hash-distributions are supported. Also, all, none, or part of a source and/ or destination IP address or port number can be used in the hash. Each SG appliance can be assigned a primary-hash-weight value to determine the proportion of the 256-element hash table to be assigned. If all caches are configured with a 0 primary-hash-weight value (the default) then each SG appliance is assigned an equal proportion of the redirection hash table. However, if any SG appliance is configured with a non-zero primary-hash-weight, each SG appliance is assigned a relative proportion of the table. For instance, consider a configuration with five caches that use a primary-hash-weight defined as {25, 200, 0, 50, 25}. The total requested weight value is 25+200+0+50+25=300 and, therefore, the proportion of the hash table assigned to each SG appliance is 25/300, 200/300, 0/300, 50/300, and 25/300. Because one cache did not specify a non-zero primary-hash-weight, that cache is assigned any elements within the redirection hash table and, therefore, does not receive any redirected traffic. Also, the hash weight can be specified for each caching member within a SG appliance. In Figure 17-2, Cache 2 and Cache 3 can be assigned different weight values.

Alternate Hash Table In some cases, a Web site becomes an Internet hot spot, receiving a disproportional number of client traffic relative to other sites. This situation can cause a larger request load on a specific SG appliance because the hash element associated with the popular site receives more activity than other hash elements.

243

Volume 5: Advanced Networking

To balance the redirection traffic load among the caches, a service group can be configured to use an alternate hash function when the number of GRE packets forwarded to the cache exceeds a certain number. (If you use L2 forwarding, the SG appliance counts MAC addresses.) Therefore, when a router receives an IP packet that hashes to an element flagged as a hot spot, the alternate hash function is computed. The appliance specified by the new index in the redirection hash table receives the redirected packet. Each SG appliance can dynamically determine a hot spot within its assigned portion of the redirection hash table. Alternate hash tables are only used for dynamic service groups that specify alternate-hash flags within their service-flags. The default Web-cache service group cannot use an alternate hash table. Instead, a comparable dynamic service group must be created. To use hot spot detection, the SG appliance’s WCCP configuration file must specify: service-flags source-ip-hash service-flags destination-port-alternate-hash

Creating a Configuration File An example of a file using a dynamic service, as opposed to the default Web-cache service, is shown below: If using the default Web-cache service, the service group settings priority, protocol, service flags, and ports are not used. wccp enable wccp version 2 service-group 9 forwarding-type L2 priority 1 protocol 6 service-flags destination-ip-hash service-flags ports-defined ports 80 21 1755 554 80 80 80 80 interface 6 home-router 10.16.18.2 end

You can create a configuration file customized for the environment two ways: CLI inline commands or through a text file. In either case, the configuration file must include the information required by the commands below. Syntax to create a customized configuration file: service-group {web-cache | service-number} [priority priority-number] [protocol protocol-number] [service-flags hash-bit-identifier] [ports port1 … port8] home-router [ip-address | domain-name] interface [interface-number] [password string] [primary-hash-weight interface-number value] forwarding-type [GRE | L2]

Using Optional Negation Syntax, you can create an alternative WCCP configuration file using these negative commands; this is especially helpful when testing and debugging. This functionality enables you to change some of the configuration settings without altering or reloading the main configuration file.

244

Chapter 17: WCCP Settings

[no] service-group {web-cache | service-number} [priority priority-number] [protocol protocol-number] [no] service-flags hash-bit-identifier [ports port1 …port8] home-router [ip-address | domain-name] [multicast-ttl [ttl_value]] [no] interface [interface-number] [password string | no password] [primary-hash-weight interface-number value]

where: web-cache

Enables the Web cache service group. If using the Web-cache service group for WCCP, the dynamic service group settings (priority, protocol, service flags, and ports) are not applicable.

service-number

The identification number of the dynamic service group being controlled by the router. Services are identified using a value from 0 to 99. The reverse-proxy service is indicated using the value 99.

priority-number

(Applies to a dynamic service group only. A dynamic service group is one identified by a service number.) Establishes queuing priorities for all defined service groups, based on a priority number from 0 through 255, inclusive.

protocol-number

(Applies to a dynamic service group only. A dynamic service group is one identified by a service number.) Number of an Internet protocol. Protocolnumber must be an integer in the range 0 through 255, inclusive, representing an IP protocol number.

hash-bit-identifier

(Applies to a dynamic service group only. A dynamic service group is one identified by a service number.) Sets the hash index, for load balancing purposes. The key associated with the hash-bit-identifier you specify is hashed to produce the primary redirection hash table index. For instance, if only the destination-ip-hash flag is set, then the packet destination IP address is used to determine the index. The index is constructed by starting with an initial value of zero and then computing an exclusive OR (XOR) of the fields specified in the hashbit identifier. If alternative hashing has been enabled, any alternate hash flags are processed in the same way and produce a secondary redirection hash table index. Alternate hash flags end with the suffix “-alternate-hash.” For more information using the hashing table, see “Understanding Cache Load

Balancing” on page 242. source-ip-hash

Sets the source IP bit definition within the redirection hash table index.

(hash-bit-identifier) destination-ip-hash

Sets the source IP bit definition within the redirection hash table index.

(hash-bit-identifier) source-port-hash (hash-bit-identifier)

Sets the source port bit definition within the redirection hash table index.

destination-port-hash (hash-bit-identifier)

Sets the destination port bit definition within the redirection hash table index.

ports-defined (hash-bit-identifier)

Sets the port bit definition within the redirection hash table index.

245

Volume 5: Advanced Networking

ports-source (hash-bit-identifier)

Sets the source port bit definition within the redirection hash table index.

source-ip-alternatehash (hash-bit-identifier)

Sets the alternate source IP bit definition within the redirection hash table index.

destination-ipalternate-hash

Sets the alternate destination IP bit definition within the redirection hash table index.

(hash-bit-identifier) source-portalternate-hash

The alternate source port bit definition within the redirection hash table index.

(hash-bit-identifier) destination-portalternate-hash

Sets the alternate destination port bit definition within the redirection hash table index.

(hash-bit-identifier) multicast-ttl

Sets the multicast TTL value per WCCP service group. The value must be set between 1 and 255. If the multicast TTL value is not set, the default value is 1. If the home-router address is not multicast, this command is non-operational.

port1…port8

(Applies to a dynamic service group only. A dynamic service group is one identified by a service number.) A zero-terminated list of TCP port identifiers. Note that this must be a list of exactly eight ports. If the service-flags ports-defined flag is set, packets are matched against the set of ports supplied. If the service-flags ports-source flag is set, the ports are assumed to be source ports. Otherwise, the ports are assumed to be destination ports.

ip-address

Indicates the IP address of your network's home router. For version 2, ipaddress can be a multicast address. (Multicast addresses are in the range 224.0.0.0 to 239.255.255.255, inclusive.) In version 2, multiple IP addresses can be specified for unicast addressing. For multicast addresses, only one IP address can be specified per service group. If you choose to specify the home router IP address, it is important that the actual home router IP address and the home router IP address specified in this SG configuration file match. If you do not already know the IP address of the home router, you can easily determine it from the router CLI by using the show ip wccp command.

domain-name

Specifies the domain name of your network's home router. Domain-name must be a valid domain name string that successfully resolves on DNS lookup.

interface-number

Specifies the adapter interface number for the service group. You cannot use a colon (0:0 or 0:1, for example).

string

(Applies to a dynamic service group only. A dynamic service group is one identified by a service number.) String can be at least one, and not more than eight, alphanumeric characters long. The password string specified here must match the password string declared for the router.

interface-number

(When used with the hash identifiers) Specifies the adapter interface to which the weight factor is applied to alter the distribution of the primary hash table.

246

Chapter 17: WCCP Settings

value

Specifies the weight factor value (0 through 255) that is applied to the adapter interface specified to alter the distribution of the primary hash table.

forwarding-type [GRE|L2]

Switches between GRE encapsulation (the default) and L2 MAC address rewrite for forwarding packets. If this command is not present, GRE encapsulation is used.

You can create a configuration file customized for the environment through the CLI inline commands or through a text file. The CLI inline commands enable WCCP on the SG appliance immediately; the drawback is that if any information changes, you must recreate the whole file using the inline command. With a text file, if any information changes, you can change the individual line; the drawback is that you must download the file again from an HTTP server to the SG appliance. To use CLI commands to create a configuration file, continue with the next procedure. To use a text editor to create a configuration file, continue with “Creating a Configuration File using a Text File” on page 247.

Creating a Configuration File using CLI Inline Commands For examples of various types of WCCP configurations, see Appendix C: "Using WCCP" on page 267. If you choose to configure through the CLI and the inline command, refer to the example below: SGOS# configure terminal SGOS#(config) inline wccp eof

where eof marks the beginning and end of the inline commands. For example: SGOS#(config) inline wccp eof wccp enable wccp version 2 service-group 9 forwarding-type L2 priority 1 protocol 6 service-flags destination-ip-hash service-flags ports-defined ports 80 21 1755 554 80 80 80 80 interface 6 home-router 10.16.18.2 end eof

You created a WCCP configuration file and enabled WCCP on the SG appliance. WCCP setup is complete.

Creating a Configuration File using a Text File If you create a configuration file using a text editor, assign the file the extension .txt. The following are SG configuration file rules: ❐

Only one command (and any associated parameters) is permitted, per line.

❐

Comments must begin with a semicolon (;) or a pound sign (#).

❐

Comments can begin in any column; however, all characters from the beginning of the comment to the end of the line are considered part of the comment and, therefore, are ignored.

247

Volume 5: Advanced Networking

For examples of various types of WCCP configurations, see Appendix C: "Using WCCP" on page 267. To create a configuration file using a text editor and load the file on an SG appliance: 1.

Open a text editor.

2.

Using the commands described in “Syntax to create a customized configuration file:” on page 244, enter the arguments you need.

3.

Copy the configuration file to an HTTP server so that it can be downloaded to the SG appliance.

4.

Enable WCCP and download the WCCP configuration file using the following syntax: wccp {enable | disable | no} [path config-file-url] | [version versionnumber]

where: enable

Enables WCCP on the SG appliance.

disable

Disables WCCP on the SG appliance.

no

Indicates that you want to clear the current WCCP configuration settings.

config-file-url

Specifies the SG WCCP configuration file or alternate configuration file.

version-number

Indicates the version of WCCP that your router is configured to use. If version version-number is omitted, it is assumed to be 2.

For example: SGOS#(config) wccp enable SGOS#(config) wccp path http://205.66.255.10/files/wccp.txt SGOS#(config) load wccp-settings

Statistics WCCP Statistics can be viewed by going to Management Console > Statistics > Advanced and scrolling down to the WCCP Statistics. The definitions for the WCCP statistics are defined as: WCCP0 WCCP1 WCCP2 WCCP3 WCCP4 WCCP5 WCCP6 WCCP6.1 WCCP6.2 WCCP6.3 WCCP6.4 WCCP6.5 WCCP6.6 WCCP6.7 WCCP6.8 WCCP6.9 WCCP6.10

: : : : : : : : : : : : : : : : :

Current time Last stats reset time Packets sent Bytes sent Packet received Bytes received Bad packets received Receive error Unknown type Total size too small Header too small Bad version Bad security comp Bad service info comp Bad query info comp Unknown group Unsolicited query

248

Chapter 17: WCCP Settings

WCCP6.11 WCCP6.12 WCCP6.13 WCCP6.14 WCCP6.15 WCCP6.16 WCCP7 WCCP8 WCCP8.1 WCCP8.2 WCCP8.3 WCCP8.4 WCCP8.5 WCCP8.6 WCCP8.7 WCCP8.8 WCCP9

: Bad router id comp : Bad router view comp : Service group mismatch : Forwarding type mismatch : Assignment type mismatch : Capability mismatch : Bad security packets : Internal errors : Failed to send : Add RID for router : Alloc query member : Alloc query timer : Add router to group : Add cache to group : Alloc active caches : Bucket reassignment : Allocated blocks

Notes If you use IP spoofing with WCCP, do the following for best results: ❐

The ip wccp redirect exclude in command should be applied to the adapter to which the SG appliance is attached.

❐

For L2 forwarding, the SG appliance should be directly connected to the router interface.

249

Volume 5: Advanced Networking

250

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

249

Volume 5: Advanced Networking

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

250

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

251

Volume 5: Advanced Networking

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

252

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

253

Volume 5: Advanced Networking

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

254

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

255

Volume 5: Advanced Networking

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

256

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

257

Volume 5: Advanced Networking

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

258

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

259

Volume 5: Advanced Networking

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

260

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

261

Volume 5: Advanced Networking

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

262

Appendix B: Using Policy to Manage Forwarding

After ICP, forwarding, and the SOCKS gateways are configured, use policy to create and manage forwarding rules. Forwarding, ICP, and SOCKS gateway rules should go in the layer of the Forwarding Policy file or the VPM Policy file (if you use the VPM). The separate layer is provided because the URL can undergo URL rewrites before the request is fetched. This rewritten URL is accessed as a server_url and decisions about upstream connections are based on the rewritten URL, requiring a separate layer. All policy commands allowed in the layer are described below. Table B-1. Policy Commands Allowed in the Layer Forwarding

Description

Conditions client_address=

Tests the IP address of the client. Can also be used in and layers.

client.host=

Tests the hostname of the client (obtained through RDNS). Can also be used in , , and layers.

client.host.has_name=

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

has_client=

has_client= is used to test whether or not the current transaction has a client. This can be used to guard triggers that depend on client identity.

hour[.utc]=

Tests if the time of day is in the specified range or an exact match. Can be used in all layers.

im.client=

Tests the type of IM client in use. Can also be used in , , and layers.

im.message.reflected=

Tests whether IM reflection occurred. Can also be used in and layers.

minute[.utc]=month[.utc]=

Tests if the minute of the hour is in the specified range or an exact match. Can be used in all layers.

263

Volume 5: Advanced Networking

Table B-1. Policy Commands Allowed in the Layer (Continued) Forwarding

Description

proxy.address=

Tests the IP address of the network interface card (NIC) on which the request arrives. Can also be used in and layers.

proxy.card=

Tests the ordinal number of the network interface card (NIC) used by a request. Can also be used in and 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 and layers.

server_url[.case_sensitive|.no_ lookup]=

Tests if a portion of the requested URL exactly matches the specified pattern.

server_url.address=

Tests if the host IP address of the requested URL matches the specified IP address, IP subnet, or subnet definition.

server_url.domain[.case_sensitive] [.no_lookup]=

Tests if the requested URL, including the domain-suffix portion, matches the specified pattern.

server_url.extension[.case_ sensitive]=

Tests if the filename extension at the end of the path matches the specified string.

server_url.host.has_name=

Tests whether the server URL has a resolved DNS hostname.

server_url.host[.exact|.substring| .prefix|.suffix|.regex][.no_lookup ]=

Tests if the host component of the requested URL matches the IP address or domain name.

server_url.host.is_numeric=

This is true if the URL host was specified as an IP address.

server_url.host.no_name=

This is true if no domain name can be found for the URL host.

server_url.host.regex=

Tests if the specified regular expression matches a substring of the domain name component of the requested URL.

server_url.is_absolute=

Tests whether the server URL is expressed in absolute form.

server_url.path[.exact|.substring| .prefix|.suffix|.regex] [.case_sensitive]=

Tests if a prefix of the complete path component of the requested URL, as well as any query component, matches the specified string.

server_url.path.regex=

Tests if the regex matches a substring of the path component of the request URL.

server_url.port=

Tests if the port number of the requested URL is within the specified range or an exact match.

server_url.query.regex=

Tests if the regex matches a substring of the query string component of the request URL.

server_url.regex=

Tests if the requested URL matches the specified pattern.

server_url.scheme=

Tests if the scheme of the requested URL matches the specified string.

socks=

This condition is true whenever the session for the current transaction involves SOCKS to the client.

264

Appendix B: Using Policy to Manage Forwarding

Table B-1. Policy Commands Allowed in the Layer (Continued) Forwarding

Description

socks.version=

Switches between SOCKS 4/4a and 5. Can also be used in and layers.

streaming.client=

yes | no. Tests the user agent of a Windows, Real Media, or QuickTime player.

time[.utc]=

Tests if the time of day is in the specified range or an exact match. Can be used in all layers.

tunneled=

yes | no. Tests TCP tunneled requests, HTTP CONNECT requests, and unaccelerated SOCKS requests

weekday[.utc]=

Tests if the day of the week is in the specified range or an exact match. Can be used in all layers.

year[.utc]=

Tests if the year is in the specified range or an exact match. Can be used in all layers.

Properties access_server()

Determines whether the client can receive streaming content directly from the OCS. Set to no to serve only cached content.

ftp.transport()

Determines the upstream transport mechanism. This setting is not definitive. It depends on the capabilities of the selected forwarding host.

forward()

Determines forwarding behavior. There is a box-wide configuration setting (config>forwarding>failure-mode) for the forward failure mode. The optional specific settings can be used to override the default.

forward.fail_open()

Controls whether the SG appliance terminates or continues to process the request if the specified forwarding host or any designated backup or default cannot be contacted.

http.refresh.recv.timeout()

Sets the socket timeout for receiving bytes from the upstream host when performing refreshes. Can also be used in layers.

http.server.connect_attempts()

Sets the number of attempts to connect performed per-address when connecting to the upstream host.

http.server.recv.timeout()

Sets the socket timeout for receiving bytes from the upstream host. Can also be used in layers.

icp()

Determines when to consult ICP. The default is yes if ICP hosts are configured and if no forwarding host or SOCKS gateway is identified as an upstream target.

im.transport()

Sets the type of upstream connection to make for IM traffic.

integrate_new_hosts()

Determines whether to add new host addresses to health checks and load balancing. The default is no. If it is set to yes, any new host addresses encountered during DNS resolution of forwarding hosts are added to health checks and load balancing.

265

Volume 5: Advanced Networking

Table B-1. Policy Commands Allowed in the Layer (Continued) Forwarding

Description

reflect_ip()

Determines how the client IP address is presented to the origin server for explicitly proxied requests. Can also be used in layers.

socks_gateway()

The socks_gateway() property determines the gateway and the behavior of the request if the gateway cannot be contacted. There is a box-wide configuration setting for the SOCKS failure mode. The optional specific settings can be used to override the default.

socks_gateway.fail_open()

Controls whether the SG appliance terminates or continues to process the request if the specified SOCKS gateway or any designated backup or default cannot be contacted.

streaming.transport()

Determines the upstream transport mechanism. This setting is not definitive. The ability to use streaming.transport() depends on the capabilities of the selected forwarding host.

trace.request()

Determines whether detailed trace output is generated for the current request. The default value is no, which produces no output

trace.rules()

Determines whether trace output is generated that shows each policy rule that fired. The default value of no suppresses output.

trace.destination()

Used to change the default path to the trace output file. By default, policy evaluation trace output is written to an object in the cache accessible using a console URL of the following form: http://SG_ip_address:8081/Policy/ Trace/path

Actions notify_email()

Sends an e-mail notification to the list of recipients specified in the Event Log mail configuration. Can be used in all layers.

notify_snmp()

The SNMP trap is sent when the transaction terminates. Can be used in all layers.

log_message

Writes the specified string to the event log.

Definitions define server_url.domain condition name

Binds a user-defined label to a set of domain suffix patterns for use in a condition= expression.

266

Appendix C: Using WCCP

This appendix discusses how to configure an SG appliance to participate in a Web Cache Communication Protocol (WCCP) scheme, when a WCCP-capable router collaborates with a set of WCCP-configured appliances to service requests. If you are already familiar with WCCP version 2 and want to get your router and SG appliance up and running right away, see the “Quick Start” on page 269.

Overview WCCP is a Cisco®-developed protocol that allows you to establish redirection of the traffic that flows through routers.

WCCP Version 1 In WCCP version 1, the WCCP-configured home router transparently redirects TCP port 80 packets to a maximum of 32 appliances. (An SG appliance is seen as a cache in WCCP protocol.) One of the caches participating in the WCCP service group is automatically elected to configure the home router’s redirection tables. This way, caches can be transparently added and removed from the WCCP service group without requiring operator intervention. WCCP version 1 supports only a single service group. Each applicable client IP packet received by the home router is transparently redirected to a cache. An SG appliance from the group is selected to define the home router’s redirection hash table for all caches. All caches periodically communicate with the home router to verify WCCP protocol synchronization and SG availability within the service group. In return, the home router responds to each cache with information as to which appliances are available in the service group.

Figure C-1. A Typical WCCP Version 1 Configuration

The following are WCCP version 1 caveats: ❐

The home router IP must be configured on all participating interfaces and must match the home router address configured on the SG appliance.

❐

The adapter connected to the SG appliance must be Ethernet or Fast Ethernet.

267

Volume 5: Advanced Networking

❐

For Cisco routers using WCCP version 1, minimum IOS releases are 11.1(18)CA and 11.2(13)P. Note that releases prior to IOS 12.0(3)T only support WCCP version 1. Ensure that you are using the correct IOS software for the router and that the SG configuration protocol version number and router protocol version number match.

For more information on WCCP Version 1, refer to the Cisco Web site. The rest of this appendix discusses WCCP version 2 only.

WCCP Version 2 For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 12.0(4). Release 12.0(5) and later releases support WCCP versions 1 and 2. Ensure that you use the correct IOS software for the router and that you have a match between the SG configuration WCCP version number and router protocol version number. WCCP version 2 protocol offers the same capabilities as version 1, along with increased protocol security and multicast protocol broadcasts. Version 2 multicasting allows caches and routers to discover each other through a common multicast service group and matching passwords. In addition, up to 32 WCCP-capable routers can transparently redirect traffic to a set of up to 32 appliances. Version 2 WCCP-capable routers are capable of redirecting IP traffic to a set of appliances based on various fields within those packets. Version 2 allows routers and caches to participate in multiple, simultaneous service groups. Routers can transparently redirect IP packets based on their formats. For example, one service group could redirect HTTP traffic and another could redirect FTP traffic. Note: Blue Coat recommends that WCCP-compliant caches from different vendors be kept separate and that only one vendor’s routers be used in a service group.

One of the caches participating in the WCCP service group is automatically elected to configure the home router’s redirection tables. This way, caches can be transparently added and removed from the WCCP service group without requiring operator intervention. WCCP version 2 supports multiple service groups. The figure below illustrates a WCCP version 2 implementation using multiple routers and Appliances. In this scenario, routers 1 through n and caches 1 through m participate in the same service group. As in version 1, an appliance from the group is selected to define the redirection hash table in all routers for all caches. All caches periodically communicate with all routers to verify WCCP protocol synchronization and appliance and router availability within the service group. In return, each router responds to caches with information as to what caches and discovered routers are available in the service group.

268

Appendix C: Using WCCP

Figure C-2. A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches

Quick Start Two tasks must be completed to get WCCP running: configuring the router and configuring the SG appliance. If you have a standard router and SG configuration, use the Quick Start below. Otherwise, begin with the instructions in the procedure "To do initial router configuration:", below, and “To create an SG appliance WCCP configuration file and enable WCCP:” on page 269. If you require a more complicated configuration, start with “Examples” on page 276. To do initial router configuration: 1.

From the router (config) mode, tell WCCP which service group you want use. The Web-cache service group redirects port 80 (HTTP) traffic only. Router(config) #ip wccp web-cache

2.

Enter the (config-if) submode by telling WCCP which IP address to use. Router(config)# int interface

where interface is the adapter interface with an IP address. The prompt changes to configuration interface submode. 3.

Enable packet redirection on an outbound (Internet facing) interface. Router(config-if)# ip wccp web-cache redirect out

4.

Prevent packets received on an adapter interface from being checked for redirection

and allow the use of Blue Coat bypass lists. Router(config-if)# ip wccp redirect exclude in

For more information on WCCP router configuration, see “Configuring a WCCP Version 2 Service on the Router” on page 270. To create an SG appliance WCCP configuration file and enable WCCP: 1.

Create a WCCP configuration file through either the SG appliance’s CLI inline commands or through a text editor. Make sure that the home router you enter here is the home router that was named in the router’s configuration. If you do have a mismatch, you must correct it before continuing. See “Identifying a Home Router/ Router ID Mismatch” on page 281. For more information on creating a configuration file, see “Examples” on page 276.

269

Volume 5: Advanced Networking

If you used the inline commands, you have completed WCCP configuration for both the router and the SG appliance and you have enabled WCCP on the SG appliance. No further steps are needed. 2.

If you used a text editor, copy the file to an HTTP server accessible to the SG appliance.

3.

Enable WCCP and download the configuration file to the SG appliance. SGOS#(config) wccp enable SGOS#(config) wccp path http://205.66.255.10/files/wccp.txt SGOS#(config) load wccp-settings

For detailed information on creating and installing a WCCP configuration file for an SG appliance, see Chapter 17: "WCCP Settings" on page 239

Configuring a WCCP Version 2 Service on the Router Configuring a router requires that you work with two different types of configuration commands: ❐

Creating a service group (which uses global settings).

❐

Configuring the Internet-Connected Interface (which uses interface settings).

Define service group settings before defining adapter interface settings.

Setting up a Service Group Services are of two types: ❐

Well known services (web-cache for port 80—HTTP— redirection)

❐

The web-cache service group is supported by both Cisco and Blue Coat.

❐

Dynamic services (which can be used for other services, such as FTP, RTSP redirection, and reverse proxy).

❐

Dynamic service uses identifiers ranging from 0-99 to name the service group.

WCCP global settings allow you to name the service group and then define the characteristics for that service group. Even if you use the pre-defined Web-cache service group, you should: ❐

configure a multicast group address

❐

create and identify a redirection access list and associate it with a service group

❐

create and identify a cache bypass list and associate it with a service group

❐

create password authentication for messages sent by the service group to the router

Syntax for configuring a service group (global settings): ip wccp {web-cache | service-number} [group-address group_address] [redirect-list access-list] [group-list access-list] [password password]

where: web-cache

Enables port 80 (HTTP) service.

service-number

The identification number of the cache service group being controlled by the router. Services are identified using a value from 0 to 99. The reverse-proxy service is indicated using the value 99, although any value can be used for reverse proxy.

270

Appendix C: Using WCCP

group-address groupaddress

(Optional) If no redirect list is defined (the default), all traffic is redirected. The group address option directs the router to use a specified multicast IP address to coalesce the “I See You” responses to the “Here I Am” messages that it has received on this address. The groupaddress argument requires a multicast address used by the router to determine which cache engine receives redirected messages. The response is sent to the group address, as well. If no group address is defined (the default), all “Here I Am” messages are responded to with a unicast reply.

redirect-list access-list

(Optional) Directs the router to use an access list to control traffic redirected to the defined service group. The access-list parameter specifies either a number from 1 to 99 identifying a predefined standard or extended access list number, or a name (up to 64 characters long) identifying an existing standard or extended access list. The access list itself specifies which traffic can be redirected.

group-list access-list

(Optional) If no group list is defined (the default), all caches might participate in the service group. The group-list option directs the router to use an access list to determine which caches are allowed to participate in the service group. The access-list parameter specifies either a number from 1 to 99 identifying a predefined standard or extended access list number or a name (up to 64 characters long) identifying an existing standard or extended access list. The access list itself specifies which caches are permitted to participate in the service group.

password password

(Optional) By default, password authentication is not configured and authentication is disabled. The password option increases authentication security to messages received from the service group specified by the service-number. Messages that do not pass authentication are discarded. The password can be up to eight characters long. If you specify a password in the router configuration, you must also configure the same password separately on each cache.

Naming a Service Group and Enabling WCCP WCCP version 2 is enabled when you name a WCCP service group. (Version 1 requires a specific enable command.) The service group can already exist, such as web-cache, or it could be a new group, such as 36. To name a service group and enable WCCP: From the router (config) mode, enter the following command: Router#(config) ip wccp web-cache -orRouter#(config) ip wccp 36

Configuring a Global Multicast Group Address Benefits of using a multicast address include reduced WCCP protocol traffic and the ability to easily add and remove caches and routers from a service group without having to reconfigure all service group members. Multicast addresses fall within the range of 224.0.0.0 to 239.255.255.255. Use the following syntax to configure a global multicast group address for multicast cache discovery. ip wccp {web-cache | service-number} [group-address group_address]

To configure a multicast address: From the router (config) mode, name the group that uses the multicast address, provide the address, then tell the router which adapter interface is used:

271

Volume 5: Advanced Networking

Router(config)# ip wccp 36 group-address 225.1.1.1 Router(config)# interface ethernet 0 Router(config-if)# end

Creating a Redirection Access List and Associating it with a Service Group Redirection access lists can contain commands redirecting packets from one network or cache to another. The lists also can be used to determine which caches participate in which service groups. The two lists, although similar, have different purposes, and are applied to the router differently. The redirection lists are applied with the redirect-list option. The cache bypass lists are applied with the group-list argument. Both lists can be identified with either a name or a number. Use the following syntax to create a redirection access list. This is partial syntax for this command. Access lists are very complicated; refer to the Cisco Web site for complete syntax. access-list acl_ID [deny | permit] protocol {[source_addr source_mask] | [local_addr local_mask]}

where: acl_ID

Names the access list you are creating. You can use either a name or number.

deny

Indicates that you do not want to allow a packet to traverse the Cisco router. By default, the router firewall denies all inbound or outbound packets unless you specifically permit access.

permit

Selects a packet to traverse the PIX firewall. By default, the router firewall denies all inbound or outbound packets unless you specifically permit access.

protocol

Identifies, by name or number, an IP protocol. This parameter can be one of the keywords icmp, ip, tcp, or udp, or an integer in the range 1 to 254 representing an IP protocol number. To match any Internet protocol, including ICMP, TCP, and UDP, use the keyword ip.

source_addr

Indicates the address of the network or host from which the packet is being sent. Use the keyword any as an abbreviation for an address of 0.0.0.0.

source_mask

Specifies the netmask bits (mask) to be applied to source_addr, if the source address is for a network mask. Use the keyword any as an abbreviation for a mask of 0.0.0.0.

local_addr

Indicates the address of the network or host local to the PIX firewall. The local_addr is the address after NAT has been performed. Use the keyword host, followed by address, as an abbreviation for a mask of 255.255.255.255.

local_mask

Specifies the netmask bits (mask) to be applied to local_addr, if the local address is a network mask. Use the keyword host followed by address as an abbreviation for a mask of 255.255.255.255.

To create a redirection access list or a cache bypass list: From the router (config) prompt, name an access list and assign rules to it. Router(config)# access-list 100 deny ip any host 126.10.10.10 Router(config)# access-list 100 permit ip any any Router# ❐

The commands above gave the access list a name of 100.

❐

Denied packets from any protocol to be sent from any host on the 126.10.10.10 network.

272

Appendix C: Using WCCP

❐

Permitted packets from any protocol to be sent from any other network.

To associate a redirection access list with a specific service group: 1.

Create a redirection access list.

2.

Associate the access list with a specified service group. ip wccp {web-cache | service-number} [redirect-list access-list] Router(config)# interface ethernet 0/0 Router(config-if)# ip wccp web-cache redirect-list 100 Router(config-if)# end Router#

To associate a cache bypass access list with a specific service group: 1.

Create a redirection access list, using the syntax discussed above.

2.

Associate the access list with a specified service group. ip wccp {web-cache | service-number} [group-list access-list] Router(config)# interface ethernet 0 Router(config-if)# ip wccp web-cache group-list 120 Router(config-if)# end Router#

Configuring the Internet-Connected Interface WCCP interface settings allow you to configure the Internet-connected adapter interface that redirects Web traffic to the content engine. Using the interface commands allows you to: ❐

Enable and prevent packet redirection

❐

Enable reception of multicast packets for service group member routers

Syntax for configuring an Internet-connected adapter interface (interface settings): ip wccp [{web-cache | service-number} redirect out | group-listen] | redirect exclude in

where: web-cache

Enables the Web cache service group.

service-number

The identification number of the cache service group being controlled by the router. Services are identified using a value from 0 to 99. The reverseproxy service is indicated using the value 99.

redirect out

Enables packet redirection on an outbound (Internet facing) adapter interface.

group-listen

On a router that is a member of a service group, enables the reception of pre-defined IP multicast packets.

redirect exclude in

Prevents packets received on an adapter interface from being checked for redirection. If the cache service-group is located on a separate router interface, the possibility exists that bypass filters could be enabled on the cache.

273

Volume 5: Advanced Networking

Using Packet Redirection WCCP communication among the routers and the appliances can be done by either directly addressing protocol packets to each router’s and cache’s IP address (as illustrated in Figure C-1 on page 267) or by sending these packets to a common multicast address as illustrated in Figure C-3, below:

Figure C-3. A Version 2 Configuration Using Multicast Packet Redirection

You can configure redirection on inbound or outbound interfaces. To configure redirection on the outbound interfaces: Use the following syntax to configure redirection on the outbound adapter interface. ip wccp {web-cache | service-number} redirect out

From the router (config) prompt, enter the following: Router(config)# interface ethernet 0 Router(config-if)# ip wccp web-cache redirect out Router(config-if)# end

To exclude packet redirection on an inbound adapter interface: Use the following command to prevent packets received on an adapter interface from being checked for redirection. ip wccp redirect exclude in

The following example shows how to exclude Blue Coat adapter interface (xx, in this case) and allow use of Blue Coat bypass lists: From the router (config) prompt, enter the following: Router(config)# int xx Router(config-if)# ip wccp redirect exclude in Router(config-if)# end

Enabling Reception of Multicast Packets Benefits of using a multicast address include reduced WCCP protocol traffic and the ability to easily add and remove caches and routers from a service group without having to reconfigure all service group members. You (optionally) set up a multicast group address in "Configuring a Global Multicast Group Address". In the following procedure, you enable the reception of the pre-defined IP multicast packets to routers that are members of the group.

274

Appendix C: Using WCCP

Multicast addresses fall within the range 224.0.0.0 to 239.255.255.255. Use the following syntax to configure for multicast discovery of the cache(s). ip wccp {web-cache | service-number} group-listen

The following example configures the router to use the WCCP 36 service group to redirect port 80 destination traffic. WCCP protocol traffic uses multicast address 225.1.1.1. Adapter interface “Ethernet 0” is used to receive the multicast WCCP traffic. Router(config)# ip wccp 36 group-address 225.1.1.1 Router(config)# interface ethernet 0 Router(config-if)# ip wccp web-cache group-listen Router(config-if)# end

Saving and Viewing Changes Once you have made all the changes, you must permanently save them to disk. If not, the changes are lost at the next reboot of the router. To save router configuration: Router# write memory

To display all current WCCP configuration settings: Use the following syntax to verify the settings in the new router configuration and to ensure that the appropriate cache engines are visible to the router. show ip wccp {web-cache | service-number} [view | detail]

where view

(Optional) Lists all members of the identified service group and whether they have been detected.

detail

(Optional) Displays IP and protocol version information about the router. Displays IP, protocol version, state, initial and assigned hash, hash allotment, redirected packet, and connection time information about the associated cache engine (SG appliance).

For example: Router# show ip wccp web-cache view Global WCCP Information: Service Name: web-cache: Number of Cache Engines:1 Number of Routers:1 Total Packets Redirected:186 Redirect Access-list:120 Total Packets Denied Redirect:57 Total Packets Unassigned:-noneGroup Access-list:0 Total Messaged Denied to Group:0 Total Authentication Failures:0 WCCP Router Informed of: 86.135.77.10 186.135.77.20 WCCP Cache Engines Visible:

275

Volume 5: Advanced Networking

186.135.77.11 186.135.77.12 WCCP Cache Engines Not Visible: -none-

Examples This section provides detailed examples of both the router and SG configurations for: ❐

Standard HTTP redirection

❐

Standard HTTP redirection and a multicast address

❐

Standard HTTP redirection and a security password

❐

Standard transparent FTP

❐

A service group and alternate hashing

For information and examples about using WCCP, refer to http://www.cisco.com/ univercd/cc/td/doc/product/software/ios121/121cgcr/fun_r/frprt3/frd3005.htm.

Displaying the Router’s Known Caches Use the router show command to display information about the appliances that are known to the router. Router# show ip wccp web-caches WCCP Web-Cache information: IP Address:192.168.51.102 Protocol Version:0.3 State:Usable Initial Hash Info:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Assigned Hash: Info:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Hash Allotment:256 (100.00%) Packets Redirected:0 Connect Time:00:00:31 Router# exit

Standard HTTP Redirection The web-cache service group enables HTTP traffic redirection on port 80.

Router Configuration The following example enables standard HTTP traffic redirection on a WCCP version 2capable Cisco router. Router(config)# ip wccp web-cache Router(config)# interface ethernet 0/0 Router(config-if)# ip wccp web-cache redirect out Router(config-if)# end

276

Appendix C: Using WCCP

SG Configuration To enable the Web-cache service group within the SG appliance, the following configuration file could be loaded. # Enable WCCP to allow WCCP protocol communication between # the ProxySG Appliance and the home router. wccp enable # By default, the WCCP version 2 protocol is assumed. An # explicit “wccp version 2" command could be specified here. service-group web-cache # Specify the address for the router. home-router 90.0.0.90 # Network interface 0 will participate. interface 0 end

Standard HTTP Redirection and a Multicast Address Configuring a multicast address on a WCCP-capable router provides reduced WCCP protocol traffic and the ability to easily add and remove caches and routers from a service group without having to reconfigure all service group members.

Router Configuration The following example enables the standard HTTP traffic redirection on a WCCP version 2-capable Cisco router. In this case, WCCP protocol traffic is directed to the multicast address 226.1.1.1. Router(config)# ip wccp web-cache group-address 226.1.1.1 Router(config)# interface ethernet 0/0 Router(config-if)# ip wccp web-cache group-listen Router(config-if)# ip wccp web-cache redirect out Router(config-if)# end

SG Configuration To enable the standard Web-cache service group within the SG appliance, the following configuration file should be loaded. In this example, both network interfaces 0 and 1 participate within the service group. Both interfaces send and receive WCCP protocol packets by way of the multicast address. # Enable WCCP to allow WCCP protocol communication between # the ProxySG Appliance and the home router. wccp enable # By default, the WCCP version 2 protocol is assumed. An # explicit “wccp version 2" command could be specified here. service-group web-cache # Specify the multicast address. home-router 239.192.5.3 # Network interface 0 will participate. interface 0 # Network interface 1 will also participate. interface 1 end

Standard HTTP Redirection Using a Security Password A simple eight-character password is configured within the router. This password must match the password configured within the SG appliance.

277

Volume 5: Advanced Networking

Router Configuration The following example enables standard HTTP traffic redirection on a WCCP version 2capable Cisco router. Router(config)# ip wccp web-cache password 29gy8c2 Router(config)# interface ethernet 0 Router(config-if)# ip wccp web-cache redirect out Router(config-if)# end

SG Configuration To enable the standard WCCP version 2 service group within the SG appliance, the following configuration file could be loaded. # Enable WCCP to allow WCCP protocol communication between # the ProxySG Appliance and the home router. wccp enable # By default, the WCCP version 2 protocol is assumed. An # explicit “wccp version 2" command could be specified # here. service-group web-cache # Specify the address for the router. home-router 90.0.0.90 # Network interface 0 will participate. interface 0 password 29gy8c2 end

Standard Transparent FTP In WCCP version 1, only HTTP traffic on port 80 could be redirected. In WCCP version 2, you can create a numbered service group that redirects other protocols on other ports. You set the service group on the router, and tell the SG appliance which ports should be redirected.

Router Configuration In this configuration, you create a new service group that you are dedicating to FTP redirects. # Enables the service group that redirects ports besides 80. Router(config)# ip wccp 10 # Enables a service group that allows user-defined # ports to be redirected. Router(config)# int e0 Router(config-if)# ip wccp 10 redirect out

SG Configuration In this configuration, you take the service group created by the router and assign the characteristics to the group. SGOS#(config) inline wccp eof wccp enable service-group 10 interface 0 home-router 10.1.1.1 protocol 6

278

Appendix C: Using WCCP

priority 1 service-flags ports-defined service-flags destination-port-hash ports 20 21 80 80 80 80 80 80 eof

Reverse Proxy Service Group This service group redirects IP packets for TCP destination port 80 traffic by hashing the source IP address.

Router Configuration The following example enables the special SG service group on a WCCP-capable router. Router(config)# ip wccp 99 Router(config)# interface ethernet 0/0 Router(config-if)# ip wccp 99 redirect out Router(config-if)# end

SG Configuration To configure the special SG service group on the appliance, a dynamic service group must be created as illustrated by the following example. # Enable WCCP to allow WCCP protocol communication between # the ProxySG Appliance and the home router. wccp enable # By default, the WCCP version 2 protocol is assumed. An # explicit “wccp version 2" command could be specified here. # Service Group 99 is specially identified within the router # as representing the ProxySG Appliance service. service-group 99 # Specify the address for the router. home-router 90.0.0.90 # Network interface 0 will participate. interface 0 # Specify the TCP protocol. protocol 6 # The hash should be based on the source IP address. service-flags source-ip-hash end

Service Group with Alternate Hashing You can create a special service group on a WCCP-capable router that uses alternate hashing when hot spots are detected. This service group redirects IP packets by hashing the source IP address.

Router Configuration In this configuration, you create a new service group that you are dedicating to Website hot spots. Router(config)# ip wccp 5 Router(config)# interface ethernet 0/0 Router(config-if)# ip wccp 5 redirect out Router(config-if)# end

279

Volume 5: Advanced Networking

SG Configuration To configure this special service group on the SG appliance, a dynamic service group must be created. # Enable WCCP to allow WCCP protocol communication between # the ProxySG Appliance and the home router. wccp enable # By default, the WCCP version 2 protocol is assumed. An # explicit “wccp version 2" command could be specified here. # Service Group 5 is created to redirect standard HTTP # traffic and use an alternate hash function based on the # source IP address, if necessary. service-group 5 # Specify the address for router 1. home-router 90.0.0.90 # Specify the address for router 2. home-router 90.0.1.5 # Network interface 0 will participate. interface 0 # Specify the TCP protocol. protocol 6 # The following two flags specify that a hash function based # on the destination IP address should be applied first. If # a hot-spot is detected, then an alternate hash # function using the source IP address should be used. service-flags destination-ip-hash service-flags source-ip-alternate-hash end

Troubleshooting: Home Router If you install WCCP settings and then later upgrade the Cisco IOS software or change network configuration by adding a device with a higher IP address, the change might result in a different home router IP assignment. WCCP might or might not work under these conditions, and performance might decrease. If you upgrade the router software or change the network configuration, verify that the actual home router IP address and home router IP address in the WCCP configuration match. To verify the home router IP address matches the home router IP address listed in the WCCP configuration: 1.

From the router CLI, view the WCCP configuration: Router#(config) show ip wccp

The home router information appears, similar to the example below: Global WCCP information: Router information: Home router Identifier:195.200.10.230 Protocol Version:2.0

2.

From the Blue Coat SG appliance, verify that the home router IP address specified in the SG WCCP configuration file is the same as the actual home router IP address discovered through the router CLI command. The following is an SG WCCP configuration file showing the same home router IP as in the example above:

280

Appendix C: Using WCCP

SGOS# show wccp config ;WCCP Settings ;Version 1.3 wccp enable wccp version 2 service-group web-cache interface 1 home-router 195.200.10.230 end

In this case, the two home router identifiers match.

Identifying a Home Router/Router ID Mismatch The following is some helpful information for resolving a home-router/Router ID mismatch that results in the router crashing the SG appliance. This situation can occur when the router interface is set to a higher IP address than the home-router and WCCP messages show w/bad rcv_id. WCCP version 1 does not care what home router the cache had configured. So if you upgrade from WCCP version 1 to WCCP version 2, the router might pick a different IP address than was configured as a home router in the cache. This means that a mismatch can occur after an upgrade.

SG Configuration Use the show wccp statistics command to identify the configured home router and the highest router IP. SGOS#(config) show wccp statistics Service Group ident. :512,1,9, 1,6,18, 1755,554,20,21,80,80,80,80 Home Routers :10.2.3.224 Policy Options.

2.

Under Default Proxy Policy, select either Deny or Allow.

3.

Click Apply to commit the changes to the SG appliance.

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 Volume 10: Blue Coat SG Appliance Content Policy Language Guide. Turning on policy tracing of any kind is expensive in terms of system resource usage and slows down the SG appliance's ability to handle traffic. To enable policy tracing: 1.

Select Configuration > Policy > Policy Options.

21

Volume 6: The Visual Policy Manager and Advanced Policy Tasks

2.

Select Trace all policy execution.

3.

Click Apply.

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 e-mail notification. You can also configure the path to point to your own custom Central policy file.

Configuring Automatic Installation You can specify whether the SG appliance checks for a new version of the Central policy file. If a new version exists, the appliance can install it automatically. Perform the following procedure to configure the SG appliance to check for and install a new version of the Central policy file. To configure automatic installation: 1.

Select Configuration > Policy > Policy Files > Policy Files.

2.

Select Automatically install new Policy when central file changes.

3.

Click Apply.

Configuring a Custom Central Policy File for Automatic Installation If you define your own Central policy file, you can configure the SG appliance 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 SG appliance 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 SG appliance automatically loads the updated version.

Configuring E-mail Notification You can specify whether the SG appliance sends e-mail when the Central policy file changes. The e-mail address used is the same as that used in diagnostic reporting: the event recipient for the custom heartbeat e-mail. For information about diagnostic reporting, see “Diagnostic Reporting (Heartbeats)” on page 424. To configure e-mail notification: 1.

Select Configuration > Policy > Policy Files > Policy Files.

2.

Select Send me email when central file changes.

3.

Click Apply.

22

Chapter 2: Managing Policy Files

Configuring the Update Interval You can specify how frequently the SG appliance 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: 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. To check for an updated central file: At the (config) command prompt, enter the following command: SGOS#(config) policy poll-now

The SG appliance 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: 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 SG appliance displays a warning that you are 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 SG Appliance to Another VPM policy files are specific to the SG appliance where they were created. But just as you can use the same Central, Local, and Forward policy files on multiple SG appliance, you can use VPM policies created on one appliance on other appliances. For detailed information on moving VPM policy files, see “Installing Policies” on page 143.

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

23

Volume 6: The Visual Policy Manager and Advanced Policy Tasks

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

Select Configuration > Policy > Policy Files > Policy Files.

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 SG appliance 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://SG_ip_address:HTTPSConsole_port/Policy/current (the default port is 8082).

•

If an HTTP-Console is configured, use http://SG_ip_address:HTTPConsole_port/Policy/current (the default port is 8081).

The SG appliance opens a separate browser window and displays the policy. 2.

Review the policy, then close the browser.

Viewing Policy Source Files You can display source (uncompiled) policy files on the SG appliance. To view policy source files: 1. 2.

Select Configuration > Policy > Policy Files > Policy Files. 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 SG appliance opens a separate browser window and displays the appropriate source policy file.

Viewing Policy Statistics You can view policy statistics on all requests processed by the SG appliance. Use the Management Console or a browser. You cannot view policy statistics through the CLI. To review policy statistics: 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.

24

Chapter 2: Managing Policy Files

4.

Examine the statistics, then close the browser.

25

Volume 6: The Visual Policy Manager and Advanced Policy Tasks 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://SG_ip_address:HTTPSConsole_port/Policy/statistics (the default port is 8082).

•

If an HTTP-Console is configured, use http://SG_ip_address:HTTPConsole_port/Policy/statistics (the default port is 8081).

The SG appliance opens a separate browser window and displays the statistics. 2.

Examine the statistics, then close the browser.

Related CLI Syntax to Manage Policy Files SGOS#(config) policy order v l c SGOS#(config) policy proxy-default {allow | deny} SGOS# policy trace {all | none} SGOS#(config) inline policy file end-of-input-marker SGOS#(config) policy subscribe SGOS#(config) policy notify: SGOS#(config) show policy SGOS#(config) show configuration -orSGOS#(config) show sources policy {central | local | forward | vpm-cpl | vpm-xml}

26

Chapter 3: The Visual Policy Manager

The Visual Policy Manager (VPM) is a graphical policy editor included with the SG appliance. The VPM allows you to define Web access and resource control policies without having an in-depth knowledge of Blue Coat Content Policy Language (CPL) and without the need to manually edit policy files. This chapter serves as a VPM object reference, and assumes that you are familiar with basic concepts of SG appliance policy functionality as described in Chapter 2, 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 Volume 10: Blue Coat SG Appliance Content Policy Language Guide. This chapter contains the following sections: ❐

Section A: "About the Visual Policy Manager" on page 28

❐

Section B: "Policy Layer and Rule Object Reference" on page 38

❐

Section C: "Detailed Object Column Reference" on page 49

❐

Section D: "Managing Policy Layers, Rules, and Files" on page 139

❐

Section E: "Tutorials" on page 149

Related topics: ❐

Chapter 2: "Managing Policy Files"

❐

Volume 7: Managing Content

❐

Volume 10: Blue Coat SG Appliance Content Policy Language Guide

27

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: About the Visual Policy Manager

Section A: About the Visual Policy Manager This section contains the following topics: ❐

“Launching the Visual Policy Manager” —Describes how to start VPM from the Management Console.

❐

“About the Visual Policy Manager User Interface” —Describes VPM menu items, tool bars, and work areas.

❐

“About VPM Components” —Provides definitions of the policy layers and describes how rule objects comprise the layers.

❐

“The Set Object Dialog” —Describes the dialog used to select objects to be added or edited.

❐

“The Add/Edit Object Dialog” —Describes the dialog used to add and edit rule objects.

Launching the Visual Policy Manager To launch the VPM:

1

2

1.

Select Configuration > Policy > Visual Policy Manager.

2.

Click Launch. The VPM launches in a separate window.

About the Visual Policy Manager User Interface The following figure labels VPM components.

28

Chapter 3: The Visual Policy Manager

Section A: About the Visual Policy Manager

Menu bar Toolbar Layer tabs Object types Rules Figure 3-1. The VPM Components

Menu Bar The following table describes VPM Menu Bar items. Table 3-1. VPM Menu Bar Items File

Edit

Policy

Install Policy On....

Saves all new policy rules.

Revert to existing Policy on ...

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.

Disable/Enable Layer

Disables or enables the selected layer. You can disable a layer without removing it from the VPM (thus losing composed policy rules) and reenable it if required.

Reorder Layers Delete Layer

Reorders the policy layers. Deletes a specific policy layer.

Add Admin Authentication Layer Add Admin Access Layer Add DNS Access Layer Add SOCKS Authentication Layer Add SSL Intercept Layer Add SSL Access 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.

29

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: About the Visual Policy Manager Table 3-1. VPM Menu Bar Items (Continued) Configuration

View

Help

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

Edit Categories

Edits content filtering categories.

Generated CPL

Displays the CPL generated by VPM.

Current SG Appliance 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.

All Objects

Displays a dialog that lists current static and user-defined VPM objects. You can also create, edit, and delete objects. See “Centralized Object Viewing and Managing” on page 131.

Tool Tips

Toggles the tool-tip display on and off.

Help Topics

Displays the online help.

About

Displays copyright and version information.

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.

❐

Move Down—Moves a rule down one position in the visible policy layer.

❐

Install Policy—Converts the policies created in VPM into Blue Coat Content Policy Language (CPL) and installs them on the SG appliance.

Policy Layer Tabs Every policy layer you create from the Policy > Add Layer menu is displayed as a tab. Click a tab and the rules included in that policy layer display below in the main body of the pane. Right-clicking a tab displays the options of disable or enabling, renaming, and deleting the policy layer.

30

Chapter 3: The Visual Policy Manager

Section A: About the Visual Policy Manager

Figure 3-2. Right-click a Policy Tab to Rename or Delete a Policy Layer

Each VPM policy layer is described in later sections in this chapter.

Rules and Objects A policy layer can contain multiple rules. Every rule is numbered and listed in a separate row. To create a new rule, click the Add Rule button; a new rule is added to the bottom of the list. If multiple rules exist within a policy layer, the SG appliance finds the first one that matches a given situation and ignores the remaining rules. Therefore, rule order is important. Use the Move buttons on the rule bar to reorder the rules in a policy. Each rule is comprised of objects. The objects are the individual elements of a rule you specify. With the exception of No. (number), which indicates the order of the rule in the layer and is filled in automatically, all objects are configurable. To specify or edit an object setting, position the mouse in the appropriate object cell within a rule and right-click to display the drop-down menu.

Figure 3-3. Right-click a Rule Cell to Set or Edit Object Properties

Each object type is described in “Policy Layer and Rule Object Reference” on page 38.

About Code Sharing With the Management Console The VPM shares information in various lists from the current configuration in the Management Console, not the saved SG appliance configurations. When the VPM is launched, it inherits the state of the SG appliance from the Management Console and remains synchronous with that Management Console. This state might include configuration changes that have not yet been applied or reverted. This does not include any changes made through the CLI. When you click Apply in the Management Console, the configurations are sent to the SG appliance; the Management Console and the VPM become synchronous with the SG appliance.

31

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: About the Visual Policy Manager For example, the SG appliance has two ICAP response services installed, A and B. In the Management Console, you remove service B, but do not click Apply. You then start the VPM and view the ICAP Response Services object. Only service A is viewable and selectable. The VPM synchronizes the latest change from the Management Console when the following occur: ❐

Clicking Revert.

❐

Clicking Apply.

❐

Clicking Policy Install.

❐

Restart the Management Console.

❐

Log out and re-log into the Management Console.

Any information the Management Console acquires from installable lists is immediately available in the VPM. The following are the lists the VPM obtains from the Management Console: ❐

Access Log fields.

❐

Authentication character sets.

❐

Authentication realms.

❐

Bandwidth gain classes.

❐

Categories.

❐

Exceptions.

❐

Forwarding hosts.

❐

ICAP request and response services.

❐

Keyrings.

❐

SOCKS gateways.

❐

Websense filter services.

About VPM Components This section describes the specific policy layer types and rule objects.

Policy Layers The layers are: ❐

Administration Authentication—Determines how administrators accessing SG

appliance must authenticate. ❐

Administration Access—Determines who can access the SG appliance to perform

administration tasks. ❐

DNS Access—Determines how the SG appliance processes DNS requests.

❐

SOCKS Authentication—Determines the method of authentication for accessing the proxy through SOCKS.

❐

SSL Intercept—Determines whether to tunnel or intercept HTTPS traffic.

32

Chapter 3: The Visual Policy Manager

Section A: About the Visual Policy Manager ❐

SSL Access—Determines the allow/deny actions for HTTPS traffic.

❐

Web Authentication—Determines whether user clients that access the proxy or the Web must authenticate.

❐

Web Access—Determines what clients can and cannot access on the Web and specifies any restrictions that apply.

❐

Web Content—Determines caching behavior, such as verification and ICAP

redirection. ❐

Forwarding—Determines forwarding hosts and methods.

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 SG appliance or Web sites they can access) once they are authenticated. Each object type is described in “Policy Layer and Rule Object Reference” on page 38.

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

While individual object-type menus occasionally contain entries specific to the object type, the basic menu options are: ❐

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.

33

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: About the Visual Policy Manager ❐

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

Figure 3-4. A Simple Web Access Layer Policy Rule

Dragging the pointer to the Destination list, right-clicking to display the drop-down list, and clicking Negate invokes a red circle with a horizontal white line in the icon in the cell.

Figure 3-5. The Red Icon in the Cell Indicates Negation

Now the rule specifies allow all URLs except the ones contained in the JobSearch category object. ❐

Cut, Copy, and Paste are the standard paste operations with the following restrictions: you can only paste anything cut or copied from the same column in the same table and the copy and paste functions do not work across multiple layers.

The following table describes the general function of each object type: Table 3-2. Object Type Functions Object

Description

Source

Specifies the source attribute, such as an IP address, user, or group.

Destination

Specifies the destination attribute, such as a URL, IP address, and file extension.

Service

Specifies the service attribute, such as protocols, protocol methods, and IM file transfer limitations.

Time

Specifies day and time restrictions.

Action

Specifies what to do when the rule matches.

Track

Specifies tracking attributes, such as event log and E-mail triggers.

Comment

Optional. You can provide a comment regarding the rule.

34

Chapter 3: The Visual Policy Manager

Section A: About the Visual Policy Manager

Policy Layer/Object Matrix The following table displays which object types are available in each policy layer. .

Table 3-3. Available Object Types Policy Layer

Source

Destination

Service

Time

Action

Track

Comment

Admin Authentication

x

x

x

x

Admin Access

x

x

x

x

DNS Access

x

x

x

x

SOCKS Authentication

x

x

x

x

SSL Intercept

x

x

x

x

x

SSL Access

x

x

x

x

x

Web Authentication

x

x

x

x

x

Web Access

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Web Content Forwarding

x

x

x

x

x

The Set Object Dialog This section discusses the Set Object dialog used to select objects for configuration. The object rules in all policy layer types determine the conditions for a particular policy rule. Depending on the type of policy layer, an object can be anything from a user or group to an IP address or a URL and so forth. To create a rule, right-click a cell in an object cell. The relevant Set Object dialog displays. In this dialog, select the objects for the rule or create new objects as necessary. Objects have type-specific icons to provide a visual aid in distinguishing among different types in the list.

35

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: About the Visual Policy Manager

Figure 3-6. Set Source Object Dialog with Selectable Objects

The Set Object dialog only displays or allows you to create the objects allowable in the specific option of the rule type you are creating. But if more than one policy-layer type uses the same object type (for example, IP address can be a source in rules for four of the five types of policies), then those existing objects display in all Set Object dialogs, regardless of policy-layer type.

Controlling the List of Objects in the Set Object Window As you create more policies, it is likely that the lists of existing objects in the various Set Object dialogs expand. You can restrict the display of objects in the list to a specific type by selecting an object type from the Show drop-down list above the objects field. The following figure demonstrates the window displayed above with the list restricted to Client IP addresses.

Figure 3-7. Limiting the Set Object Dialog view.

36

Chapter 3: The Visual Policy Manager

Section A: About the Visual Policy Manager

The Add/Edit Object Dialog From the Set Object dialog, the Add Object dialog is used to define configurable objects. Existing configurable options can be altered using the Edit Object dialog. In terms of functionality, the two dialogs are identical. For the initial configuration of an object, click New on the Set Object dialog to display the Add Object dialog. Perform the tasks required to configure the object and click OK. The newly named and configured object appears in the list of selectable objects in the Set Object dialog and is ready to be selected for the rule. To edit an existing object, select an object from the list and click Edit. The Edit Object dialog appears with the existing parameters on display. Edit as necessary and click OK. To remove an existing object, select an object from the list and click Remove. A secondary prompt verifies your attempt to remove the object; click OK. The object is deleted.

Online Help The VPM contains its own Help module (a porting of this chapter). Each object in the VPM contains a Help button that links to the corresponding object reference in the Help file. This reference describes the purpose of the object. Interaction with other policy and references to feature-related sections in the Blue Coat Configuration and Management Guide Suite volumes are provided, if relevant. Also, this Help module contains navigation buttons and its own Table of Contents. Note: The online Help file is displayed in a separate window and requires a few seconds to load and scroll to the correct object. The speed of your system might impact this slight lag time. Furthermore, this lag time increases on slower machines running JRE v1.5.

37

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference

Section B: Policy Layer and Rule Object Reference This section contains the following topics: ❐

“About the Reference Tables” —Describes the table conventions used in this section.

❐

“Administration Authentication Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“Administration Access Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“DNS Access Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“SOCKS Authentication Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“SSL Intercept Layer Reference” —Describes the objects available in this policy layer.

❐

“SSL Access Layer Reference” —Describes the objects available in this policy layer.

❐

“Web Authentication Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“Web Access Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“Web Content Policy Layer Reference” —Describes the objects available in this policy layer.

❐

“Forwarding Policy Layer Reference” —Describes the objects available in this policy layer.

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

38

Chapter 3: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference

Administration Access Policy Layer Reference The following table provides the objects available in the Administration Access policy layer. Source Objects

Service Objects

Action Objects

Track Objects

Client IP Address/ Subnet

Service Name

Allow Read-Only Access

Event Log

Client Hostname

Allow Read-Write Access

Email

Proxy IP Address/Port

Deny

SNMP

User

Log Out/Do Not Log Out Other Users With Same IP

Trace

Group

Log Out/Do Not Log Out User

Combined Objects

Attribute

Log Out/Do Not Log Out User’s Other Sessions

User Login Address

Force Deny

User Login Time

Set Authorization Refresh Time

User Login Count

Set Credential Refresh Time

Client Address Login Count

Set Surrogate Refresh Time

Combined Objects

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

Track Objects

Client IP Address/ Subnet

DNS Response Contains No Data

Time

Bypass DNS Cache

Event Log

Proxy IP Address/ Port

DNS Response IP Address/Subnet

Combined Objects

Do Not Bypass DNS Cache

Email

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

DNS Request Opcode

DNS Response Code

Enable/Disable DNS Imputing

Combined Objects

39

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Time Objects

Action Objects

DNS Request Class

Category

Send DNS/RDNS Response Code

DNS Request Type

Server Connection DSCP Trigger

Send DNS Response

DNS Client Transport

Combined Objects

Send Reverse DNS Response

Client Connection DSCP Trigger

Reflect IP

Combined Objects

Manage Bandwidth

Track Objects

Set Client Connection DSCP Value Set Server Connection DSCP Value 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

SSL Intercept Layer Reference The following table provides the objects available in the SSL Forward Proxy policy layer. Source Objects

Destination Objects

Action Objects

Track Objects

Client Hostname Unavailable

Destination IP Address/ Subnet

Enable HTTPS Intercept

Event Log

Client Hostname

Destination Host/ Port

Enable HTTPS Intercept on Exception

Email

Proxy IP Address/Port

Request URL

Combined Objects

SNMP

40

Chapter 3: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Action Objects

Track Objects

Combined Objects

Request URL Category

Trace

Server URL

Combined Objects

Server Certificate Server Certificate Category Combined Objects

SSL Access Layer Reference The following table provides the objects available in the SSL Access Layer policy layer. Source Objects

Destination Objects

Service Objects

Action Objects

Track Objects

Authenticated User

Destination IP Address/Subnet

Request Forwarded

Allow

Event Log

Client Hostname Unavailable

Destination Host/ Port

Client Protocol

Deny (static)

Email

Guest User

Request URL

SSL Proxy Mode

Require/Do Not Require Client Certificate

SNMP

Client IP Address/ Subnet

Request URL Category

Health Check

Force Deny

Trace

Client Hostname

Server URL

Combined Objects

Force Deny (Content Filter)

Combined Objects

Proxy IP Address/ Port

Server Certificate

Deny

User

Server Certificate Category

Return Exception

Group

Server Certificate

Set Client Certificate Validation

Attribute

Server Certificate Category

Set Server Certificate Validation

User Login Address

Server Negotiated Cipher

Combined Objects

User Authentication Error

Server Negotiated Cipher Strength

User Authorization Error

Server Negotiated SSL Version

Client Certificate

Combined Objects

41

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Service Objects

Action Objects

Track Objects

Client Negotiated Cipher Client Negotiated Cipher Strength Client Negotiated SSL Version Combined Objects

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

Request URL

Authenticate

Proxy IP Address/Port

Request URL Category

Authenticate Guest

User Agent

Combined Objects

Add Default Group

Request Header

Force Authenticate

Combined Objects

Authentication Charset Set IP Address For Authentication Permit Authentication Error Permit Authorization Error Combined Objects

42

Chapter 3: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference

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

Guest User

Request URL

Client Protocol

Force Deny

Authenticated User

Request URL Category

Service Name

Bypass Cache

Client IP Address/ Subnet

File Extensions

Protocol Methods

Do Not Bypass Cache

Client Hostname

HTTP MIME Types

IM File Transfer

Check/Do Not Check Authorization

Trace

Proxy IP Address/ Port

Apparent Data Type

IM Message Text

Always Verify

Combined Objects

User

Response Code

IM Message Reflection

Use Default Verification

Group

Response Header

Streaming Content Type

Block/Do Not Block PopUp Ads

Attribute

Response Data

ICAP Error Code

Force/Do Not Force IWA for Server Auth

User Login Address

IM Buddy

Health Status

Log Out/Do Not Log Out Other Users With Same IP

SNMP

43

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Service Objects

Time Objects

Action Objects

User Login Time

IM Chat Room

Combined Objects

User Login Count

Server Connection DSCP Trigger

Log Out/Do Not Log Out User’s Other Sessions

Client Address Login Count

Combined Objects

Reflect/Do Not Reflect IM Messages

Track Objects

Log Out/Do Not Log Out User

User Authentication Error

Block/Do Not Block IM Encryption

User Authorization Error

Support/Do Not Support Persistent Client Requests

User Agent

Support/Do Not Support Persistent Server Requests

IM User Agent

Trust/Do Not Trust Destination IP

Request Header

Deny

SOCKS Version

Return Exception

IM User

Return Redirect

P2P Client

Send IM Alert

Client Negotiated Cipher

Modify Access Logging

Client Negotiated Cipher Strength

Override Access Log Field

Client Connection DSCP Trigger

Rewrite Host

Combined Objects

Reflect IP

P2P Client

Suppress Header

44

Chapter 3: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Service Objects

Time Objects

Action Objects

Client Negotiated Cipher

Control Request Header/Control Response Header

Client Negotiated Cipher Strength

Notify User

Client Connection DSCP Trigger

Strip Active Content

Combined Objects

Set Client HTTP Compression

Track Objects

Set Server HTTP Compression Manage Bandwidth Modify IM Message Return ICAP Feedback Set External Filter Service Set ICAP Request Service Set FTP Connection Set SOCKS Acceleration Disable SSL Detection Set Streaming Max Bitrate Set Client Connection DSCP Value Set Server Connection DSCP Value Set ADN Connection DSCP

45

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference Source Objects

Destination Objects

Service Objects

Time Objects

Action Objects

Track Objects

Set Authorization Refresh Time Set Credential Refresh Time Set Surrogate Refresh Time Combined Objects

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

Request URL

Use Default Verification

Email

Request URL Category

Use Default Caching

SNMP

File Extensions

Do Not Cache

Trace

HTTP MIME Types

Force Cache

Combined Objects

Response Header

Mark/Do Not Mark As Advertisement

Response Data

Support/Do Not Support Persistent Server Requests

Server Connection DSCP Trigger

Enable/Disable Pipelining

Combined Objects

Set Dynamic Categorization Set External Filter Service Set Client HTTP Compression Set Server HTTP Compression Manage Bandwidth Set ICAP Request Service Set ICAP Response Service

46

Chapter 3: The Visual Policy Manager

Section B: Policy Layer and Rule Object Reference Destination Objects

Action Objects

Track Objects

Set TTL Modify Access Logging Override Access Log Field Set Server Connection DSCP Value Combined Objects

Forwarding Policy Layer Reference The following table provides the objects available in the Forwarding policy layer. Source Objects

Destination Objects

Service Objects

Action Objects

Track Objects

Streaming Client

Destination IP Address/Subnet

Client Protocol

Send Direct

Trace

Authenticated User

Destination Host/ Port

Health Check

Integrate/Do Not Integrate New Hosts

Guest User

Server URL

Health Status

Connect Using ADN When Possible/Do Not Connect Using ADN

Client IP Address/ Subnet

Server Connection DSCP Trigger

Combined Objects

Allow Content From Origin Server

Client Hostname

Combined Objects

Serve Content Only From Cache

Proxy IP Address/ Port

Select SOCKS Gateway

User

Select Forwarding

Group

Reflect IP

Attribute

Manage Bandwidth

User Login Address

ADN Server Optimization

User Login Time

Set IM Transport

User Login Count

Set Streaming Transport

Client Address Login Count

Set ADN Connection DSCP

User Authentication Error

Set Server Connection DSCP Value

47

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Policy Layer and Rule Object Reference Source Objects User Authorization Error

Destination Objects

Service Objects

Action Objects

Track Objects

Combined Objects

SOCKS Version P2P Client Client Connection DSCP Trigger Combined Objects

48

Chapter 3: 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” on page 49

❐

“Destination Column Object Reference” on page 66

❐

“Service Column Object Reference” on page 76

❐

“Time Column Object Reference” on page 82

❐

“Action Column Object Reference” on page 84

❐

“Track Object Column Reference” on page 125

❐

“Comment Object Reference” on page 128

❐

“Using Combined Objects” on page 128

❐

“Creating Categories” on page 134

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.

Important: Because of character limitations required by the generated CPL, only alphanumeric, underscore, dash, ampersand, period, or forward slash characters can be used to define a source object name.

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.

Guest User This is a static object. This rule applies to all guest users.

49

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

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. Note: See “Combined Source Object” on page 64 for related information regarding this source object.

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 SG appliance. 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 SG appliance. LDAP You can optionally select a User Base DN from a drop-down list. Entries in the User Base DN list come from those specified by the administrator in the SG appliance. You can also edit an entry selected in the list, type a new one, or click Browse to manually select a name. Edited names and new names are retained in the list. Notice in the Full Name field that the VPM takes the User Attribute type specified by the administrator in the SG appliance (cn= in the following illustration), and associates it with the user name and Base DN entered here. Important: When you configure a realm, the SG appliance assumes a default primary user attribute (sAMAccountName for Active Directory; uid for Netscape/iPlanet Directory Server/SunOne; cn for Novell NDS). You can accept the default or change it. Whatever is entered there is what the VPM uses here, entering it in the Full Name display field once a Base DN is selected. If the primary user attribute specified in the SG appliance differs from the primary user attribute specified in the directory server, enter the latter in the User field with the appropriate value (in the format attribute=value). This replaces the entry in the Full Name field. Examine the following screenshot. Assume that the organization uses phone as the primary attribute in its LDAP directory:

50

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

You can only enter a user attribute and equal sign in the User field if a User Base DN is selected.

IWA Entries in this list are not prepopulated. You must enter a name in the Domain Name field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above.

51

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

RADIUS Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. Windows SSO Entries in this list are not prepopulated. You must enter a name in the User field. Entries in the Domain Name list come from those specified by the administrator in the SG appliance. You can also edit an entry selected in the list, type a new one, or click Browse to manually select a name. Local Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. Certificate If a Certificate realm is selected and that realm uses an LDAP realm as authentication realm, the Browse button is clickable. This option allows you to browse the LDAP database and select users, thus preventing typing errors possible from manually entering names in the fields. If the Certificate realm does not use an LDAP authentication realm, Browse is not displayed.

52

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference Netegrity SiteMinder Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. Oracle COREid Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. Policy Substitution Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. Sequences Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. From the Member Realm drop-down list, select an authentication realm (already configured on the SG appliance). Depending on the realm type, new fields appear.

Group Specifies a verifiable group name. Enter a user group and an authentication realm. The dialog then displays different information depending on the type of authentication realm specified. ❐

Group field—Replace the default with a verifiable group name.

❐

Authentication Realm field—Select the appropriate realm from the drop-down list. Items in the list are taken from the realms configured by the administrator in the SG appliance.

•

LDAP—Entries in the Group Base DN list come from those specified by the administrator in the SG appliance. You can also edit an entry selected in the list, or type a new one. Edited names and new names are retained in the list. Notice in the Full Name field that the VPM takes the User Attribute type specified by the administrator in the SG appliance (cn= in the following illustration), and conjoins it with the group name and Base DN entered here.

Important: When you create a group, the default attribute is cn= in the Full Name display field.

53

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Figure 3-8. Adding a group object

If the primary user attribute specified in the SG appliance differs from the primary user attribute specified in the directory server, you need to enter the latter here. Do that by typing it in the Group field with the appropriate value (in the format attribute=value). Doing so replaces the entry in the Full Name field. Unlike the comparable situation when creating a user (described immediately above), when creating a group, the Group Base DN does not need to be selected in order to type the attribute=value pair in the Group field. •

IWA—Entries in this list are not prepopulated. You must enter a name in the Domain Name field. A name typed in is retained and can subsequently be selected and edited. Notice in the Full Name field that the VPM displays the domain name

and group name entered above. •

RADIUS—Entries in this list are not prepopulated. You must enter a name in the Group field.

•

Windows SSO—Entries in this list are not prepopulated. You must enter a name in the Group field.

54

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Figure 3-9. Adding a group object

•

Local—Entries in this list are not prepopulated. You must enter a name in the Group field. A name typed in is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays the group name entered

above. •

Certificate—If a Certificate realm is selected and that realm uses an LDAP realm as authentication realm, the Browse button is clickable. This option allows you to browse the LDAP database and select users, thus preventing typing errors possible from manually entering names in the fields. If the Certificate realm does not use an LDAP authentication realm, Browse is not displayed.

•

Netegrity SiteMinder—Entries in this list are not prepopulated. You must enter a name in the Group field. A name typed in is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays the group name entered above.

•

Oracle COREid—Entries in this list are not prepopulated. You must enter a name in the Group field. A name typed in is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays the group name entered above.

•

Policy Substitution—Entries in this list are not prepopulated. You must enter a name in the Group field. A name typed in is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays the group name entered above.

55

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference •

Sequences—Entries in this list are not prepopulated. You must enter a name in the Group field. An entered name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays domain name and user name entered above. From the Member Realm drop-down list, select an authentication realm (already configured on the SG appliance). Depending on the realm type, new fields appear.

Attribute Specifies an LDAP or Radius realm-specific attributes.

LDAP Specifies a specific LDAP attribute (and optional value). Specify an LDAP attribute:

1 2

3 4

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

From the Authentication Realm drop-down list, select All LDAP or a specific realm.

3.

In the Attribute Name field, enter a valid attribute.

4.

In the Attribute Value field, enter value for the specified LDAP attribute, or leave blank to accept any value. The above example sets a Common Name (CN) attribute with the value of Kent to the LDAP1 realm.

RADIUS Specifies a RADIUS attribute.

56

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To specify a RADIUS attribute:

1 2

3 4

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

Select All RADIUS or a specific realm.

3.

Select an Attribute Name.

4.

Enter an Attribute Value for the Attribute Name.

User Login Address The condition matches the IP address used to login. Serves as a request parameter for Windows Single Sign-On (SSO).

User Login Time This condition matches the number of seconds since the current login started, and can limit the length of a login session.

User Login Count This condition matches the number of times that a specific user is logged in with the current realm. This condition ensures that a user is only logged in at one workstation. If the condition is combined with the user.login.log_out_other property, old logins on other workstations are automatically logged out.

Client Address Login Count This condition matches and can limit the number of different users who are logged into the current IP address.

User Authentication Error Checks for a matches of specified user authentication errors.

57

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To specify a User Authentication Error object:

1

2

1.

Select one of the following: •

None: Authentication was attempted and no user errors occurred.

•

Any: Authentication was attempted a user error occurred.

•

Selected errors: Authentication was attempted and one of the selected errors

occurred. 2.

3.

If you selected Selected errors: a.

Select one or more error types (use Control + Left-click to highlight multiple errors).

b.

Click Add to move the errors to the Selected field.

c.

Name the object or accept the default name.

Click OK.

Note: If authentication fails and no default groups are added through policy (see Guest

Authentication and Default Groups), the group conditions always evaluate to false. Verify group conditions if you permit authentication errors, especially in scenarios where users are denied based on group membership.

User Authorization Error Checks for a match of specified user authorization errors.

58

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To specify a User Authorization Error object: 1.

Select one of the following: •

None: Authorization was attempted and no user errors occurred.

•

Any: Authorization was attempted a user error occurred.

•

Selected errors: Authorization was attempted and one of the selected errors

occurred. 2.

3.

If you selected Selected errors: a.

Select one or more error types (use Control + Left-click to highlight multiple errors).

b.

Click Add to move the errors to the Selected field.

c.

Name the object or accept the default name.

Click OK.

Note: If authorization fails and no default groups are added through policy (see Guest Authentication and Default Groups), the group conditions always evaluate to false. Verify group conditions if you permit authorization errors, especially in scenarios where users are denied based on group membership.

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.

59

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference 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. To specify a DNS Client Transport object: 1.

Select UDP Transport or TCP Transport. This object is automatically named using the prefix DNS; for example, DNS: Client Transport UDP.

2.

Click OK.

SOCKS Version Specifies the SOCKS version, 4 or 5. This object is automatically named as SOCKSVersion4 or SOCKSVersion5.

User Agent Specifies one or more agents a client might use to request content. The choices include specific versions of: Microsoft Internet Explorer, Netscape Communicator, Microsoft Windows Media Player and NetShow, Real Media RealPlayer and RealDownload, Apple QuickTime, Opera, and Wget. The policy defined in this rule applies to these selected agents. You can name this list and create other custom lists to use with other policy layer rules.

60

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Example: Selecting streaming media user agents.

Note: If you require a user agent not contained in this list, use the Request Header object, which can contain user agent specified as a header.

IM User Agent Checks the specified string for a match in the user agent provided by the IM client. For example, specify the string Lotus to distinguish between the Lotus AOL client and the standard AOL client. To specify a User Agent: 1.

In the IM User Agent field, enter a string.

2.

From the drop-down list, select a matching criteria.

3.

Click Add.

Request Header Specifies the rule applies to requests containing a specific header. Blue Coat supplies a list of standard headers, but you can also select a custom header.

61

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To specify a request header:

1 2 3 4

1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

From the Show drop-list select the viewing field from All to Standard or Custom, as desired. Standard displays only the default standard headers. Custom displays any admin-defined headers that exist.

3.

From the Header Name drop-list, select a standard or custom header or enter a new custom header name.

4.

In the Header Regex field, enter the header values to which this rule applies.

Client Certificate Allows for testing common name and subject fields in client certificates.

IM User Specifies an IM user by their handle. IM traffic sent to or from this user is subject to this rule. You can enter a complete user ID, a string that is part of a user ID, or a string with a regular expression. Select the match type from the drop-down list to the right (Exact, Contains, or RegEx).

Example: Designating Bob Kent in Purchasing as IM user number 1.

P2P Client Specifies peer-to-peer (P2P) clients. To specify P2P clients: 1.

In the Name field, enter a name for the object or accept the default.

2.

Select All P2P Clients (all protocols become selected), or one or more P2P protocols.

62

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference 3.

Click OK.

Client Negotiated Cipher Allows the testing of the SSL cipher in use between the SG appliance and the browser. Select a code from the drop-down list. To specify a client negotiated cipher: 1.

In the Name field, enter a name for the object or accept the default.

2.

Select one or more cipher codes valid for this rule.

3.

Click OK.

Client Negotiated Cipher Strength Tests the cipher strength between a SG appliance-to-browser (client) HTTPS connection. To specify a client negotiated cipher strength: 1. 2.

In the Name field, enter a name for the object or accept the default. Select one or more of the strength options valid for this rule Export, High, Medium, or Low.

3.

Click OK.

Low, Medium, and High strength ciphers are not exportable.

Client Negotiated SSL Version Tests the SSL version between a SG appliance-to-browser (client) HTTPS connection. To specify a client negotiated SSL version: 1. 2.

In the Name field, enter a name for the object or accept the default. Select one or more of the version options valid for this rule SSL 2.0, SSL 3.0, or TLS 1.0.

3.

Click OK.

Client Connection DSCP Trigger Tests the inbound differentiated service code point (DSCP) value of primary client-to-SG appliance connections. After testing DSCP bits (in the IP header), additional policy dictates how to handle traffic associated with the type of service.

63

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

1

3 2

To specify DSCP values to test against inbound client connections: 1.

In the Name field, enter a name for the object or accept the default. This example creates an object that tests for an IP Precedence of 2 or any Assured Forwarding Class (AFC) of type 2 (for low, medium, and high drop rates).

2.

Select IP Precedence values (denoted by CS) and Assured Forwarding Classes (Denoted by AF) as required).

3.

(Optional) Rather than select Precedence and AFC values, enter a DSCP value range. The valid range is 0 to 63. Blue Coat does not recommend this option. Most applications fit into one of the defined values.

For conceptual information about configuring the SG appliance to manipulate traffic based on type of service, refer to "Managing QoS and Differential Services" on page 194.

Combined Source Object Allows you to create an object that combines different source types. See “Using Combined Objects” on page 128. Note: Blue Coat strongly recommends that combined objects with large lists of Client IP Address/Subnet values (see “Client IP Address/Subnet” on page 50) do not contain other source objects. If other source objects are present, the policy evaluation might experience a significant performance degradation.

64

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

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 Admin DNS SOCKS SSL SSL Auth Acc Acc Auth Int Acc

Web Auth

Web Web Fwding Acc Cont x

Streaming Client x

Client Hostname Unavailable

x

x

x

Authenticated User

x

x

Guest User

x

x

Client IP Address/Subnet

x

Client Hostname

x

Proxy IP Address/Port

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

User

x

x

x

x

Group

x

x

x

x

Attribute

x

x

x

x

User Login Address

x

x

x

x

User Authentication Error

x

x

x

User Authorization Error

x

x

x

User Login Time

x

x

x

x

User Login Count

x

x

x

x

Client Address Login Count

x

x

x

x

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

SOCKS Version

x x

User Agent

x

IM User Agent x

Request Header Client Certificate IM User

x

x

x x

65

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference Object

Admin Admin DNS SOCKS SSL SSL Auth Acc Acc Auth Int Acc

Web Auth

Web Web Fwding Acc Cont x

P2P Client Client Negotiated Cipher

x

x

Client Negotiated Cipher Strength

x

x

Client Negotiated SSL Version

x x

Client Connection DSCP Trigger x

Combined Objects

x

x

x

x

x

x

x

x

x

x

x

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.

Important: Because of character limitations required by the generated CPL, only alphanumeric, underscore, dash, ampersand, period, or forward slash characters can be used to define a destination object name.

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

Request URL Applies to a URL request sent by the client to the SG appliance. To check for a match against requested URL Select an option and enter the required information in the fields:

66

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference ❐

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 in the rule 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. Unlike the other options on this dialog, selecting Advanced Match allows you to 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).

67

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Request URL Category Allows you to create and customize categories of URLs. Requested URLs are checked for matches and categorized and evaluated for further action dependent upon content filtering policy. ❐

Policy—Displays all current pre-defined and user created URL categories. This includes all category-related configurations created in the VPM, as well as in the Local and Central policy files (once installed). Select and deselect categories as required.

You can also create new categories from this dialog, which is similar to the dialog accessed through the VPM Menu Bar as described in “Creating Categories” on page 134. If you enable a service, such a content filter, those relevant categories appear in this object. ❐

Blue Coat—If you are employing Blue Coat Web Filter, those categories appear here.

❐

System—Displays hard-coded SG appliance configurations. These are not editable, but you can select or deselect them.

Create a policy category: 1.

Select Policy; click Add. The Object Name dialog appears.

2.

Name the category and click OK.

68

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference 3.

Drop the Policy list and select the created category; click Edit URLs. The Edit Locally Defined Category Object dialog appears.

4.

Enter URLs appropriate for the content filter category you are creating; click OK.

5.

Click OK. Note: If one or more other administrators have access to the SG appliance through other workstations and are creating categories either through VPM or with inline

commands, consider that newly-created or edited categories are not synchronized until the policy is installed. When the policy is installed with VPM, the categories are refreshed. If confusion occurs, select the File>Revert to Existing Policy on SG Appliance option to restore the policy to the previous state and reconfigure categories.

Category Hierarchy Behavior Once categories have been created, they can be selected and deselected as required. If you create sub-categories (a parent and child category hierarchy), the category selection behavior is the following: ❐

Selecting a parent category automatically selects all child categories if no child categories are already selected.

❐

Deselecting a parent category automatically deselects all child categories if all child categories are already selected.

❐

If one or more of the child categories are already selected or deselected, selecting or deselecting the parent category does not affect child categories—the status of selected or deselected remains the same.

This behavior applies to as many levels as you create.

Category Functions the same as “Request URL Category” on page 68, but this object is unique to the DNS Access Layer.

69

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Server URL This object is functions the same as the “Request URL” on page 66 object, but applies to a URL sent from the SG appliance to a server. If the SG appliance is performing URL rewrites, the URL sent from the client might change, which requires another URL matching check.

Server Certificate Allows testing of server certificate attributes to be used by the SG appliance-to-server HTTPS connections. Select one of the options: ❐

Hostname: This is the hostname you want to match in the server certificate. After you enter the hostname, select from the dropdown list one of the following: Exact Match, Contains, At Beginning, At End, Domain, or Regex.

❐

Subject: This is the fully qualified subject name in the server certificate. After you enter the subject, select from the dropdown list one of the following: Exact Match, Contains, At Beginning, At End, Domain, or Regex.

Server Certificate Category Functions the same as the “Request URL Category” on page 68 object, but the piece of information used for matching and categorizing is the hostname in the server certificate.

Server Negotiated Cipher Tests the cipher suites used in a SG appliance-to-server connection. To specify a server-negotiated cipher: 1.

In the Name field, enter a name for the object or accept the default.

2.

Select one or more cipher codes valid for this rule.

3.

Click OK.

Server Negotiated Cipher Strength Specifies the cipher strength between a SG appliance-to-server HTTPS connection. To specify a server-negotiated cipher strength: 1. 2.

In the Name field, enter a name for the object or accept the default. Select one or more of the strength options valid for this rule Export, High, Medium, or Low.

3.

Click OK.

Low, Medium, and High strength ciphers are not exportable.

Server Negotiated SSL Version Specifies the SSL version between a SG appliance-to-server HTTPS connection. To specify a server-negotiated SSL version: 1.

In the Name field, enter a name for the object or accept the default.

70

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference 2.

Select one or more of the strength options valid for this rule SSL 2.0, SSL 3.0, or TLS 1.0.

3.

Click OK.

File Extensions Creates a list of file extensions. The rule is triggered for content with an extension matching any on the list. You can create multiple lists that contain various extensions to use in different rules. For example, create a list called Images, and select file extension types such as GIF, JPEG, BMP, XPM, and so on.

HTTP MIME Types Creates a list of HTTP MIME content types. The rule is triggered for content matching any on the list. You can create multiple lists that contain various MIME types to use in different rules. For example, create a list called MicrosoftApps, and select MIME types application/vnd.ms-excel, application/vnd.ms-powerpoint, application/vnd.ms-project, and application/vnd.works. Note: If you require a MIME type not contained in this list, use a Request URL object that uses the At End matching criteria.

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

In the Name field, enter a name for the object or accept the default.

2.

Select one or both of the following data types:

3.

•

DOS/Windows Executable: Any type of Windows executable file, such as .exe files (the most common type of Microsoft executable file, which is self-extracting); .dll files (also self-extracting, but require another executable file), and .ocx files (ActiveX control files that can be installed if the browser security level is set to low). Windows PE, LE, and NE executable types are recognized.

•

Microsoft Cabinet File: Although not executable themselves, .cab (cabinet) files are used by spyware programs to propagate ActiveX controls. Code in HTML pages reference .cab files, which, from the inside, instruct the browser to download and extract ActiveX components.

Click OK.

Response Code Specifies the rule applies to content responses containing a specific HTTP code. Select a code from the drop-down list. You can name the rule object or accept the default name.

71

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Response Header Specifies the rule applies to content responses containing a specific header. Blue Coat supplies a list of standard headers, but you can also enter a custom header. To specify a response header:

1 2 3 4

1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

From the Show drop-down list select the viewing field from All to Standard or Custom, as desired. Standard displays only the default standard headers. Custom displays any admin-defined headers that exist.

3.

From the Header Name drop-down list, select a standard or custom header.

4.

In the Header Regex field, enter the header string this rule applies to.

Response Data Specifies the rule applies to content responses containing specific regular expressions. To specify a regular expression header:

1 2 3

1.

In the Name field, enter a custom name or leave as is to accept the default.

2.

In the RegEx to match field, enter the regular expression string to match.

3.

In the Number of bytes to examine field, enter how many object bytes are scanned for the match.

4.

Click OK.

72

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

IM Buddy Specifies an IM buddy by their handle. IM traffic sent to or from this buddy is subject to this rule. You can enter a complete buddy ID, a string that is part of a buddy ID, or a string with a regular expression. Select the match type from the drop-down list to the right (Exact, Contains, or RegEx).

IM Chat Room Specifies an IM chat room by name or other condition. IM traffic sent to this chat room is subject to this rule. To create a chat room condition:

1 2a 2b 2c 2d 2e

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

Select one or more of the following conditions: a.

Room ID—Specifies a specific IM chat room by its name. Enter a name and from the drop-down list select an option: Exact Match, Contains, or RegEx.

b.

Type—Specifies whether the room is Private or Public.

c.

Invite Only—Specifies to trigger if user must be invited or not.

d. Voice Enabled—Specifies whether room supports voice chat or not. e. 3.

Conference—Specifies whether room has conference capability or not.

Click OK.

DNS Response IP Address/Subnet Specifies the destination DNS IP address and, optionally, a subnet mask. The policy defined in this rule only applies to DNS responses containing this address or addresses within this subnet. This object is automatically named using the prefix DNS; for example, DNS: 1.2.3.4/255.255.0.0.

73

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

RDNS Response Host Specifies a reverse DNS response 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 RDNS; for example, RDNS: host.com. If you select a matching qualifier, that attribute is appended to the object in parentheses. For example, RDNS: host.com (RegEx).

DNS Response CNAME Specifies the rule applies to DNS CNAME responses matching a given hostname. Enter the host name and select matching criteria. This object is automatically named using the prefix DNS CNAME; therefore, the object is displayed as DNS CNAME: host.com.

DNS Response Code Specifies the rule applies to DNS responses containing a specific DNS Response code. Select one or more codes from the list. You can name the rule object or accept the default name.

Server Connection DSCP Trigger Tests the inbound differentiated service code point (DCSP) value of primary server-to-SG appliance connections. By testing DCSP bits (in the IP header), additional policy dictates how to handle traffic associated with the type of service.

1

3 2

74

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To specify DSCP values to test against inbound server connections: 1.

In the Name field, enter a name for the object or accept the default. This example creates an object that tests for an IP Precedence of 2 or any Assured Forwarding Class (AFC) of type 2 (for low, medium, and high drop rates).

2.

Select IP Precedence values (denoted by CS) and Assured Forwarding Classes (Denoted by AF) as required).

3.

(Optional) Rather than select Precedence and AFC values, enter a DSCP value range. The valid range is 0 to 63. Blue Coat does not recommend this option. Most applications fit into one of the defined values.

For conceptual information about configuring the SG appliance to manipulate traffic based on type of service, refer to "Managing QoS and Differential Services" on page 194.

Combined Destination Objects Allows you to create an object that combines different destination types. Refer to “Using Combined Objects” on page 128.

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 Admin DNS SOCKS SSL Auth Acc Acc Auth Int

SSL Acc

Web Web Web Fwding Auth Acc Cont

Destination IP Address/Subnet

x

x

x

x

x

x

Destination Port

x

x

x

x

x

x

Request URL

x

x

x

x

x

x

Request URL Category

x

x

x

x

x

Server URL

x

x

Server Certificate

x

x

Server Certificate Category

x

x

File Extensions

x

x

HTTP MIME Types

x

x

Category

x

Server Negotiated Cipher

x

Server Negotiated Cipher Strength

x

Server Negotiated SSL Version

x

Apparent Data Type

x

Response Header

x

Response Code

x

75

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference Object

Admin Admin DNS SOCKS SSL Auth Acc Acc Auth Int

SSL Acc

Web Web Web Fwding Auth Acc Cont

Response Data

x

IM Buddy

x

IM Chat Room

x

DNS Response IP Address/ Subnet

x

RDNS Response Host

x

DNS Response CNAME

x

DNS Response Code

x

Server Connection DSCP Trigger

x

Combined Objects

x

x

x

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

Because of character limitations required by the generated CPL, only alphanumeric, underscore, dash, ampersand, period, or forward slash characters can be used to define a service object name.

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. The rule applies if ICAP scanning detects a virus.

Request Forwarded This is a static object. Automatically created when upgrading from SGOS 4.2.x to SGOS 5.2.x. Refer to the Blue Coat SGOS 5.2 Upgrade/Downgrade Guide.

Client Protocol Specifies the client protocol types and subsets. From the first drop-down list, select a type from the drop-down list: CIFS, Endpoint Mapper, FTP, HTTP, HTTPS, Instant Messaging, P2P, Shell, SOCKS, SSL, Streaming, or TCP Tunneling.

76

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference The second drop-down list allows you to select a protocol subset (these options vary depending on the selected protocol): ❐

All—Applies to all communication using this type of protocol.

❐

Pure—Applies if the protocol is using a direct connection.

❐

Over—Applies if a protocol is communicating through a specific transport method.

Service Name Specify any default or custom proxy service that exists on the SG appliance (created from the Management Console: Configuration > Services > Proxy Services). ❐

The Web Access Layer only displays and accepts proxy services.

❐

The Admin Access Layer only displays and accepts console services.

Protocol Methods Specifies the protocol methods that trigger a rule. To specify a protocol method:

1 2

3

1.

In the Name field, enter a name or accept the default.

2.

From the Protocol drop-down list, select one of the options: FTP, HTTP, HTTPS, Instant Messaging, SOCKS.

3.

Select connection methods. These options vary depending on the selected protocol. The above example demonstrates basic Instant Messaging connections.

77

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference 4.

Click OK.

SSL Proxy Mode Specifies the deployment mode of the SSL proxy: HTTPS Forward Proxy requests, HTTPS Reverse Proxy requests, Unintercepted SSL requests. This objects allows you to apply policy to a subset of SSL traffic going through the SG appliance. For example, this object can be used to enforce strong cipher suites for HTTPS reverse proxy requests while, allowing all ciphers suites for HTTPS forward proxy requests.

IM File Transfer Specifies the rule is applied to IM file transfers, which can be triggered by matching the file name, file size, or both. To specify IM file transfer parameters:

1 2a

2b

3a

3b

1.

In the Name field, enter a name for the object or accept the default.

2.

To trigger by file name:

3.

a.

Select File; in the File field, specify a file name;

b.

From the drop-down list, select if file is matched exactly (Exact Match), if the file contains the name (Contains), or matched by regular expression (RegEx).

To trigger by message size: a. b.

Select Size and enter a range. From the drop-down list, select the size attribute: Bytes, Kbytes, MBytes, or GBytes.

IM Message Text Specifies the rule is applied to IM message text, which can be triggered by any or all of the following: matching content keywords, message size, service type, and whether the content type is text or application.

78

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To specify IM message text parameters:

1 2a

2b

3

3b

4 5

1.

In the Name field, enter a name for the object or accept the default.

2.

To trigger by content keywords:

3.

a.

Select Text; in the Text field, specify a keyword.

b.

From the drop-down list, select if the file contains the text (Contains), or if it is to be matched by regular expression (RegEx).

To trigger by message size: a. b.

Select Size; enter a range. From the drop-down list, select the size attribute: Bytes, Kbytes, MBytes, or GBytes.

4.

To specify the message route, select Route. From the drop-down list, select Service, Direct, or Chat.

5.

To specify message type, select Text or Application. •

Text specifies messages entered by a user.

•

Application specifies messages sent by the client application, such as typing notifications.

IM Message Reflection Allows policy to test whether or not reflection is enabled for the current message and, if enabled, whether it is possible. ❐

Succeeded—IM reflection is enabled and is performed for this message.

❐

Failed—IM reflection is enabled, but not possible for this message because the

recipient is not connected through this SG appliance. ❐

Disabled—IM reflection is not enabled for this message.

The objects are automatically named based on the selection and can be used in any rule.

Streaming Content Type Specifies streaming protocols.

79

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To specify streaming protocols: 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 2a 2b 2c

1.

In the Name field, enter a name for the object or accept the default.

2.

Select an option: a.

No errors—An ICAP scan was performed without scanning errors.

b.

Any errors—An ICAP error code was returned during a scan.

c.

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.

80

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Health Check This condition tests whether the current transaction is a health check transaction. Optionally, the condition tests whether the transaction is that of a specific health check. To create a Health Check object:

1 2a 2b 2c

1.

Select one of the following: •

Not a health check: Transaction is not identified as a health check.

•

Any Health Check: A health check service of any type was matched.

•

Any of the selected health checks below: A health check of the selected types was

matched. 2.

3.

If you selected Any of the selected health checks below: a.

Select one or more error types (use Control + Left-click to highlight multiple errors).

b.

Click Add to move the errors to the Selected field.

c.

Name the object or accept the default name.

Click OK.

Health Status This conditions tests whether the target of the specified health check is health or sick.

Combined Service Objects Allows you to create an object that combines different service types. Refer to “Using Combined Objects” on page 128.

81

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Service Column/Policy Layer Matrix The following matrix lists all of the Service column objects and indicates which policy layer they apply to. Object

Admin Admin DNS Auth Acc Acc

SOCKS SSL Auth Int

SSL Acc

Web Web Auth Acc

Web Cont

Fwding

x

x

x

x

x

Using HTTP Transparent Authentication x

Request Forwarded

x

Virus Detected x

Client Protocol x

Service Name

x x x

Protocol Methods x

SSL Proxy Mode IM File Transfer

x

IM Message Text

x

IM Message Reflection

x

Streaming Content Type

x

ICAP Error Code

x

Health Status

x

Health Check

x

Combined Objects

x

x x

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.

82

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To configure time restrictions:

1

2

3

4

5

6

7

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 SG appliance internal clock. UTC sets the rule to use the Universal Coordinated Time (also known as Greenwich 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.

To specify a day of the week restriction, select Enable; in the Specific Weekday Restriction field, select one or more days.

5.

To specify a day of the month range restriction, select Enable; in the Specify Day of Month Restriction field, select the days, which are numbered from 01 to 31. To limit the range to specific day, configure the numbers to be the same. For example, selecting 22 and 22 specifies the rule to apply only the 22nd day of every month.

83

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference 6.

To specify a restriction that spans one or more months, select Enable; in the Specify Annually-Recurring Date Restriction field, select the month and day ranges. This calendar restriction applies every year unless the restriction is altered. Overlapping months is allowed, similar to the behavior of day ranges in Step 3.

7.

To specify a one-time only restriction, select Enable; in the Specify Non-Recurring Date Restriction field, select the year, month, and day ranges. This calendar restriction applies only during the time specified and will not repeat.

8.

Click OK.

Combined Time Object Allows you to combine a time object that adheres to multiple time restrictions. See “Using Combined Objects” on page 128.

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 Admin DNS Auth Acc Acc

SOCKS SSL Auth Int

SSL Acc

Web Web Auth Acc

Time

x

x

Combined Objects

x

x

Web Fwding Cont

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

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.

84

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Force Deny (Content Filter) This is a static objects Forces a request to be denied, regardless if rules in subsequent layers would have allowed the request. In the access logs, the Content Filter moniker allows you to identify policy denies based on content filtering versus other reasons.

Allow Content From Origin Server This is a static object.

Connect Using ADN When Possible/Do Not Connect Using ADN These are static objects. Connect Using ADN When Possible instructs the SG appliance to use the byte caching tunnels (used in Application Delivery Network (ADN) deployments). Do Not Connect Using ADN prevents the use of tunnel connections.

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 SG appliance to be selected through VPM. Note: In the SOCKS Authentication policy layer, the object is SOCKS Authenticate.

85

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To create an Authenticate object:

1 2 3 4 5 6

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

3.

Optional (in the Web Authentication policy layer only): from the Mode drop-down list, select a mode. The mode determines the way the SG appliance 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 SG appliance uses an explicit proxy challenge. No surrogate credentials are used. This is the typical mode for an authenticating explicit proxy.

•

Proxy IP—The SG appliance uses an explicit proxy challenge and the client's IP address as a surrogate credential.

86

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

4.

•

Origin—The SG appliance acts like an OCS and issues OCS challenges. The authenticated connection serves as the surrogate credential.

•

Origin IP—The SG appliance 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 SG appliance 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 SG appliance 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 SG appliance does not support origin-redirects with the CONNECT method.

•

SG2—The mode is selected automatically, based on the request using the SGOS 2.x-defined rules.

(Optional) If you selected a Form mode in Step 3, the Authentication Form, New Pin Form, and Query Form drop-down lists becomes active. •

Authentication Form—When forms-based authentication is in use, this property selects the form used to challenge the user.

•

New Pin Form—When forms-based authentication is in use, this selects the form to prompt user to enter a new PIN.

•

Query Form—When forms-based authentication is in use, this selects the form to display to the user when a yes/no questions needs to be answered. Note: The New Pin Form and the Query Form are only used with RSA SecurID

authentication. In most deployments, the default form settings should be adequate. However, if in your enterprise you have customized authentication forms configured (on the SG appliance Management Console: Configuration > Authentication > Forms), you can select them from the drop-down lists. For example, HR_PIN. 5.

Click OK.

Users are prompted to provide a valid user name and password.

Authenticate Guest Allows a user to be authenticated as a guest user. One scenario is to allow access to a user who might otherwise be considered unauthenticated. Another is where no authentication is required, but you want to track access. For more information, see the Controlling Access to the Internet and Intranet chapter in Volume 4: Securing the Blue Coat SG Appliance.

87

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To create an Authenticate Guest object:

1 2 3

4

1.

In the Name field, name the object or accept the default.

2.

In the Guest Username field, enter the name the guest is given. This name appears in the access logs.

3.

In the Guest Realm area, select one of the following options:

4.

•

Use realm:

•

Use realm from previous authenticate request:

In the Guest Surrogate Refresh Time area, select one of the following options: •

Use realm’s surrogate refresh time:

•

User surrogate refresh time:

Add Default Group A default group can be assigned to any realm. You can assign users to these groups, which are valid when authorization succeeds, fails, or not attempted. Default groups support guest users, which are users who are not authenticated against a realm, but are given a guest name and allowed access to specific information. For example, you create a default group that all guest users are assigned to, which makes it easier to track and log. Default Groups are configured the same as described in “Group” on page 53.

Force Authenticate Forces the user to authenticate even though the request is going to be denied for reasons that do not depend on authentication. This action is useful to identify a user before the denial so that the username is logged along with the denial. See Volume 4: Securing the Blue Coat SG Appliance for a description of the fields in this object.

88

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Note: In the SOCKS Authentication policy layer, the object is Force SOCKS Authenticate.

Bypass Cache This is a static object. Prevents the cache from being queried when serving a proxy request, and prevents the response from the origin server from being cached.

Do Not Bypass Cache This is a static object. The SG appliance always checks if the destination is cached before going to the origin server; also, the content is cached if cacheable.

Bypass DNS Cache This is a static object. Prevents the request from querying the DNS cache list of resolved lookup names or addresses.

Do Not Bypass DNS Cache This is a static object. The SG appliance always queries the DNS cache list of resolved lookup names or addresses.

Allow DNS From Upstream Server This is a static object. Allows the SG appliance to send requests for data not currently cached to DNS servers.

Serve DNS Only From Cache This is a static object. Instructs the SG appliance 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 SG appliance appends the suffixes in the DNS imputing list to host names 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 SG appliance 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 SG appliance 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.

89

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

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 SG appliance to use its default freshness verification.

Block/Do Not Block PopUp 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, see Section A: "Blocking Pop Up Windows" on page 170.

Force/Do Not Force IWA for Server Auth These are static objects. When configured for explicit proxy, Internet Explorer (IE) does not support an IWA challenge from an origin server. If Force IWA for Server Auth is applied, the SG appliance converts the 401-type server authentication challenge to a 407-type proxy authentication challenge, which IE supports. The SG appliance also converts the resulting Proxy-Authentication headers in client requests to standard server authorization headers, which allows an origin server IWA authentication challenge to pass through when IE is explicitly proxied through the SG appliance.

Log Out/Do Not Log Out Other Users With Same IP These are static objects. If more than one user is logged in at the IP address of the current transaction, this property logs out all users from the current IP address except the user of the current transaction.

Log Out/Do Not Log Out User These are static objects. This property logs out the login referenced by the current transaction.

90

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Log Out/Do Not Log Out User’s Other Sessions These are static objects. If a user is logged in at more than one IP address, this property logs out the user from all IP address except the IP address of the current transaction.

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 SG appliances manage the traffic and routes it depending on each SG appliance fail open and fail closed configurations. For detailed information about this deployment, refer to the Instant Messaging chapter in Volume 3: Web Communication Proxies.

Support/Do Not Support Persistent Client Requests These are static objects. Allowing persistent connections to the SG appliance from clients reduces load improves the all-around performance of the network. This object specifies whether or not to allow persistent server connections.

Support/Do Not Support Persistent Server Requests These are static objects. If the back-end authentication authority (such as LDAP, RADIUS, or the BCAAA service) receives large numbers of requests, you can configure the SG appliance to use persistent connections to the server. This dramatically reduces load on the back-end authentication authority and improves the all-around performance of the network. This object specifies whether or not to allow persistent server connections.

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, refer to the Instant Messaging chapter in Volume 3: Web Communication Proxies.

Require/Do Not Require Client Certificate These are static objects. For the SSL Proxy, specifies whether a client (typically a browser) certificate is required or not. ❐

In forward proxy deployments, this is used to either request consent certificates or to support certificate realm authentication.

❐

In reverse proxy deployments, client certificates are requested for certificate realm authentication.

Also, see “Set Client Certificate Validation” on page 93.

Trust/Do Not Trust Destination IP These are static objects. The Trust Destination IP object instructs the SG appliance to trust the IP address sent by the client, forgoing a DNS lookup. This is designed for transparent and ADN deployments. Conversely, the Do Not Trust Destination IP instructs the SG appliance to always perform a DNS lookup.

91

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Deny This object provides the same functionality as the “Force Deny” on page 84 object, but provides the option to re-allow authentication and insert substitution strings.

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. To create a Return Exception object:

1 2a 2b 3 4 5

1. 2.

In the Name field, enter a name for the object or leave as is to accept the default. Perform one of the following: a.

Standard exception type: select one from the Built-in exception drop-down list.

b.

Custom exception (which already must be defined on the SG appliance) type: select one from the User-defined exception drop-down list.

3.

Optional: Select Force exception even if later policy would allow request to supersede other policy that applies to this request.

4.

Optional: Select Allow re-authentication to allow the user to re-enter credentials should the first attempt fail.

5.

Optional: in the Details field, enter a message that is displayed along with the summary and exception ID on the exception page displayed to the user when the exception is returned.

The above example creates an object named DNSException2 that upon a DNS server failure returns a message to the user instructing them to contact their support person. To create custom exceptions, see Section D: "Defining Exceptions" on page 176.

92

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Return Redirect Aborts the current transaction and forces a client request to redirect to a specified URL. For example, used to redirect clients to a changed URL; or redirecting a request to a generic page stating the Internet access policy. Applies only to HTTP transactions. .

Note: Internet Explorer (IE) ignores redirect responses from FTP over HTTP requests, although Netscape Navigator obeys the redirect. To avoid problems with IE, do not use redirect when url.scheme=ftp.

If the URL that you are redirecting the browser to also triggers a redirect response from your policy, then you can put the browser into an infinite loop. In the Name field, enter a name for the object (or leave as is to accept the default); in the URL field, enter the redirect destination URL. Example An object that redirects clients to an HTML policy statement page.

Set Client Certificate Validation If a client certificate is requested (see “Require/Do Not Require Client Certificate” on page 91), this object specifies whether the requested client certificate is validated. If Also check certificate revocation is selected, this is checked from a Certificate Authority. For information on using CRL, refer to Volume 2: Proxies and Proxy Services.

Set Server Certificate Validation This feature is enabled by default. The SSL Proxy performs checks on server certificates. To mimic the overrides supported by browsers, the SSL Proxy can be configured to ignore failures for the first three checks in the list.

93

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To add a Server Certificate Validation object:

1

2

3

If this feature is disabled, the features valid when enabled are greyed out.

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

(Optional) Select one or more to ignore certain failures:

3.

•

Ignore a hostname mismatch: Ignores the comparison of hostname in URL and certificate (intercepted connections only).

•

Ignore certificate expiration: Ignores the verification of certificate dates.

•

Ignore untrusted issuer: Ignores the verification of issuer signature.

The certificate revocation list (CRL) option: If Also check certificate revocation is selected, this is checked from a Certificate Authority. For information on using CRL, refer to Volume 4: Securing the Blue Coat SG Appliance. Note: Two built-in exceptions can be used to notify the user that the verification of the server's certificate failed: exception.ssl_server_cert_expired and exception.ssl_server_unknown_ca. For information on using exceptions, see Chapter 4: Advanced Policy, Section D: "Defining Exceptions" on page 176.

Enable HTTPS Intercept The HTTPS Intercept object enables the SG appliance to act as an HTTPS Forward Proxy, providing performance gains and security (authentication, content filtering, anti-virus scanning) for HTTPS traffic before it is delivered to clients. This object allows HTTPS content to be intercepted and examined.

94

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To create an HTTPS Intercept object:

1 2a 2b 2c

2d

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

To allow SSL content to be examined, select: a.

b.

Issuer Keyring: Accept the default keyring or select this option and from the drop-down list select a previously generated keyring. This is the keyring used for signing emulated certificates. Hostname: The hostname you enter here is the hostname in the emulated

certificate. c.

Splash Text: The limit is 200 characters. The splash text is added to the emulated certificate as a certificate extension. The splash text is added to the emulated certificate as a certificate extension. For example: Visit http://example.com/https_policy.html

To add substitution variables to the splash text, click Edit and select from the list. d. Splash URL: The splash text is added to the emulated certificate as a certificate extension. The SSL splash can be caused by such occurrences as when a browser receives a server certificate signed by an unknown CA, or a host miss-match. Note: Not all browsers display the splash text and splash URL correctly.

Enable HTTPS Intercept on Exception An HTTP Intercept on Exception object is used to intercept SSL traffic if there is an exception, such as a certificate error or policy denial. This differs from the HTTPS Intercept object, which intercepts all HTTPS traffic. For information on configuring an HTTPS Intercept on Exception object, see“Enable HTTPS Intercept” on page 94.

95

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Disable SSL Intercept This is a static object. Selecting this object disables HTTPS interception.

Send IM Alert Defines a message that is sent to an IM user by the SG appliance. The message is triggered by the IM parameters defined in the policy (for example, client login, sent or received messages, and buddy notification). Volume 3: Web Communication Proxies provides more information about regulating IM through the SG appliance, as well as VPM examples. Example A message that informs IM users their messaging is logged.

Modify Access Logging Defines access logging behavior. ❐

Disable all access logging—No activity is logged for the requests matched by the rule.

❐

Reset to default logging—Resets to logging the request to the default log specified by

the SG appliance configuration, if one exists. ❐

Enable logging to—Enables logging of requests matched by this rule to the specified

log. ❐

Disable logging to—Disables logging of requests matched by this rule to the specified

log. Example: Enable logging P2P logging for this rule.

96

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Override Access Log Field Allows you to manipulate access log entries. For any specific log value, you can suppress the value, encode the value in Base64, or rewrite the value. To override access log fields:

1 2 3

4

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

From the Log Name drop-down list, select a log (must already be configured on the SG appliance).

3.

From the Field Name drop-down list, select an access log field.

4.

Select one of the following: •

Log original value—Records unmodified value in the access log.

•

Suppress value—Prevents value from appearing in the access log.

•

Base64 encode value—Records an encoded version of the value in the access log.

97

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference •

Rewrite value—In the field, enter a string that replaces the value. Clicking Edit calls the Select The Rewrite String dialog. The substitution variables instruct the SG appliance to append specific information to the object. The variables are categorized alphabetically, according to prefix. Note: Some variables do not have prefixes, which allows you to substitute the value with information defined by other field types.

5.

Click OK.

The above example creates an object called CEOLogRewrite that suppresses log entries so persons, such as support personal, cannot view economically sensitive information to gain improper knowledge.

Rewrite Host Rewrites host component of a URL, specifying either Windows Media, Real Media, or all protocols. Use this to redirect the request to a different host. For example, rewrite www.traning1.com to www.training2.com. You can create and name multiple rewrites, but you can only specify one per rule. To specify a rewrite:

1 2 3 4

1.

In the Name field, enter a name or leave as is to accept to the default.

2.

From the Scheme drop-down list, Windows Media, Real Media, or All to rewrite all URLs, regardless of protocol.

3.

In the Pattern field, enter a host name.

4.

In the Replacement field, enter the name the pattern is rewritten to.

5.

Click OK.

Reflect IP Specifies which IP address is used when making connections to upstream hosts.

98

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To create a Reflect IP object:

1

2

1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

In the In outgoing client IP, reflect field, select one of the following:

3.

•

Do not reflect IP—Disables reflecting IPs; the SG appliance uses the IP address of the interface that request is sent out on.

•

Incoming client IP [IP spoofing]—Reflects the client IP address.

•

Incoming proxy IP—Reflects the IP address of where the request arrived to.

•

Proxy IP—Specifies to reflect a specific IP of the SG appliance; enter the IP address in the field.

•

Use services configuration—Specifies whether to reflect IP in the configuration of the service which is used to process the request.

Click OK.

Example The above example reflects another IP address configured on the SG appliance.

Suppress Header Specifies one or more standard headers that are suppressed (not transmitted) on the outbound request, the outbound response, or both.

99

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To create a Suppress Header object:

1

2

3

1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

Select Request, Response, or Both. The valid headers vary for requests and responses. Both displays a small subset of headers valid for requests and responses.

3.

Select one or more header types from the list.

4.

Click OK.

The above example creates an object called EconomicConfidentialAccess to be used in a rule suppresses headers so specified users can access economically sensitive information without people, such as support personal, being able to gain knowledge of sources.

Control Request Header/Control Response Header Allows you to control and modify request or response headers by: ❐

Inserting a header with a specific value.

❐

Rewriting the value of a specific header.

❐

Suppressing a specific header.

100

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To create a Request Header or Control Response Header object:

1 2 3 4

1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

From the Show drop-list select the viewing field from All to Standard or Custom, as desired. Standard displays only the default standard headers. Custom displays any admin-defined headers that exist.

3.

From the Header Name list, select a standard (pre-defined) header or a custom header if one has been defined.

4.

Select an action:

5.

•

Suppress—The header is not visible.

•

Set value—Replace the header with a string or value.

•

Append to value—Add a string or value to the existing header.

Click OK.

Notify User This action displays a notification page in the user’s Web browser. A user must read the notification and click an Accept button before being allowed to access the Web content. You can customize the following: ❐

The page title, notification message, and the Accept button.

❐

The conditions that cause a notification to be displayed again. By default, the notification is displayed each time a user begins a new Web browsing session (reboots, logs out, or closes all Web browser windows). You can configure renotification to occur for each new visited host or Web site, or after a time interval. Note: The Accept button click action is logged if HTTP access logging is enabled. A URL is logged that contains the string: accepted-NotifyName, where NotifyName is the name of the Notify User object.

101

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference This feature is designed to provide the following functionality: ❐

Web-use compliance: A compliance page is a customized notification page displayed on a user’s Web browser when attempting to access the Internet. This page ensures employees read and understand the company’s Acceptable Use Policy before Internet use is granted. Typically, a compliance notification is displayed each time a browser is opened, but you can configure a time condition to display the page at specific intervals or times of the day, week, or month.

❐

Coach users: A coaching page displays when a user visits a Web site that is blocked by content filtering policy. This page explains why the site is blocked, the consequences of un-authorized access, and a link to the site if business purposes warrants access. A coaching page is configured to display each time a user visits a new Web page that is barred by content filtering policy; however, you can also configure this page to appear at different time intervals.

To configure HTML notification:

1

2 3

4

5

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

In the Title field, enter a name that is the title of the page (text only; no HTML is allowed).

3.

In the Body field, compose a block of HTML that displays the message to the user. You can also customize the Accept link or button text. The HTML body must contain an Accept button or link. The default is:

102

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference Accept

You can also use a button image (the image resides on an external Web server, as in the following example:

If you use an HTML editor to compose code, you can paste it into the VPM; however, only copy the HTML from the tag to the tag. 4.

Under Notify mode, select an option that determines notification when visiting a new Web site: •

Notify once for all hosts—The notification page is displayed only once; this is used for configuring compliance pages. This option uses a Virtual Notify URL. If you must change the URL from the default value, please read the limitation section following this procedure. Note: This option might cause users to experience some noticeable Web

browsing slowness. •

Notify only once for related domains—The notify page reappears each time the user visits a new Web site; this is used for configuring coaching pages. Note: This option interferes with some Web advertising banners. In some

cases, the notification page appears inside the banner. In other cases, banner ads are disabled by javascript errors. To fix these problems, do not serve notification pages for URLs that belong to the Web Advertising, Advertising, or Web Ads category. The actual name of this category varies with the content filtering vendor, and some vendors do not have an equivalent. •

5.

Notify on every host—The notify page reappears each time the user visits a new Web host. Blue Coat recommends that only highly experienced administrators employ this option. In addition to breaking banner ads, as described above in the previous option, this option, on some Internet Web sites, might cause Javascript errors that impair the functionality of the site.

Under Notify users again, select an option that specifies when the notification expires and re-notification is required: •

At next browser session— The notification page does not reappear until the next browser session. When a user reboots, logs out, or closes all Web browser windows, this ends the browser session.

•

After (time interval)—Notification reoccurs after the defined elapsed time (minutes or hours); this is useful for coaching.

•

After (specific time)—Notification reoccurs at a specific time of day. You can specify an interval of days; this is useful for compliance. Note: The time is referenced from the local workstation. If a compliance page is configured, verify the workstations and SG appliance clocks are synchronized.

103

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference The above example creates a Notify Object with a custom message, set to display once a day after 7 AM. Interactivities and Workarounds If you must change the default Virtual Notify URL, consider the following: ❐

The Virtual Notify URL consists of an HTTP domain name or IP address (http://); a port number is optional.

❐

Do not use a host name that is explicitly defined as a trusted site on Internet Explorer 6 for Windows XP, Service Pack 2. Furthermore, only use domain names that contain dots. If you use domain names that do not contain dots, the HTTP redirects generated by the notification action causes Internet Explorer to display false warning messages each time the user is redirected from an untrusted site to a trusted site, or the other way around.

❐

For transparent proxy deployments, the domain name must be DNS-resolvable to an IP address that is in the range of destination IP addresses that are routed to the SG appliance.

Policy Interactions This action generates CPL that might interfere with other policy or cause undesired behavior. Enhancements will occur in future SGOS releases. For this release, consider the following guidelines: ❐

Do not create VPM policy that modifies the Cookie request header.

❐

Do not create VPM policy that modifies the Set-Cookie and P3P response headers.

❐

Notification pages exist in the browser history. Therefore, if you click Accept and are taken to the requested page, then click the back button, you get the notification page again.

❐

If you have a chain of SG appliances, with different notification pages configured on each appliance in the chain, then each notification page must have a different object name.

Strip Active Content Strips HTTP tags from specified active content HTML pages. For each item you select for removal, you can also create a customized message that is displayed to the user. Note: Pages served over an HTTPS tunneled connection are encrypted, so the content cannot be modified.

See Chapter 4: Advanced Policy, Section B: "Stripping or Replacing Active Content" on page 172 for detailed information about the different types of active content.

104

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To create a Strip Active Content object:

1

2 3

1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

Select the active content to be stripped.

3.

The default message in the Replacement Text column is Active Content Removed. To replace the default message, double click the field, enter a message, and press Enter. See the examples in the screenshot, Java applets have been removed.

Exempting the SG Appliance Stripping active content might interfere with Web applications deployed on your intranet. For example, if you create a policy rule that removes Java applets, and the destination defined in the rule contains an IP address of a SG appliance functioning as a proxy, the policy rule actually disables the Management Console because the Console itself is comprised of Java applets. To prevent this, for each SG appliance functioning as a proxy, create a rule that exempts the IP address of the SG appliance from the stripping action. 1.

Click Add Rule.

2.

Click Move Up; the rule to exempt the SG appliance must precede the rule that strips active content.

3.

In the Destination field, enter the SG appliance IP address.

4.

With the IP address entered, right-click it in the Destination field and select Negate from the drop-down list.

5.

In the Action field, enter the Remove Active Contents, Java Apps action.

105

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Figure 3-10. Exempting a SG appliance IP Address

HTTP Compression Level Allows you to set the level of compression to low, medium, or high. When configuring, consider that a higher compression level consumes more CPU resource. Note: If you enable HTTP Compression using the VPM but do not specify the HTTP Compression Level using VPM policy, then by default the level is Low.

To specify an HTTP compression level: 1.

2.

Select a compression level option: •

Low—Equivalent to compression level 1.

•

Medium—Equivalent to compression level 6.

•

High—Equivalent to compression level 9.

Click OK.

The object is automatically named as Compression Level Low, Medium, or High.

Set Client HTTP Compression Specifies the behavior when the client wants the content in a different compression form than is in the cache. To specify compression actions: 1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

This object has two instructions: •

A client requests compressed content, but only uncompressed content is available. Select to either compress the content before serving it, or serve uncompressed content.

•

A client requests uncompressed content, but only compressed content is available. Select to either uncompress the content before serving it, or serve compressed content.

The default is to compress or decompress content, respectively, before serving it. 3.

Click OK.

For recommended compression configurations, refer to Volume 2: Proxies and Proxy Services.

106

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Set Server HTTP Compression Enables or disables HTTP compression. To specify compression options: 1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

Select a compression option: • •

Disable HTTP compression—The default. Objects are not compressed. Use client HTTP compression options—Default to the type of content requested by

the client. •

Always request HTTP compression—Force clients to always request compressed

content. 3.

Click OK.

For recommended compression configurations, refer to Volume 2: Proxies and Proxy Services.

Manage Bandwidth Allows you to manage bandwidth for all protocols or specific protocols, on both inbound and outbound traffic. To create a manage bandwidth object: 1.

In the Name field, enter name for the object or leave as is to accept the default.

2.

Select to limit bandwidth on the: Client side or Server side.

3.

•

Client side—Traffic flowing between a client and the SG appliance.

•

Server side—Traffic flowing between a server and the SG appliance.

Select to limit bandwidth for: Inbound or Outbound traffic. •

Inbound—Network packets flowing into the SG appliance. Inbound traffic mainly consists of packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object and packets originating at the client and sent to the SG appliance for Web requests.

•

Outbound—Network packets flowing out of the SG appliance. Outbound traffic mainly consists of packets sent to the client in response to a Web request and packets sent to an OCS or other service (such as a virus scanner) to request a service.

4.

Select a Bandwidth Class from the drop-down list.

5.

Click OK; click Save Changes.

For complete information about Bandwidth Management, refer to Volume 5: Advanced Networking.

ADN Server Optimization Specifies whether byte caching is employed on either (branch or core) or both sides of an Application Delivery Network connection (specified IP addresses in the rule). Byte caching reduces WAN latency.

107

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference ❐

Optimize traffic in both directions: Apply Byte Caching to traffic coming and leaving

the server. ❐

Optimize only inbound traffic: Apply Byte Caching only to traffic coming into the

server. ❐

Optimize only outbound traffic: Apply Byte Caching only to traffic leaving the server.

❐

Do not optimize traffic: Do not allow Byte Caching on specified connections.

Modify IM Message In IM clients, replaces or appends the given text that is displayed to IM messages in clients that are logged in through the SG appliance. For example, use with Time Object to inform users that Instant Messages sent outside the corporate network are not allowed during business hours. To create an IM message modification object:

1 3 2

1.

In the Name field, enter a name for the object, or accept the default.

2.

In the text field, enter a message that appears on an IM client if the rule applies.

3.

Select one of the following: •

Set message text—Replaces the text displayed to the IM client. See the example in

the screenshot. •

Append to message text—The specified text is added to the IM message.

Volume 3: Web Communication Proxies provides more information about regulating IM through the SG appliance, as well as VPM examples.

Return ICAP Feedback Specifies to display a patience page to the client or employ data trickling if ICAP scanning exceeds the given time duration.

108

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To return ICAP feedback:

1

2a 2b

2c

3a 3b 3c

1.

Name the object or accept the default.

2.

Select interactive traffic (Web browser based requests) options: a.

Do not provide feedback...: Users do not receive feedback for longer ICAP

scans. b.

Provide feedback after seconds: Specifies how far into the scan to wait

before providing feedback (patience page or data trickling) to the client.

c.

•

The range for the patience page method is 5 to 65535.

•

The range for the trickling methods is 0 to 65535.

Select a feedback method: •

Return patience page: The SG appliance displays a (customizable) page on the Web browser client, informing the user a content scan is in progress.

•

Trickle object data from start: The more secure method because most of the

object data does not reach the client, pending the result of the content scan. However, users might become impatient, close the request, and reinitiate the connection. •

3.

Trickle object data at end: The lesser secure method because the client receives most of the object data, pending the result of the content scan. This method provides the better user experience because they perceive the connection as almost complete.

Select non-interactive traffic (non-Web browser based clients, such as flash players or automatic updaters) options. See descriptions in Step 2.

109

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference 4.

Click OK.

Enter a time value (in seconds) that the SG appliance 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.

Patience page management and limitations are described in Volume 7: Managing Content.

Set Dynamic Categorization Dynamic categorization extends the process of categorizing a URL. Traditional content filtering involves searching of massive URL pattern databases, which are published by vendors and downloaded to the SG appliance at specified intervals. As new content constantly reaches the Web, the limitation is that it cannot be filtered until its existence is discovered, added, and uploaded. Dynamic categorization enhances content filtering by scanning a new Web page, attempting to determine its contents, and categorizing accordingly in real time. When an un-categorized page is first encountered, the SG appliance calls an external service with a categorization request. Once the content is scanned, a category is assigned (a majority of the time). For related information, refer to the Content Filtering chapter in Volume 7: Managing Content. To configure dynamic categorization: 1.

2.

Select a mode: •

Do not categorize dynamically—The loaded database is consulted for category information. URLs not in the database show up as category none.

•

Categorize dynamically in the background—Objects not categorized by the database are dynamically categorized as time permits. Proxy requests are not blocked while DRTR is consulted. Objects not found in the database appear as category pending, indicating that DRTR was requested, but the object was served before the DRTR response was available.

•

Categorize dynamically in realtime—The default. Objects not categorized by the database are dynamically categorized on first access. If this entails consulting the DRTR service, the proxy request is blocked until DRTR responds.

•

Use dynamic categorizing setting from configuration—Default to the SG appliance configuration (Content Filtering>Blue Coat>Dynamic Categorization).

Click OK.

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 SG appliance and the external service.

110

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To determine external filter service request behavior:

1 2 3 To instruct all request types defined in the rule to not route through an external filter service for content filtering.

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 SG appliance; Configuration > External Services).

3.

In the Error handling field, select one of the following option: •

To deny all requests if a communication error occurs, select Deny the client request.

•

To allow requests to go through without content filtering, select Continue without further external service processing.

4.

Click OK.

Set ICAP Request Service Specifies which installed ICAP service or service group a content request routes to or bypasses, and specifies what occurs if a communication error occurs between the SG appliance and the ICAP server.

111

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To determine ICAP request behavior:

1

2 3 To instruct all request types defined in the rule to not route through an ICAP request service for AV scanning.

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

To instruct all request or response types defined in the rule to route to a specific ICAP service, select Use ICAP Request Service; from the drop-down list, select the ICAP request modification service or service group (which must already exist on the SG appliance; Configuration > External Services > ICAP).

3.

In the Error handling field, select one of the following option: •

To deny all requests or responses if a communication error occurs, select Deny the client request. This is the default and recommended by Blue Coat.

•

To allow requests or responses to go through without ICAP scanning, select Continue without further ICAP request processing. Be advised that this presents a

content integrity risk. Note: When the ICAP service is restored, these objects are scanned and served from the cache if they are requested again.

Set ICAP Response Service Identical to “Set ICAP Request Service” on page 111, but applies to other protocol responses, such as HTTP and FTP. Requires an ICAP response modification service created on the SG appliance (Configuration > External Services > ICAP).

Set FTP Connection For an outgoing request over FTP, specifies whether the FTP connection should be made immediately or deferred, if possible. The benefit of deferring connections is that requests for previously cached content can be served without contacting the origin server, which reduces the FTP load on that server.

112

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Set SOCKS Acceleration Specifies whether or not accelerate SOCKS requests, and defines the transport method. To set SOCKS acceleration: 1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

Select one of the following:

3.

•

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.

Click OK.

Disable SSL Detection Important:

This object is only required to preserve user-selectable SSL detection options that existed in SGOS 4.2.x but are not available in SGOS 5.2.x.

SGOS 4.2.x allowed you to select whether SSL was detected over HTTP, SOCKS, and/or TCP. These are options are not user-selectable in SGSO 5.2.x, but you can use this object to preserve the previous behavior. To preserve 4.2.x SSL detection behavior:

1

2

1.

Select one of the following: •

If in SGOS 4.2.x you configured all proxies to not detect SSL, select All Tunneled Traffic and proceed to step 3.

•

If in SGOS 4.2.x you configured SSL detection for one or two proxies, select Traffic Tunneled Over and proceed to step 2.

2.

Select one or more proxies.

3.

Click OK.

113

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference For more information about this feature, refer to the Blue Coat SGOS Upgrade/Downgrade Guide.

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.

Set Client Connection DSCP Value Sets the outgoing differentiated service code point (DCSP) value or action for primary client connections (from the server) matching the DSCP value(s) in the Source column. To set the server to client DSCP value or action:

1 2a 2b 2c 2d

1. 2.

In the Name field, enter a name for the object or leave as is to accept the default. This example sets the DSCP value to CS1 (IP Precedence 1). Selection an action: a.

Echo the inbound packet’s DSCP value: Use the same outbound (point of reference, the SG appliance) packet DSCP value as the inbound value.

b.

Preserve the incoming DSCP value: Track the inbound (from the client) DSCP bits on the primary server connection and use that same value when sending packets to outbound to the server. This is valuable for protocols that have multiple client/server connections. For example, FTP control and data connections. The values remain independent for each connection.

c.

DSCP name: Instead of the incoming DSCP, use the DSCP value selected from

the drop-down list. d. DSCP value: Instead of the incoming DSCP value, use this non-categorized DSCP value (range is 0 to 63). 3.

Click OK.

For conceptual information about configuring the SG appliance to manipulate traffic based on type of service, refer to Chapter 4: Advanced Policy, “Managing QoS and Differential Services” on page 194.

114

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Set Server Connection DSCP Value This object is identical to "Set Client Connection DSCP Value" on page 114, but applies to using the DSCP values or bits from client connections to server connections.

Set ADN Connection DSCP This object specifies DSCP settings for Application Delivery Network (ADN) tunnel connections, which allows you more granular control to regulate WAN traffic. For example, you might not want the DSCP values for packets sent from the OCS and downstream tunnel packets to have the same value. To specify an ADN connection DSCP value:

1a

1b

1.

Select one of the following options: a.

Preserving the incoming DSCP value: This is the default behavior if no other

policy is specified. The ADN proxies (branch and concentrators) preserve the inbound packet DSCP values:

b.

•

The client inbound packet and upstream tunnel packet DSCP values are the same.

•

The server inbound packet to the concentrator and downstream tunnel packet DSCP values are the same.

From the DSCP name drop-down list, select one of the standard DSCP values. The behavior is as follows: •

The DSCP value of the upstream tunnel packets is the selected value until it is reset by an intermediary device.

•

The DSCP value of a downstream packet is the selected value until it is reset by an intermediary device, even if the intermediary device modifies DSCP values of upstream tunnel packets.

Alternately, if your network uses a numerical DSCP value system, select DSCP value (0-63) and enter a value. Note: For more information about DSCP values, see Chapter 4: Advanced Policy, Section F: "Managing QoS and Differential Services".

115

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference Click OK.

Set Authorization Refresh Time Realms that support authorization and authentication separately use the authorization refresh time value to manage the load on the authorization server. These realms include: Local, LDAP, Windows SSO, Novell SSO, Certificate, XML and Policy Substitution. They determine authorization data (group membership, attribute values) separately from authentication, allowing the time the authorization data is trusted to be increased or decreased. For realms that must authenticate the user to determine authorization data, the authorization data is updated only when the user credentials are verified with the authentication server.

Set Credential Refresh Time The credential refresh time value determines how long a cache username and password is trusted. After that time has expired, new transactions that require credential authentication result in a request to the authentication server. A password different than the cached password also results in a request to the authentication server. This value can is only valid for realms that cache the username and password on the proxy and realms that use Basic username and password credentials: LDAP, RADIUS, XML, IWA (with Basic credentials), SiteMinder, and COREid.

Set Surrogate Refresh Time Specifies how long surrogate credentials are trusted in a particular realm.

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 (time to live) 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.

116

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference To set a DNS response:

1 2 3 4a

4b

5

1.

In the Name field, enter a name for the object or leave as is to accept the default.

2.

In the Host field, enter a host name that is returned.

3.

To respond with the IP address of the proxy that is forwarding the request, select Respond with proxy IP.

4.

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 required; click Close. 5.

(Optional) In the TTL field, enter a time-to-live value (how long the response is cached).

6.

Click OK.

Send Reverse DNS Response Specifies which host to return for a reverse DNS response. Optional: define a time-to-live value.

Do Not Cache This is a static object. Specifies that objects are never cached.

117

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Force Cache This is a static object. Specifies that (cacheable) objects are always cached. Objects that are not cacheable (for example, RealMedia file types) and 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 SG appliance 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 SG appliance 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 SG appliance 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 SG appliance. 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 SG appliance 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 SG appliance performs health checks. If that host name resolves to multiple IP addresses that correspond to different servers, the SG appliance fetches content from the available servers and ignores the servers that fail the health check.

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.

118

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

Select SOCKS Gateway Specifies which SOCKS gateway, if any, to use; defines behavior if communication between the SOCKS gateway and the SG appliance 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 SG appliance 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.

Server Byte Caching Specifies whether byte caching is employed on either (branch or core) or both sides of an Application Delivery Network connection (specified IP addresses in the rule). Byte caching reduces WAN latency. ❐

Optimize traffic in both directions: Apply Byte Caching to traffic coming and leaving

the server. ❐

Optimize only inbound traffic: Apply Byte Caching only to traffic coming into the

server. ❐

Optimize only outbound traffic: Apply Byte Caching only to traffic leaving the server.

❐

Do not optimize traffic: Do not allow Byte Caching on specified connections.

Set IM Transport Specifies the transport method used for IM traffic. ❐

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.

Set Streaming Transport Specifies which streaming transport method the rule uses.

119

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference ❐

Auto—Connects using the transport method used by the client.

❐

HTTP—Streaming over HTTP.

❐

TCP—Streaming over TCP.

Authentication Charset The VPM allows you enter non-ASCII in many objects, such user and group names and text for the “Notify User” on page 101 object. This object allows you set the character set to use in conjunction with localized policy. From the drop-down list, select a character set and click OK.

Set IP Address For Authentication Some Application Delivery Network (ADN) configurations in proxy chain deployments mask the source IP address of the request. Policy to set the IP address for authentication is required so that Windows Single Sign On (SSO), Novell SSO, and policy substitution realms can authenticate users. For more information, see Volume 4: Securing the Blue Coat SG Appliance for more information about this type of authentication. To set an IP address for authentication: 1.

Define a name for the object or accept the default.

2.

Click Edit to display the Set Substitution dialog.

3a

3.

Define the substitution strings:

120

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference a.

Select one or more strings and click Insert. For example, your branch user headers contain the request.header.ClientIP HTTP header.

b.

Click OK.

4.

From the IP Address drop-down list, select a substitution string. For example: the $(request.header.Client-IP): sets the address for authentication to the address received from the HTTP Client-IP header.

5.

Click OK.

Permit Authentication Error After an authentication failure occurs, the authentication error is checked against the list of errors that policy specifies as permitted: ❐

If the error is not on the list, the transaction terminates.

❐

If the error is on the list, the transaction is allowed to proceed; however, the user is unauthenticated. Because the transaction is not considered authenticated, the authenticated=yes policy condition evaluates to false and the user has no username, group information, or surrogate credentials. Policy that uses the user, group, domain, or attribute conditions does not match.

121

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference To permit an authentication error:

1

2

1.

2.

3.

Select one of the following: •

Any errors: Allows any type of authentication error.

•

Selected errors: Only allowed if the error matches the selected errors.

If you selected Selected errors: a.

Select one or more error types (use Control + Left-click to highlight multiple errors).

b.

Click Add to move the errors to the Selected field.

c.

Name the object or accept the default name.

Click OK.

Permit Authorization Error After an authorization failure occurs, the authorization error is checked against the list of errors that policy specifies as permitted. ❐

If the error is not on the list, the transaction is terminated.

❐

If the error is on the list, the transaction is allowed to proceed and the user is marked as not having authorization data.

❐

If a user is successfully authenticated but does not have authorization data, the authenticated=yes condition evaluates to true and the user has valid authentication credentials.

122

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference ❐

The user.authorization_error=any evaluates to true if user authorization failed and the user object contains username and domain information, but not group or attribute information. As a result, policy using user or domain actions still match, but policy using group or attribute conditions do not.

Combined Action Objects Allows you to combine an action object that invokes multiple actions. See “Using Combined Objects” on page 128.

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 Admin DNS SOCKS SSL Auth Acc Acc Auth Int

x

Allow Deny (static)

SSL Web Web Web Fwding Acc Auth Acc Cont

x

x

Allow Read-Only Access

x

Allow Read-Write Access

x

x x

Do Not Authenticate

x

x

x

Authenticate

x

x

x

Force Authenticate

x

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 IWA For Server Auth

x

Do Not Force IWA For Server Auth

x

Require Client Certificate

x

Do Not Require Client Certificate

x

Reflect IM Messages

x

Do Not Reflect IM Messages

x

Block IM Encryption

x

123

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference Object

Admin Admin DNS SOCKS SSL Auth Acc Acc Auth Int

SSL Web Web Web Fwding Acc Auth Acc Cont

Do Not Block IM Encryption

x

Trust Destination IP

x x

Not Trust Destination IP Deny

x

x

Return Exception

x

x x

Return Redirect Set Client Certificate Validation

x

Set Server Certificate Validation

x

Set HTTPS Intercept

x

Set HTTPS Intercept on Exception

x

Send IM Alert

x

Modify Access Logging

x

x

Override Access Log Field

x

x

Rewrite Host

x

Reflect IP

x

x

Suppress Header

x

Control Request Header

x

Control Response Header

x

Notify User

x

Strip Active Content

x

Set Client HTTP Compression

x x

ADN Server Optimization Set Server HTTP Compression

x

Modify IM Message

x

Return ICAP Feedback

x x

Set Dynamic Categorization Set External Filter Service

x

Set ICAP Request Service

x

x

Set ICAP Response Service

x

Use Default Caching

x

Set FTP Connection

x

124

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference Object

Admin Admin DNS SOCKS SSL Auth Acc Acc Auth Int

SSL Web Web Web Fwding Acc Auth Acc Cont

Set SOCKS Acceleration

x

Set Streaming Max Bitrate

x

Client Connection DSCP Value

x

x

Server Connection DSCP Value

x

x

Send DNS/RDNS Response Code

x

Send DNS Response

x

Send Reverse DNS Response

x

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

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

Set Streaming Transport

x x

Authentication Charset Combined Objects

x

x

x

x

x

x

Track Object Column Reference A track object defines the parameters for tracking and tracing traffic. All policy layers contain the same trace objects, but tracking parameters are layer-specific.

125

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Note: Because of character limitations required by the generated CPL, only alphanumeric, underscore, and dash characters can be used to define an action object name.

Event Log, E-mail, and SNMP You can customize the event log, E-mail notification, and SNMP with triggers. These triggers are the same for all three object types. To customize an Event Log, E-mail, or SNMP object: 1.

Right-click the Tracking cell in a policy layer and select Set; the Set Track Object dialog appears.

2.

Click New and select Event Log, Email, or SNMP; the appropriate add object dialog appears.

3 4

5a 5b

5c

3.

In the Name field, enter a name for this object or leave as is to accept the default. Note: The e-mail object also contains a Subject field.

4.

In the Message Text field, enter a customized message that appears with each entry.

126

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference 5.

Optional: Add substitution variables. The substitution variables instruct the SG appliance to append specific information to the tracking object. The variables are categorized alphabetically, according to prefix. Note: Some variables do not have prefixes.

In the Substitution Variables field: a.

From the Category drop-down list, select a category to narrow the view to a subset of variables.

b.

The Display Option options allow you to further aggregate the variables by ELFF (Extended Log File Format) or CPL (Content Policy Language).

c.

Select a variable and click Insert. Rolling the mouse over a variable displays a brief description of the variable. Repeat as required.

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. Furthermore, a trace destination can 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: url.domain=aol.com trace.request(yes) trace.rules(all) trace.destination("aol_tracing.html") url.domain=msn.com trace.request(yes) trace.rules(all)trace.destination("msn_tracing.html") client.address=10.10.10.1 trace.request(yes) trace.rules(all)

The resulting actions are: ❐

Requests to the aol.com domain are logged to aol_tracing.html.

❐

Requests to the msn.com domain are logged to msn_tracing.html.

❐

Requests from the client with the IP of 10.10.10.1 are logged to the default location of default.html.

127

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference .

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

The Trace File option can be used in conjunction or separately from the Trace Level option. The default path of the trace file is accessible through one of the following URLs. If the Management Console secure mode is enabled (the default on a new or upgraded system): https://SG_appliance_IP_address:8082/Policy/Trace/default_trace.html

If the Management Console is deployed in non-secure mode: http://SG_appliance_address:8081/Policy/Trace/default_trace.html

Combined Track Object Allows you to combine track objects into one. See “Using Combined Objects” on page 128.

Track Objects/Policy Layer Matrix The following matrix lists all of the Track and column objects and indicates which policy layer they apply to. Object

Admin Admin DNS Auth Acc Acc

SOCKS SSL Auth Int

SSL Acc

Web Web Web Auth Acc Cont

Event Log

x

x

x

x

x

x

Email Log

x

x

x

x

x

x

SNMP Objects

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Trace Combined Objects

x

x

Fwding

x

Comment Object Reference The Comment object allows you to write any text to aid in labeling the policy layer. The text in this field does not impact the policy.

Using Combined Objects As previously discussed, you select one object for as many object types as required for a given rule. Most object types also have the option of using a combined object. This feature allows you to select multiple objects for a given type, thus creating more complex tools. There are two uses for combined conditions: lists and multiple object types. Also consider the Negate option, which exempts the objects in the list. Example One Consider the following example. You want a Web Content policy layer that as an action forces authorization and sends the response to an ICAP service for content scanning.

128

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

1.

In the Set Action Object dialog, select New > Combined Action Object.

129

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

2 3 4 5 Hold Shift to select multiple objects.

Click New to create new objects from this dialog.

6

2.

In the Name field, enter a name for this object or leave as is to accept the default.

3.

In the Description field, enter brief text that explains the intent of this object (for reference).

4.

The Show drop-down list allows you narrow the scope of the displayed objects.

5.

Hold the Shift key and select Check Authorization and Branch_AV_Req.

6.

Click Add. The selected objects appear in the Selected Action Objects field.

7.

Click OK. The CombinedAction1 object appears as a separate, selectable object.

8.

Select CombinedAction1; click OK. The object is now part of the rule. Based on the other parameters specified in the rule, all requests are forced to an upstream server for authorization and the Web responses are subject to content scanning through the ICAP service.

Example Two In the following example, the rule searches for one of the Proxy IP Address/Port objects and one of the streaming client user agents.

130

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference .

Note The VPM displays various warning messages if you attempt to add objects that creates an invalid combined object. However, it is possible to add a combined object to another combined object, even if doing so presents duplication of simple object definitions without receiving validation warnings. For example, the contents of a child combined object might have already been included either within the parent combined object directly, or indirectly within other child combined objects. This is allowable because of the complexity some combined objects and policies can achieve.

Centralized Object Viewing and Managing This section describes how to use the All Objects dialog to view and manage every VPM object.

Viewing Objects The All Objects feature allows you view a list of all objects—both static and userdefined—that currently exist across all layers and columns. To view all configured VPM objects, in the Menu Bar select View > All Objects.

131

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

The objects are displayed according to the policy layer order (click Policy in the menu bar) and the column order (as presented in “Policy Layer and Rule Object Reference” on page 38). To narrow the scope of the displayed objects, select from the Show drop-down list at the top: ❐

All (sort by object name): Displays all objects in alphabetical order.

❐

All (sort by object type): Groups object types together.

❐

You can select to display only the static (predefined) objects for the Source, Destination, Service, and Action columns.

❐

You can select to display or any one object type. For example, you want to only view the user-defined P2P Client objects. Scroll down and select P2P Client Objects.

132

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

View Unused Objects Selecting Show only unused objects displays all static and user-defined objects that are not currently used in any policy layer.

Managing Objects This section describes how to manage objects within the All Objects dialog.

Creating Objects The All Objects dialog also allows you to create objects. Once an object is created, it appears in the list. When creating or editing policy layers, the objects are available to add to rules. To create an object: 1.

Select New. The available columns and relevant objects are displayed in a cascade style.

2.

Select Column > Object. The Add dialog for that object appears.

3.

Define the object as required

4.

Click OK. Note: When creating Combined Objects, not all objects that appear in the left column are valid for more than one policy layer type. For example, the IM User object is only valid in the Web Access Layer > Source column. If you attempt to add an object that is not valid, a dialog appears with that information.

Editing Objects Any user-defined object can be modified. Highlight the object and click Edit. After editing the object, re-install the policy to apply the modified object in every policy layer it exists in.

133

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Deleting Objects You cannot delete an object that is currently part of an installed policy or combined object. Before removing an object, you can use the View>Object Occurrences feature to identify which policy layers contain the object.

Creating Categories This feature allows you create the content filter URL categories that can be used in the Category object. The Destination column in the DNS Access, Web Access, Web Authentication, and Web Content policy layers contain the Category object. Similarly, categories created in the Category object (see “Request URL Category” on page 68) appear in this dialog and can be edited. Create a category 1.

In VPM, select Configuration > Edit Categories. The Edit Categories dialog appears.

2

2.

Select Policy; click Add. The Object Name dialog appears.

3.

Name the category and click OK.

134

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference

4

4.

Drop the Policy list and select the created category; click Edit URLs. The Edit Locally Defined Category Object dialog appears.

Add URLs to create a category of URLs.

5.

Enter URLs appropriate for the content filter category you are creating; click OK.

6.

Click OK in the Edit Categories dialog to complete the category creation.

135

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Note: If other administrators have access to the SG appliance through other workstations and are creating categories either through VPM or with inline

commands, consider that newly-created or edited categories are not synchronized until the policy is installed. When the policy is installed with VPM, the categories are refreshed. If too many categories are created at the same time and confusion occurs, select the File > Revert to Existing Policy on SG Appliance option to restore the policy to the previous state and reconfigure categories.

Refreshing Policy In between occurrences when either VPM is closed and reopened or Install Policies is invoked, VPM does not recognize changes to VPM-managed policy that were made on the SG appliance through another method. For example: ❐

Another administrator opens a separate VPM to make changes.

❐

Another administrator edits the local or central policy file through the serial console.

❐

Another administrator makes edits the local or central policy file.

❐

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.

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 Volume 10: Blue Coat SG Appliance 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.

136

Chapter 3: The Visual Policy Manager

Section C: Detailed Object Column Reference 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.

Click OK.

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 SG appliance 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 Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

Creating the Reverse DNS Lookup Restriction List The list is created from the VPM Menu bar. This prevents the SG appliance 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 Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

137

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section C: Detailed Object Column Reference

Creating the Group Log Order List The list is created from the VPM Menu bar. 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 SG appliance.

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.

138

Chapter 3: The Visual Policy Manager

Section D: Managing Policy Layers, Rules, and Files

Section D: Managing Policy Layers, Rules, and Files This section contains the following topics: ❐

“How Policy Layers, Rules, and Files Interact” —Describes the importance of rule order policy layer order.

❐

“Managing Policy” —Describes how to save and install policies on the SG appliance.

❐

“Installing VPM-Created Policy Files” —Describes how to propagate a policy file created on one SG appliance to another.

❐

“Viewing the Policy/Created CPL” —Describes how to view the underlying CPL that is created with VPM.

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 SG appliance; the state of the VPM user interface is also stored as an XML file on the SG appliance. 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 2: "Managing Policy Files" on page 15.

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 restricting the choices of conditions and properties to those compatible timing requirements. The following table summarizes how to use VPM layers and which CPL layers result. Table 3-4. VPM-Generated CPL Layers Policy Purpose

VPM Layer

CPL Layer

Establish Administrator identities.

Admin Authentication

Control Administrator access.

Admin Authorization

Control DNS access.

DNS Access

Establish SOCKS user identities.

SOCKS Authentication

139

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section D: Managing Policy Layers, Rules, and Files Table 3-4. VPM-Generated CPL Layers (Continued) Policy Purpose

VPM Layer

CPL Layer

Allow HTTPS interception.

SSL Intercept

Control HTTPS traffic.

SSL Access

Establish user identities.

Web Authentication

Control user access.

Web Access

Control content independent of users.

Web Content

Control forwarding.

Forwarding

Note: VPM currently does not support the layer.

Ordering Rules in a Policy Layer The SG appliance evaluates the rules in the order in which they are listed in a policy layer. When it finds a rule that applies to the situation, it skips the remaining rules in the policy layer and goes on to the next policy layer. Consider the following simple example. Assume that a company has a policy that prohibits everyone from accessing the Web. This is a policy that is easy to create with a Web Access layer rule. There are, however, likely to be exceptions to such a broad policy. For example, you require the manager of the purchasing department to be able to access the Web sites of suppliers. Members of the sales department need to access their customer Web sites. Creating Web Access rules for both these situations is also simple. But if you put all these rules in a single policy layer, then the rule prohibiting access to everyone must be ordered last, or the other two rules are not applied. Principle Design Rule: Always go from the specific to the general.

Using Policy Layers of the Same Type Because the SG appliance skips the remaining rules in a policy layer as soon as it finds one that meets the condition, multiple policy layers and a combination of rules might be required to accomplish a task. Consider the following example. A company does not want to prohibit its employees from accessing the Web, but it does not want them to abuse the privilege. To this end, the company wants employees who access the Web to authenticate when they do so; that is, enter a username and password. So the company creates a Web Authentication policy layer with a rule that says: “If anyone from anywhere in the company sends a request to a URL on the Web, authenticate the client before granting access.”

140

Chapter 3: The Visual Policy Manager

Section D: Managing Policy Layers, Rules, and Files The company also allows members of the group Sales to access various sports Web sites only during non-work hours. Given the Web Authentication rule above, these people must authenticate when they do this. But the company feels that it is not important for people going to these sites after hours to authenticate. So the company creates the following Web Access policy-layer rule: ❐

Grant Sales personnel access to sports Web sites from 5:00 PM to midnight. But there are additional issues. Some members of the sales department spend a lot of time watching game highlights on video clips, and this takes up a lot of bandwidth. At the same time, a lot of customers access the company Web site in the evening (during non-work hours), so internal bandwidth should remain manageable. The company, therefore, limits the bandwidth available to the people in the Sales department with a Web Access layer rule that is identical to the one above in all respects except for the action:

❐

Grant Sales personnel access to sports Web sites from 5:00 PM to midnight, but limit the maximum streaming bitrate to 300 kilobits per second.

For both these rules to work, they need to be in separate policy layers. If they were in the same policy layer, the rule listed second would never be applied.

Ordering Policy Layers The order of policy layers is also important. The SG appliance evaluates policy layers in the order in which they are listed in VPM. When the SG appliance is going through policy layers, it does not execute a given rule as soon as it finds that it meets the specific situation. Rather, it compiles a list of all the rules that meet the condition; when it has gone through all the policy layers, it evaluates the list, resolves any apparent conflicts, and then executes the required actions. If there is a conflict between rules in different policy layers, the matching rule in the policy layer evaluated last takes precedence. In the above example, there are two Web Access policy layers: one contains a rule stating that Sales personnel can access certain Web sites without authenticating, and the other states that when they do access these Web sites, limit the available bandwidth. The order of these policy layers is irrelevant. The order is irrelevant because there is no conflict between the rules in the layers. The following is an example in which the order of policy layers does matter. Assume all URL requests from members of the purchasing department are directed to a single proxy server. To discourage employees from surfing the Web excessively during business hours, a company creates a Web Authentication Policy rule that says: “Whenever a client request comes in to the proxy server, prompt the client to authenticate.” Members of the purchasing department, however, need to access specific Web sites for business reasons, and the company does not want to require authentication every time they do this. So they create a Web Access policy rule that says: “If any member of the purchasing department sends a request to a specific URL contained in a combined-object list, allow access.” The policy layer with the first rule needs to come first in evaluation order; it is then overridden by the second rule in a subsequent policy layer. Principle Policy Layer Design Rule Always go from the general to the specific; that is, establish a general rule in an early policy layer, then write exception rules in later policy layers.

141

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section D: Managing Policy Layers, Rules, and Files

About the Layer Guard Rule The VPM layer guard feature allows you to set a condition by which the whole layer is evaluated or not. This saves system resources, especially if you have layers with large numbers of rules. When added, the layer guard is a single rule table that appears above the selected layer. The layer guard rule contains all of the columns available in the layer except for the Action and Track columns. These columns are not required because the rule itself does not invoke an action other than allowing or not allowing policy evaluation for the entire layer. All of the objects valid in the available columns are selectable and configurable in the layer guard rule, just as they are in the layer. You cannot add a layer guard rule until you have created other policy layer rules. To add a layer guard: 1

2

1.

From the Menu Bar, click Edit.

2.

Select Add Layer Guard. The layer guard rule displays above the evaluation rules.

3.

Right-click any column in the layer guard rule; select Set.

142

Chapter 3: The Visual Policy Manager

Section D: Managing Policy Layers, Rules, and Files 4.

Define an object or objects just as you would in a policy layer. These objects determine if the rest of the rules in the layer are evaluated. For example, if you specify a Destination IP address in the layer guard rule, the other rules in the layer are evaluated only when the SG appliance detects the a transaction destined for that IP address.

Note: If you create and install a “Notify User” object, the following layer guard CPL is

automatically added to the Web Access, Web Content, and SSL Access policy layers: "condition=!__is_notify_internal". This is required for compatibility does not

require any user interaction or tasks.

Disabling or Deleting a Layer Guard Rule By default, a layer guard rule is enabled. You can disable (which retains the rule) or delete the rule from the VPM. Right-click Guard and make a selection.

Figure 3-11. Disabling a layer guard rule. Note: Alternately, right-click the layer tab to add, disable, or remove a layer guard rule.

Installing Policies As you add policy layers and rules, your work is saved in a file on the SG appliance. However, policies only take effect after you install the policies and the generated XML has been validated. The SG appliance then compiles the policies into CPL format and saves the resulting policies in the vpm.cpl file. This overwrites any policies previously created using VPM. The appliance saves VPM-generated policies in a single file and loads it all at once. You do not need to load policies separately, as is the case with the local or central policy files. To install policies: ❐

Select File > Install Policies, or

❐

Click Install Policies on the Rule bar. The VPM validates the generated XML for any issues, such as missing layers. If the validation passes, the CPL is generated and the policies are loaded. If the XML fails the validation, a dialog appears allowing you to: •

Revert to the policy currently installed on the SG appliance, or

•

Continue to edit the policy and attempt another installation.

Furthermore, the failed XML file is written to your hard disk; view this file to troubleshoot the failed XML. The default location for this file is: C:\Documents and Settings\user.name\bluecoat\vpm_err.xml

143

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section D: Managing Policy Layers, Rules, and Files Notes The Category and Notify User objects and the DNS Lookup Restrictions, Reverse DNS Lookup Restrictions, and Group Log Order configuration objects generate CPL, regardless if they are or are not included in rules. These specific objects and features allow users to edit categories and lists that might or might not be used in current policies.

Managing Policy This section describes how to manage VPM policy.

Refreshing Policy In between occurrences when either VPM is closed and reopened or Install Policies is invoked, VPM does not recognize changes to VPM-managed policy that were made on the SG appliance through another method. For example: ❐

Another administrator opens a separate VPM to make changes.

❐

Another administrator edits the local or central policy file through the serial console.

❐

Another administrator makes edits the local or central policy file.

❐

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.

Reverting to a Previous Policy If after creating new policies or editing an existing policy you decide to abandon the process and continue with the existing policy installed on the SG appliance, you can revert to that version. All current changes are deleted (VPM provides a verification prompt). To revert to an existing installed policy: Select File > Revert to Existing Policy on SG Appliance.

Changing Policies You can change, edit, delete, add to, and otherwise manage policies created in VPM at any time by returning to VPM and working with policy layers and rules just as you did when creating them.

Managing Policy Layers This section describes how to perform edits of policy layers.

Renaming a Policy Layer The VPM allows you to rename policy layers and disable and re-enable layers. To rename a policy layer: 1.

Right-click the tab of the policy layer and select Rename. The Rename New Layer dialog appears.

2.

Rename the layer and click OK.

144

Chapter 3: The Visual Policy Manager

Section D: Managing Policy Layers, Rules, and Files

Disabling a Policy Layer Disabling policy layers allows you to remove a subset of the employed policy without losing the rules and the effort put forth to create them. Once disabled, the policy in that layers is ignored. You can re-enable a disabled layer at any time. To disable or enable a policy layer: Right-click the tab of the policy layer and select Disable Layer. The layer name text turns red and the layer rules are greyed-out. To re-enable a layer, repeat this step and select Enable Layer.

Deleting a Policy Layer You can completely remove a policy layer.

Important: Once deleted, a layer cannot be recovered. To delete a policy layer: 1.

Right-click the tab of the policy layer to be deleted.

2.

Select Delete Policy from the drop-down list.

Note: All of the above procedures can be accomplished from the Menu Bar>Edit dropdown list.

Managing Policy Rules Occasionally, you might need to temporarily disable rules in a policy layer; for example, when troubleshooting compiles errors and warnings. This might help confirm that the SG appliance can successfully compile the remaining policy. After disabling a rule, you can edit the objects and re-enable the rule. To disable or enable a rule: 1.

Click the appropriate policy layer tab.

2.

Right-click in the No. column.

3.

Click Disable Rule on the shortcut menu. The policy editor changes the rule text color to red.

4.

To enable the rule, repeat step 3. After you enable a disabled rule, the policy editor changes the rule text color to black.

Installing VPM-Created Policy Files Policies created with VPM are saved on the specific SG appliance on which they are created. SGOS automatically creates the following files when saving VPM-created policies: config_policy_source.xml config_policy_source.txt

145

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section D: Managing Policy Layers, Rules, and Files You can install VPM policies that were created on another SG appliance. This requires the following steps: 1.

Copy the two VPM files, to be shared, to a Web server from the SG appliance on which they reside.

2.

Use the Management Console or CLI to load VPM files on another SG appliance.

To copy VPM files from a SG appliance to a Web server: 1.

Select Statistics > Advanced.

2.

Scroll down and click Policy. The page jumps down to the Policy files links.

Figure 3-12. Policy Files in Custom URLs

3.

Right-click the Show VPM CPL policy link.

4.

In the Save As dialog, enter the full path to a directory on the Web server before the file name and click OK. Important: The Save As dialog offers the appropriate default file name (config_policy_source.xml or config_policy_source.txt). You can change the names, including the extension. This can be helpful if an enterprise is using various sets of shared VPM files. You could rename files to indicate the SG appliance on which they were created, for example, or for a department that has a set of VPM-specific policies, used perhaps in multiple locations (sales_vpm.cpl and sales_vpm.xml).

5.

Repeat the previous step for the second VPM file.

To load VPM files to a SG appliance: 1.

Select Configuration > Policy > Policy Files > Visual Policy Files.

146

Chapter 3: The Visual Policy Manager

Section D: Managing Policy Layers, Rules, and Files

2b 2a

2.

In the Install Visual Policy field: a.

Select Remote URL from the Install VPM-CPL from drop-down list.

b.

Click Install. The Install VPM-CPL dialog appears.

c.

In the Installation URL field, enter the URL to the VPM CPL file copied to the Web server (this is the file with the default .txt extension) and click Install.

d. Repeat Steps a through c to enter the URL to the second VPM XML file copied to the Web server (this is the file with the default .xml extension) and click Install. 3.

Click Apply.

Notes ❐

If VPM files already exist on the SG appliance, the URLs to those files display in the two file fields. To replace them, delete the URLs and type new ones. Installing new files overwrites any that are already present.

❐

To review VPM-generated policies before installing them, enter the URL to the CPL file on the Web server and click View.

❐

Regardless of whether you are installing new VPM files, you can review the CPL or XML files of the policies currently on the SG appliance. Click VPM-CPL and VPM-XML in the View Visual Policy Files box at the bottom of the dialog.

❐

Never edit either of the VPM files directly. Change the files only by working with the policies in VPM and saving changes there.

To load VPM files to a SG appliance: The two commands in the first step load one of the VPM policy files; the commands in the second step load the other policy file. In each case, url is the complete path, including file name, to the appropriate file on the Web server.

147

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section D: Managing Policy Layers, Rules, and Files 1.

At the config command prompt, enter the following commands: SGOS#(config) policy vpm-cpl-path url SGOS#(config) load policy vpm-cpl

2.

At the config command prompt, enter the following commands: SGOS#(config) policy vpm-xml-path url SGOS#(config) load policy vpm-xml

Viewing the Policy/Created CPL View the CPL generated by installing VPM-created policy from VPM or the Management Console. To view the generated CPL through the VPM: Select View > Generated CPL. To view the VPM policy file: Select View > Current SG Appliance VPM Policy Files.

Important: Do not edit or alter VPM-generated files by opening the VPM policy file and working in the generated CPL. To edit, change, or add to VPM policies, edit the policy layers and re-install the policy.

148

Chapter 3: The Visual Policy Manager

Section E: Tutorials

Section E: Tutorials This section contains the following topics: ❐

“ Tutorial—Creating a Web Authentication Policy”

❐

“ Tutorial—Creating a Web Access Policy”

Tutorial—Creating a Web Authentication Policy This section is a tutorial that demonstrates how to create policies and rules for Web authentication. Use Web Authentication policies to specify whether the individual making a request is prompted to authenticate by entering a username and password. In this example, a company uses a PAC file to configure most employee browsers to connect to a specific IP address on the SG appliance. It wants these users to authenticate when their browsers send a request to the proxy. To create a policy layer: 1.

Start the VPM from the Management Console: Configuration > Policy > Visual Policy Manager.

2.

Select Policy > Add Web Authentication Layer.

3.

A dialog displays offering a default name for the layer, consisting of the layer type and a number. Rename the layer or accept the default and click OK. The VPM creates the new layer tab and adds a blank rule.

Example 1: Create an Authentication Rule By default, the unmodified rule applies to everyone whose browsers connect to a specific IP address.

149

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

1

2

3

1.

Right-click the Source cell to drop the menu; select Set to open the Set Source Object dialog.

2.

Select a proxy IP address or port; if necessary, click New to create a new one. This example selects the IP address on the SG appliance where the PAC file sends most employee browsers.

3.

Click OK to enter the IP address in the Source cell.

150

Chapter 3: The Visual Policy Manager

Section E: Tutorials

4

5

4.

Create an authentication Action object. Right-click the Action cell to drop the menu and select Set; the Set Action Object dialog displays.

5.

The only objects available are the pre-existing static objects, so you must create a new Authenticate object. Click New and select Authenticate. The Add Authenticate Object window displays.

6.

For this example, the following fields are:

151

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials •

Name—Every configurable object has a name. The default name Authenticate1; change to Authenticate_Example_Corp, which is how it is listed in the Add Object window.

•

Realm—Specifies an LDAP realm.

•

Mode—Specifies the authentication realm mode is Origin IP.

7.

Click OK to close the Add Action Object window, with the new Authenticate object in the list.

8.

Click OK.

Figure 3-13. Completed Action Object

9.

Create a Trace object to log all authentication activity. Right-click the Track cell to drop the menu and select Set; the Set Track Object dialog appears.

10. You must create a new Trace object. Click New and select Trace; the Add Trace Object appears.

152

Chapter 3: The Visual Policy Manager

Section E: Tutorials

11

12

11. In the Name field, enter AuthTrace. 12. Click Trace Level and Verbose to enable verbose tracing, which lists the rules that were skipped because one or more of their conditions were false and displays the specific condition in the rule that was false. 13. Click OK. 14. Click OK again to add the object. The rule is complete.

Figure 3-14. Completed Rule

Example 2: Exempt Specific Users from Authentication Certain individuals and groups are exempt from the above restriction. Individuals in the purchasing department are required to access the Web often so they can order online from supplier Web sites, and the company does not want them to authenticate.

1.

Click Add Rule to add a new rule to this policy layer.

153

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

2.

People in the purchasing group use the same PAC file and thus their browsers are directed to the same IP address: 10.1.1.1.

3.

Change the Action object to Do Not Authenticate and click OK.

154

Chapter 3: The Visual Policy Manager

Section E: Tutorials The new rule in the policy layer accepts the default Action Object to not authenticate and does not require a Trace Object.

Figure 3-15. Updated second rule.

However, a problem exists. The second rule cannot be evaluated because the first rule affects everyone who goes through the proxy. The rules need to be reversed.

4.

Select the second rule and click Move Up to reorder the rules.

5.

Click Install Policy.

Tutorial—Creating a Web Access Policy This section is a tutorial that demonstrates how to create policies and rules for Web access. Use SG appliance policies to define end-user access to Web resources. For more information about Web access policies, refer to Volume 7: Managing Content. This section provides examples.

Example 1: Restrict Access to Specific Websites This example demonstrates a simple rule that denies everyone access to specific job searching Web sites. This rule requires you to configure only one rule option; it uses the defaults for all other options. 1.

Start the policy editor and select Policy > Add Web Access Layer. The VPM displays a tab with the name of the new policy; beneath that is a new rule-specific row.

155

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

The default is Deny.

2.

Right-click Destination and select Set; the Set Destination Object dialog appears.

3.

Click New; select Combined Destination Object. The Add Combined Destination Object dialog appears.

156

Chapter 3: The Visual Policy Manager

Section E: Tutorials

4.

Select New > Request URL.

157

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

5

6

8

5.

Click Simple Match; in the URL field, enter hotjobs.com.

6.

Click Add.

7.

Repeat Step 5, adding monster.com and bajobs.com.

8.

Click Close.

158

Chapter 3: The Visual Policy Manager

Section E: Tutorials

9

9.

Select each newly added URL and click the first Add button.

10. Click OK. The Set Destination Object now contains the individual URL objects and the combined object. 11. Select the JobSearchURLs combined object and click OK. The object is now part of the rule.

Figure 3-16. Completed Rule

As the default action is deny, the rule is complete. No one can access these Web sites. 12. To activate the rule, click Install Policies.

Example 2: Allow Specific Users to Access Specific Websites The after-hours IT shift is comprised of part-time college interns who are on call to handle small problems, but are not involved in major projects. Therefore, you allow them to browse certain sports and entertainment Web sites when all is quiet; access is allowed from two workstations and you still want to track their browsing activity.

159

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials To configure the Source object:

1

2

3

1.

Add a new rule to the policy and position the pointer in the Source cell.

2.

Right-click the Source cell and select Set to display the Add Source Object dialog.

3.

Click New and select Combined Source Object; the Add Combined Source Object appears.

160

Chapter 3: The Visual Policy Manager

Section E: Tutorials

4

5

4.

Name the object IT_PM_Shift.

5.

Under the selectable list of objects, click New and select Client IP Address/Subnet; the Add Client IP Address/Subnet Object dialog appears.

6.

Enter the IP address of the first workstation and click Add; repeat for the second; click Close.

161

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

7.

Select each IP address and click the first Add.

8.

Click OK; click OK again to add the Source object to the rule.

162

Chapter 3: The Visual Policy Manager

Section E: Tutorials To configure the Destination object:

1

2

1.

Right-click the Destination field and select Set; the Set Destination Object dialog appears.

2.

Click New and select Request URL Category; the Add Request Category Object dialog appears.

163

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

3

4

3.

Select Policy and click Add; the Enter Name for New Category dialog appears.

4.

Name the object Allowable_Sports and click OK.

5

5.

Select Sports URLs. Click Edit URLs. The Edit Locally Defined Category Object dialog appears.

164

Chapter 3: The Visual Policy Manager

Section E: Tutorials

6.

Enter the URLs for the allowable sports Web sites and click OK.

7.

Under Policy, select Allowable_Sports; click OK.

8.

Repeat Steps 3 through 7, creating a category called Allowable_Entertainment with the URLs ew.com, rollingstone.com, and variety.com.

9.

Name the object Allowable PM IT Websites. Click OK twice to add the object to the rule.

Figure 3-17. Completed Second Rule in Layer

To configure the Time object: This example allows the specified users to access the sports and entertainment Web sites after business hours.

165

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials

1

2

1.

In the second rule, right-click the Time field and select Set; the Set Time Object dialog appears.

2.

Click New and select Time Object; the Add Time Object dialog appears.

166

Chapter 3: The Visual Policy Manager

Section E: Tutorials

3

4

5

3.

Name the object After Hours.

4.

In the Specific Time of Day Restriction field, select Enable and set the time from 18:00 to 05:59. This defines after hours as 6:00 PM to 6:00 AM.

5.

In the Specific Weekday Restriction field, select Enable and select Monday, Tuesday, Wednesday, Thursday, and Friday. This defines the days of the week to which this rule applies.

6.

Click OK twice to add the Time Object to the rule.

167

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section E: Tutorials To configure the Action object:

1.

In the second rule, right-click Action and select Allow.

2.

Click Install Policy.

168

Chapter 4: Advanced Policy Tasks

This chapter provides conceptual and procedural information about the SG appliance advanced policy features. While many SG appliance features have a policy component, some features have no configuration component outside policy. Configuring advanced policy is accomplished by defining rules in the Visual Policy Manager (VPM) or by composing Content Policy Language (CPL). While some examples are provided in this chapter, references to the relevant VPM chapter component are included in each section. This chapter contains the following topics: ❐

Section A: "Blocking Pop Up Windows" on page 170

❐

Section B: "Stripping or Replacing Active Content" on page 172

❐

Section C: "Modifying Headers" on page 175

❐

Section D: "Defining Exceptions" on page 176

❐

Section E: "Managing Peer-to-Peer Services" on page 188

❐

Section F: "Managing QoS and Differential Services" on page 194

Excluding exceptions, you must use policy to implement these capabilities. (For exceptions, you can create a list outside of policy to install on the system.)

169

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section A: Blocking Pop Up Windows

Section A: Blocking Pop Up Windows This section describes the Blue Coat solution for blocking unwanted pop up windows.

About Pop Up Blocking The SG appliance allows you to block pop up windows, which are usually in the form of unsolicited advertisements. Pop up windows are blocked by inserting Javascript code into each HTML Web page. Every time the Web page tries to open a new window, the code attempts to determine if the window is a result of user click. The window is allowed to open if the SG appliance determines a user clicked a button or link; otherwise, the window does not open.

Interactivity Notes Because of the dynamic nature of the Web, blocking pop up windows is not a perfect solution. Consider the following caveats before configuring this feature: ❐

Windows that contain desired or useful information cannot be distinguished from undesired content, such as advertisements.

❐

If the Web browser caches a page that spawns pop up windows before the blocking policy was installed, pop up ads continue to be served from that page regardless of current policy.

❐

Animated ads contained within Web pages are not blocked. Commonly seen in scrolling or drop-down form, these are not true pop up windows but are contained within the page. Users who see these ads might believe that pop up window blocking is not implemented.

❐

Pop up windows that are delivered through HTTPS are not blocked.

❐

Although the SG appliance request headers instruct a Web server not to use compression, it is possible (though not likely) for a Web server to be configured to send compressed responses anyway. The pop up blocking feature does not work on compressed HTML pages.

Recommendations ❐

To compensate for limiting factors, administrators and users can override pop up blocking: •

Administrators—Use the VPM to create policy rules that exempt pop up blocking for specific Web sites and IP address ranges. For example, Blue Coat recommends disabling pop up blocking for your Intranet, which commonly resides on a IP address range.

Figure 4-1. Disabling pop up blocking on the corporate site.

170

Chapter 4: Advanced Policy Tasks

Section A: Blocking Pop Up Windows •

Users—When a pop up window is blocked, a message is displayed in the status bar: blocked popup window -- use CTRL Refresh to see all popups.

While pressing the Control key, click the Web browser Refresh button; the page is reloaded with pop up blocking disabled for that action. ❐

Create a separate Web Access policy layer for pop up blocking actions. This alleviates interference with Web applications deployed on your Intranet that require pop up windows.

❐

To prevent a cached Web page from spawning pop up windows, clear the browser cache, then reload the page without holding down the CTRL key.

Blocking pop up windows is accomplished through the Visual Policy Manager. See “Block/Do Not Block PopUp Ads” on page 90 for information about how to create blocking actions in a policy layers.

171

Volume 6: The Visual Policy Manager and Advanced Policy Tasks Section B: Stripping or Replacing Active Content

Section B: Stripping or Replacing Active Content This section describes the Blue Coat solution for stripping or replacing unwanted active content.

About Active Content Scripts activated within Web pages can pose a security concern. The SG appliance policy can be configured to supplement standard virus scanning of Web content by detecting and removing the HTML tags that launch active content such as Java applets or scripts. In addition, the removed content can be replaced with predefined material, a process referred to as active content transformation. When the SG appliance is configured to perform active content transformation, Web pages requested by a client are scanned before they are served and any specified tags and the content they define are either removed or replaced. Because the transformed content is not cached, the transformation process is based on a variety of conditions, including time of day, client identity, or URL. Note: Pages served over an HTTPS tunneled connection are encrypted, so the content cannot be modified.

The following tags and related content can be removed or replaced: ❐

—Java applets, as defined by HTML elements.

❐

—Embedded multimedia objects displayed using Netscape Navigator plugins as defined by HTML elements.

❐

—Embedded multimedia objects displayed using Internet Explorer ActiveX controls and other multimedia elements, as defined by HTML elements

❐

—Embedded Javascript and VBScript programs, whether these are represented as HTML elements, Javascript entities, Javascript URLs, or event handler attributes. The tag is not affected by this features.

Stripping active content is accomplished through the Visual Policy Manager or by composing CPL. ❐

See “Strip Active Content” on page 104 for information about how to create a Strip Active Content action object in a Web Access policy layer.

❐

Refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

About Active Content Types The following sections provide more detail about the types of active content that can be removed or replaced.

Script Tags Scripts are generally placed between the start and end tags and . The type of script used is defined by the LANGUAGE attribute; for example, ). When the LANGUAGE attribute is undefined, the browser assumes JavaScript.

172

Chapter 4: Advanced Policy Tasks

Section B: Stripping or Replacing Active Content When transform active_content is configured to remove scripts, the basic operation is to remove all content between and including and , regardless of the language type, and substitute any defined replacement text. A notable exception occurs when a script is defined in the header portion of the HTML document (defined by the tag). In this case, the script is simply removed. This is because images, objects, and text are not allowed in the header of an HTML document. If the end script tag is missing from the document (the end of the document is defined as either up to the or tag, or the last character of the document), then all content from the start tag to the end of the document is removed.

JavaScript Entities JavaScript entities have the following format: &{javascript code} and are found anywhere in the value part of an attribute (that is, Content Filtering > General.

2.

Select Enable for Blue Coat Web Filter.

3.

Select the Lookup Mode.

4.

a.

The default is Always, which specifies that BCWF will always be consulted for category information.

b.

Uncategorized specifies that the lookup is skipped if the URL has already been found in policy, a Local database, or the Internet Watch Foundation (IWF) database.

(Optional) In the Options section, select Enable Category Review Message in Exceptions. This adds a link to the default content filter exception page that can be used to request review of the categories assigned to a blocked URL. Two substitutions ($(exception_category_review_url) and $(exception_category_review_message)) are automatically appended to the help element of all exception definitions. For information on using the $(exception.help) element, refer to Volume 6: VPM and Advanced Policy.

14

Chapter 2: Filtering Web Content

Section B: Configuring Blue Coat Web Filter

Note: The substitution values are empty if the database was not consulted for

categorization or if the categorization process failed due to an error. 5.

Click Apply to commit the changes to the SG appliance. Note: If this is the first time you enabled BCWF, a small database that contains the

category list is downloaded, allowing immediate policy creation. No username or password is required during the trial period (60 days). To download the database on demand or on a schedule, you must configure BCWF service.

Configuring Blue Coat Web Filter To configure Blue Coat Web filter: 1.

Select Configuration > Content Filtering > Blue Coat.

2.

When you subscribed to BCWF Service, you received a username and password for access to download updates. (If you are in the trial period, no username or password is required.)

3.

a.

In the Username field, enter your username.

b.

Click Change Password. The Change Password dialog displays.

c.

Enter your password and click OK.

Download the database: a.

The default database download location displays in the URL field. Note: Only enter a new URL if instructed. Otherwise, accept the default.

4.

Click Download Now. The Download Status dialog displays, stating that a download has started.

15

Volume 7: Managing Content Section B: Configuring Blue Coat Web Filter

a.

Click Close to close the Download status dialog.

b.

To view the download log, click View Download Status. A new browser window opens, displaying the download log. Download log: Blue Coat download at: 2007/06/07 17:40:42-0400 Downloading from https://list.bluecoat.com/bcwf/activity/download/ bcwf.db Requesting differential update Differential update applied successfully Download size: 84103448 Database date: Wed, 07 Jun 2007 08:11:51 UTC Database expires: Fri, 07 Jul 2007 08:11:51 UTC Database version: 2005040

c. 5.

When you are finished viewing the download log, close the browser window.

Click Apply to commit the changes to the SG appliance.

Specifying a Custom Time Period to Update Blue Coat Web Filter The SG appliance checks for updates to the database several times an hour. When an update is available, it is automatically downloaded and applied. Typically, an update contains only the information that has changed. You can prevent this automatic check entirely by disabling automatic updates. You can also restrict the checks to occur only within a specific time period. For example, you can choose to check for updates only between the hours of 8 am and 11 pm. The time frame is always local time. Note: When the database is downloaded, a log is available that includes detailed

information about how the database was updated. You can view the download log in the Management Console by clicking View Download Status on the BCWF tab, selecting Statistics > Advanced > Content Filter Service, or in the CLI (SGOS#(config) show content-filter status). To specify a custom time period for updates: 1.

Select Configuration > Content Filtering > Blue Coat. The Automatically Check for Updates check box is selected by default.

16

Chapter 2: Filtering Web Content

Section B: Configuring Blue Coat Web Filter

2.

a.

Select the Only between the hours of check box. The time frame is local time.

b.

Click the arrows to view the drop-down lists, and set the time period for your update schedule. For example, to check for updates between the hours of 8 am and midnight, set the first box to 08:00 and the second box to 23:59.

Click Apply to commit the changes to the SG appliance.

Configuring Dynamic Real-Time Rating By default, DRTR is enabled and configured to categorize un-categorized URLs. If this service is causing significant delays to enterprise Web communications, you can run the service in the background or disable the feature.

About Proxy Chaining Support for DRTR The SG appliance allows you to forward BCWF DRTR requests through upstream proxy servers and SOCKS gateways, which eliminates the requirement for the SG appliance to have direct connection to back-end servers.

Forwarding Hosts and Groups You can specify the alias of a forwarding host or group that has already been defined. If you want the DRTR requests to be forwarded through an upstream HTTP proxy, configure a forwarding host that is defined as a proxy and has an HTTP port set. Then select that forwarding host in the DRTR configuration. Important:

Do not define your proxy as a server. An attempt to configure proxy chaining using a server results in an error.

SOCKS Gateways When you use proxy chaining to forward DRTR requests through an upstream SOCKS gateway, you must configure the SOCKS gateway.

17

Volume 7: Managing Content Section B: Configuring Blue Coat Web Filter If both a forwarding host or group alias and a SOCKS gateway are specified in the proxy chain, the SG appliance attempts the connection through the SOCKS gateway to the forwarding target.

Configuring DRTR Complete the following procedures to configure DRTR. Note that Enable Dynamic Categorization (DRTR) is enabled by default. To configure DRTR: 1.

Select Configuration > Content Filtering > Blue Coat > Dynamic Categorization (DRTR).

Categorize dynamically in real-time is enabled by default. If DRTR is disabled, the SG

appliance does not contact the service when no category is found for a URL in the database, and all Dynamic Categorization properties specified in policy are ignored. If DRTR is enabled for BCWF, it is only invoked while BCWF is in use. 2.

Select one of the following settings: a.

Do not categorize dynamically. The loaded database is consulted for category information. URLs not found in the database show up as category none.

Dynamic categorization is still possible, but only occurs when explicitly invoked by policy. b.

Categorize dynamically in the background. In background mode, after a call is

made to the dynamic categorization service, the URL request immediately proceeds without waiting for the external service to respond. The system category pending is assigned to the request, indicating that the policy was evaluated with potentially incomplete category information. The results of DRTR are entered into a categorization cache (as are the results of real-time requests). This cache ensures that any subsequent requests for the same or similar URLs can be categorized quickly, without needing to query the external service again. c.

3.

Categorize dynamically in real-time (default). The advantage of real-time mode categorization is that Blue Coat policy has access to the results, allowing policy decisions to be made immediately upon receiving all available information.

Click Apply to commit the changes to the SG appliance.

18

Chapter 2: Filtering Web Content

Section B: Configuring Blue Coat Web Filter

About DRTR States DRTR has three states: ❐

Enabled: The service attempts to categorize unrated Web sites.

❐

Disabled: If the service is disabled, the SG appliance does not make any contact with the service, regardless of any installed policy.

❐

Suspended: If BCWF license expires and DRTR is enabled, the service enters a suspended state; during this time the SG appliance does not make contact with the service, regardless of any installed policy. After BCWF license is updated, DRTR returns to enabled status.

To view DRTR status (CLI only): At the (config) prompt, enter the following command: SGOS# (config content-filter) view Provider: Blue Coat Dynamic Categorization: Service: Enabled/Disabled/Suspended Content Filtering > General page, click View Categories.

2.

To see what categories a Web site is assigned by your current configuration, enter the URL into the URL field and click Test.

Related CLI Syntax to Manage the BCWF Database ❐

To enter configuration mode: SGOS#(config) content-filter

❐

The following subcommands are available: SGOS#(config content-filter) provider bluecoat {enable | disable} SGOS#(config content-filter) provider bluecoat lookup-mode {always | uncategorized} SGOS#(config content-filter) categories SGOS#(config content-filter) bluecoat SGOS#(config bluecoat) download {all-day | auto | between-hours | encrypted-password | get-now | password | url | username} SGOS#(config bluecoat) service {enable | disable} SGOS#(config bluecoat) service {forward {none | host_or_group_alias} | mode {background | realtime | none} | socks-gateway {none | gateway_alias}} SGOS#(config bluecoat) no download SGOS#(config bluecoat) {exit | view} SGOS#(config content-filter) test-url url

19

Volume 7: Managing Content Section C: Configuring a Local Database

Section C: Configuring a Local Database This section describes how to select and refer to a local database and how to schedule the database update schedule.

Selecting the Local Database and Downloading the Database Two main reasons to use a local database instead of a policy file for defining categories are: ❐

A local database is more efficient than policy if you have a large number of URLs.

❐

A local database separates administration of categories from policy. This separation is useful for three reasons: •

It allows different individuals or groups to be responsible for administrating the local database and policy.

•

It keeps the policy file from getting cluttered.

•

It allows the local database to share categories across multiple boxes that have different policy.

However, some restrictions apply to a local database that do not apply to policy definitions: ❐

No more than 200 separate categories are allowed.

❐

Category names must be 32 characters or less.

❐

A given URL pattern can appear in no more than four category definitions.

You can use any combination of the local database, policy files, or the VPM to manage your category definitions. See “Applying Policy to Categorized URLs” on page 35 for more information. You can also use both a local database and a third-party vendor for your content filtering needs. Note: Blue Coat recommends locating your local database on the same server as any policy files you are using.

To configure local database content filtering: 1.

Select Configuration > Content Filtering > General.

20

Chapter 2: Filtering Web Content

Section C: Configuring a Local Database

2.

Select Local Database.

3.

Select the Lookup Mode. a.

The default is Always, which specifies that the Local database will always be consulted for category information.

b.

Uncategorized specifies that the lookup is skipped if the URL has already been found in policy.

4.

Click Apply to commit the changes to the SG appliance.

5.

Select Configuration > Content Filtering > Local Database.

6.

If the database is located on a server that requires a password for access, you must configure the SG appliance to use that password when accessing the database:

7.

a.

Click Change Password. The Change Password dialog displays.

b.

Enter your password and click OK.

Download the database: a.

In the URL field, enter the location of the file to be downloaded.

b.

Click Download Now. The Download Status dialog displays.

c.

To view a download log, click Close to close the Download Status dialog, and then click View Download Log. Download log: Local database download at: 2007/06/07 17:40:42-0400 Downloading from ftp://1.1.1.1/list-1000000-cat.txt Download size: 16274465 Database date: Wed, 07 Jun 2007 08:11:51 UTC Total URL patterns: 1000000 Total categories: 10

d. Click OK. 8.

Click Apply to commit the changes to the SG appliance.

21

Volume 7: Managing Content Section C: Configuring a Local Database Future Downloads You can return to this screen at any time and download a database on demand (independent of the automatic download feature, which is described in the next section). Ordinarily, the SG appliance checks to see if the database has changed before initiating a download. If the database is the most current, no download is performed. Note: Incremental updates are not available for Local Database.

Specifying a Custom Time Period to Update a Local Database The SG appliance checks for updates to the database several times an hour. When an update is available, it is automatically downloaded and applied. Typically, an update contains only the information that has changed. You can prevent this automatic check entirely by disabling automatic updates. You can also restrict the checks to occur only within a specific time period. For example, you can choose to check for updates between 8 am and 11 pm only. The time frame is always local time. Note: When the database is downloaded, a log is available that includes detailed

information about how the database was updated. You can view the download log in the Management Console by selecting Statistics > Advanced > Content Filter Service, or in the CLI (SGOS#(config) show content-filter status). To specify a custom time period for updates: 1.

Select Configuration > Content Filtering > Local Database. The Automatically check for updates check box is selected by default.

2.

Select the Only between the hours of check box. The time frame is local time.

3.

Click the arrows to view the drop-down lists and set the time period for your update schedule. For example, to check for updates between the hours of 8 am and midnight, set the first box to 08:00 and the second box to 23:59.

4.

Click Apply to commit the changes to the SG appliance.

Diagnostics Allows you to see all categories available for use in policy or test a URL against the database. Categories are not displayed for a vendor or local database if no database has been downloaded. To see all available categories: 1.

On the Configuration > Content Filtering > General page, click View Categories.

2.

To see what categories a Web site is assigned by your current configuration, enter the URL into the URL field and Click Test.

22

Chapter 2: Filtering Web Content

Section C: Configuring a Local Database Related CLI Syntax to Configure Content Filtering ❐

To enter configuration mode: SGOS#(config) content-filter

❐

The following subcommands are available: SGOS#(config content-filter) provider local {enable | disable} SGOS#(config content-filter) provider local lookup-mode {always | uncategorized} SGOS#(config content-filter) categories SGOS#(config content-filter) local SGOS#(config local) download {all-day | auto | between-hours | encrypted-password | get-now | password | url | username} SGOS#(config local) source SGOS#(config local) clear SGOS#(config local) {view | exit} SGOS#(config content-filter) test-url url

23

Volume 7: Managing Content Section D: Configuring Internet Watch Foundation

Section D: Configuring Internet Watch Foundation This section describes how to select the Internet Watch Foundation (IWF) database and how to schedule the database update schedule. The IWF is a non-profit organization that provides to enterprises a list of known child pornography URLs. The IWF database features a single category called IWF-Restricted, which is detectable and blockable using policy. IWF can be enabled along with other content filtering services.

Selecting the IWF Database To configure IWF content filtering: 1.

Select Configuration > Content Filtering > General.

2.

Select Internet Watch Foundation.

3.

Select the Lookup Mode. a.

The default is Always, which specifies that IWF will always be consulted for category information.

b.

Uncategorized specifies that the lookup is skipped if the URL has already been found in policy or a Local database.

4.

Click Apply to submit the changes to the SG appliance.

5.

Select Configuration > Content Filtering > IWF.

24

Chapter 2: Filtering Web Content

Section D: Configuring Internet Watch Foundation

6.

Download the database: a.

The default database download location displays in the URL field. Note: Only enter a new URL if instructed. Otherwise, accept the default.

b.

Click Download Now. The Download Status dialog displays. When the operation is complete, the dialog changes to indicate installation status.

c.

Click Results to see the IWF download log: Download log: IWF download at: 2007/06/07 17:40:42-0400 Downloading from https://list.bluecoat.com/iwf/activity/download/ iwf.db Requesting differential update Differential update applied successfully Download size: 84103448 Database date: Wed, 07 Jun 2007 08:11:51 UTC Database expires: Fri, 07 Jul 2007 08:11:51 UTC Database version: 2005040

d. Click OK. 7.

Click Apply to commit the changes to the SG appliance.

Future Downloads You can return to this screen at any time and download a database on demand (independent of the automatic download feature, which is described in the next section). Ordinarily, the SG appliance checks to see if the database has changed before initiating a download. If the database is the most current, no download is performed. If an incremental update is available on the server, then it is downloaded (an incremental update contains only the changes between the current installed version and the latest published version of the database, and is much smaller than a full copy of the database).

25

Volume 7: Managing Content Section D: Configuring Internet Watch Foundation

Specifying a Custom Time Period to Update IWF The SG appliance checks for updates to the categorization database several times an hour. When an update is available, it is automatically downloaded and applied. Typically, an update contains only the information that has changed. You can prevent this automatic check entirely by disabling automatic updates. You can also restrict the checks to occur only within a specific time period. For example, you can choose to check for updates between 8 am and 11 pm only. The time frame is always local time. Note: When the database is downloaded, a log is available that includes detailed

information about how the database was updated. You can view the download log in the Management Console by selecting Statistics > Advanced > Content Filter Service, or in the CLI (SGOS#(config) show content-filter status). To specify a custom time frame for updates: 1.

Select Configuration > Content Filtering > IWF. The Automatically check for updates check box is selected by default.

2.

Select the Only between the hours of check box. The time frame is always local time.

3.

Click the arrows to view the drop-down lists and set the time period for your update schedule. For example, to check for updates between the hours of 8 am and midnight, set the first box to 08:00 and the second box to 23:59.

4.

Click Apply to commit the changes to the SG appliance.

Diagnostics This allows you to test a URL against the database. To test a URL: 1.

Select Configuration > Content Filtering > General.

2.

Enter the URL into the URL field.

3.

Click Test.

Related CLI Syntax to Manage IWF ❐

To enter configuration mode: SGOS#(config) content-filter

❐

The following subcommands are available: SGOS#(config content-filter) provider iwf {enable | disable} SGOS#(config content-filter) provider iwf lookup-mode {always | uncategorized} SGOS#(config content-filter) iwf

26

Chapter 2: Filtering Web Content

Section D: Configuring Internet Watch Foundation SGOS#(config iwf) download {all-day | auto | between-hours | encrypted-password | get-now | password | url | username} SGOS#(config iwf) no download SGOS#(config iwf) {exit | view} SGOS#(config content-filter) test-url url

27

Volume 7: Managing Content Section E: Configuring a Third-Party Vendor

Section E: Configuring a Third-Party Vendor This section describes how to select and configure your preferred third-party vendor and how to schedule the database update schedule. Most of the third-party vendor configuration tasks are identical, but there are a few with vendor-specific options. As you follow the procedures, you are prompted to proceed to another section for these vendors to continue the configuration.

Selecting the Provider and Downloading the Database This procedure assumes you have a valid account with your preferred vendor. To configure third-party content filtering: 1.

Select Configuration > Content Filtering > General.

2.

From the 3rd-party database drop-down list, select your preferred vendor.

3.

Select the Lookup Mode.

4.

a.

The default is Always, which specifies that the third-party database will always be consulted for category information.

b.

Uncategorized specifies that the lookup is skipped if the URL has already been found in policy, a Local database, the Internet Watch Foundation (IWF) database, or BCWF.

(Optional and applicable for SmartFilter and BCWF only) Select Enable Category Review Message in Exceptions. This adds a link to the default content filter exception page that can be used to request review of the categories assigned to a blocked URL. Two substitutions ($(exception_category_review_url) and $(exception_category_review_message)) are automatically appended to the help element of all exception definitions. For information on using the $(exception.help) element, refer to Volume 6: VPM and Advanced Policy.

28

Chapter 2: Filtering Web Content

Section E: Configuring a Third-Party Vendor

Note: The substitution values are empty if the provider was not consulted for

categorization, or if the categorization process failed due to an error. 5.

Click Apply to commit the changes to the SG appliance.

6.

Proceed accordingly: •

SmartFilter: Continue with: “Configuring SmartFilter” on page 30.

•

Websense: Continue with: “Configuring Websense (on-box)” on page 31.

•

i-Filter, InterSafe, Optenet, Proventia, SurfControl, or Webwasher: Continue with Step 7.

7.

Select Configuration > Content Filtering > vendor:

8.

(This example uses Surf Control.) If the database is located on a server that requires a password for access, you must configure the SG appliance to use that password when accessing the database:

9.

a.

Enter your third-party vendor username.

b.

Click Change Password. The Change Password dialog displays.

c.

Enter your password and click OK.

Download the database: a.

The default database download location is displayed in the URL field. If you have been instructed to use a different URL, enter it here (optional: click Set to default to always use this location).

b.

Click Download Now. The Installation Status dialog box displays. When the operation is complete, the dialog changes to indicate installation status.

c.

Click Results to see the completion message:

29

Volume 7: Managing Content Section E: Configuring a Third-Party Vendor Download log: SurfControl download at: 2007/06/07 17:40:42-0400 Downloading from https://list.bluecoat.com/.../download/ surfcontrol.db Warning: Unable to determine current database version; requesting full update Download size: 8106572 Database date: Wed, 07 Jun 2007 08:11:51 UTC Database expires: Fri, 07 Jul 2007 08:11:51 UTC Database version: 3

d. Click OK. 10. Click Apply to commit the changes to the SG appliance. 11. Continue with “Specifying a Custom Time Period to Update a Third-Party Database” on page 33. Future Downloads You can return to this screen at any time and download a database on demand (independent of the automatic download feature, which is described in the next section). Ordinarily, the SG appliance checks to see if the database has changed before initiating a download. If the database is the most current, no download is performed. If an incremental update is available on the server, then it is downloaded (an incremental update contains only the changes between the current installed version and the latest published version of the database, and is much smaller than a full copy of the database).

Configuring SmartFilter The SmartFilter database configuration screen contains unique options. Configure SmartFilter: 1.

Select Configuration > Content Filtering > SmartFilter:

2.

Configure SmartFilter: a.

In the License key field, enter the customer serial number assigned you by Secure Computing.

b.

In the Server field, the default server is displayed. If you have been instructed to use a different server, enter the hostname or IP address here.

c.

Click Download now. The SmartFilter Installation status dialog box displays with the message SmartFilter download in progress.

30

Chapter 2: Filtering Web Content

Section E: Configuring a Third-Party Vendor When the operation is complete, the dialog changes to indicate installation status. d. Click Results to see the completion message: Download log: SmartFilter download at: 2007/06/07 17:40:42-0400 Checking incremental update Warning: Unable to open input control list Warning: Unable to open installed control list Downloading full control file SmartFilter download at: 19 June 2007 17:40:42-0400 Downloading from http://example.com/...version=4.0 Download size: 45854194 Database version: 95 Database date: Wed, 07 Jun 2007 08:11:51 UTC Database expires: Fri, 07 Jul 2007 08:11:51 UTC

Note: The first time you download a SmartFilter database, warnings appear in the results message under Checking incremental update. These are expected, and represent the normal process of checking to see if an incremental update is possible. The next time you download a SmartFilter database, the SG appliance checks the previously downloaded database, and downloads only what is necessary to keep the database current.

3.

Click Apply to commit the changes to the SG appliance.

4.

Continue with “Specifying a Custom Time Period to Update a Third-Party Database” on page 33.

Configuring Websense (on-box) The Websense database configuration screen contains unique options. Note: Websense databases contain a category called User-Defined to support locallyspecified categorizations on other platforms. Do not use this category on the SG appliance. Instead, define your own categories through the SG appliance and assign URLs to them using Policy (see page “Defining Custom Categories in Policy” on page 38), or using a local category database (refer to Volume 4: Securing the Blue Coat SG Appliance).

To configure Websense (on-box): 1.

Select Configuration > Content Filtering > Websense.

31

Volume 7: Managing Content Section E: Configuring a Third-Party Vendor

2.

In the License Key field, enter the key assigned to you for downloading the Websense database.

3.

In the Server field, the default server is displayed. If you have been instructed to use a different server, enter the hostname or IP address here.

4.

(Optional) In the Contact e-mail field, enter an e-mail address by which Websense can contact you.

5.

Click Download now. The Websense Installation status dialog box displays with the message Websense download in progress.

6.

Click Apply to view the Websense download log: Download log: Websense download at: 2007/06/21 17:40:42-0400 No database is currently installed Attempting full download Downloading from download.websense.com Processing download file Retrieved full update Download size: 147079939 Database version: 82300 Database date: 2007/06/21 License expires: 2007/07/21 08:11:51 UTC License max users: Licenses in use: Library version:

25 0 3.2.0.0 [BCSI rev A]

7.

Click OK.

8.

(Optional) Always apply regular expressions to urls:

32

Chapter 2: Filtering Web Content

Section E: Configuring a Third-Party Vendor Select this option to force an additional regular expression lookup for each URL to be categorized. Normally, regular expression lookups are done only when no category is found in the Websense database. If this option is selected, regular expression lookups always occur, even for categorized URLs. Selecting this option can cause a significant reduction in lookup performance, but allow certain sites (such as translation, search engine, and link-cache sites) to be categorized more accurately. 9.

To use the Websense Reporter, you must enable the Websense Integration Service. a.

In the Integration Service Host field, enter the Integration Service Host IP (which has the same IP address as the Websense Log Server).

b.

In the Port field, specify the port of the Websense Integration Service. It must be between 0 and 65535 and match the port selected on the Integration Service host.

c.

Select Enabled to enable the service.

d. (Optional) Select Log forwarded client address. Normally, the SG logs the actual client IP address to the Websense Reporter log. You can configure the SG to log an address obtained from the X-Forwarded-For HTTP Header (if present and valid) instead. This is useful in some specific network topologies. Note: The Policy Server, the Log Server, and Reporter must be installed and enabled on your PC before Reporter can be used. For information on Websense products, refer to: http://www.websense.com/support/documentation/ integrationservice.

You must also set up access logging on the SG appliance with Websense as the client. For more information on configuring a Websense access logging client, refer to Volume 8: Access Logging. 10. Click Apply to commit the changes to the SG appliance. 11. Proceed to the “Specifying a Custom Time Period to Update a Third-Party Database” on page 33.

Specifying a Custom Time Period to Update a Third-Party Database The SG appliance checks for updates to the database several times an hour. When an update is available, it is automatically downloaded and applied. Typically, an update contains only the information that has changed. You can prevent this automatic check entirely by disabling automatic updates. You can also restrict the checks to occur only within a specific time period. For example, you can choose to check for updates between 8 am and 11 pm only. The time frame is always local time. Note: When the database is downloaded, a log is available that includes detailed

information about how the database was updated. You can view the download log in the Management Console by selecting Statistics > Advanced > Content Filter Service, or in the CLI (SGOS#(config) show content-filter status). To specify a custom time period for updates: 1.

Select Configuration > Content Filtering > vendor. The Automatically check for updates check box is selected by default.

33

Volume 7: Managing Content Section E: Configuring a Third-Party Vendor

2.

Select the Only between the hours of check box. The time frame is always local time.

3.

Click the arrows to view the drop-down lists and set the time period for your update schedule. For example, to check for updates between the hours of 8 am and midnight, set the first box to 08:00 and the second box to 23:59.

4.

Click Apply to commit the changes to the SG appliance.

Diagnostics This allows you to see all categories available for use in policy or test a URL against the database. Categories are not displayed for a vendor or local database if no database has been downloaded. To see all available categories or test a URL: 1.

On the Configuration > Content Filtering > General page, click View Categories.

2.

To see what categories a Web site is assigned by your current configuration, enter the URL into the URL field.

3.

Click Test.

Related CLI Syntax to Manage Third-Party Vendor Content Filtering ❐

To enter configuration mode: SGOS#(config) content-filter

❐

The following subcommands are available: SGOS#(config content-filter) {i-filter | intersafe | optenet | proventia | smartfilter | surfcontrol | websense | webwasher} SGOS#(config content-filter) provider 3rd-party lookup-mode {always | uncategorized} SGOS#(config content-filter) provider 3rd-party vendor SGOS#(config vendor) download {all-day | auto | between-hours | encrypted-password | get-now | password | url | username} SGOS#(config vendor) view SGOS#(config smartfilter) download license license_key SGOS#(config smartfilter) download server ip_address_or_hostname SGOS#(config smartfilter) allow-rdns | no allow-rdns SGOS#(config smartfilter) use-search-keywords SGOS#(config websense) download email-contact e-mail_address SGOS#(config websense) download server ip_address_or_hostname SGOS#(config websense) download license license_key SGOS#(config websense) {always-apply-regexes | no always-applyregexes} SGOS#(config websense) integration-service {enable | disable} SGOS#(config websense) integration-service host ip_address_or_hostname SGOS#(config websense) integration-service port {0-65535}

34

Chapter 2: Filtering Web Content

Section F: Applying Policy

Section F: Applying Policy This section discusses the interaction between content filtering categories and the application of control policies.

Applying Policy to Categorized URLs Policy is applied to categories the same way as individual URLs: create policies that restrict, allow, and track access. Policy rules are created by composing Blue Coat Content Policy Language (CPL) or with the Visual Policy Manager (VPM). Note: If you have extensive category definitions, Blue Coat recommends that you put them into a local database rather than into a policy file. The local database stores custom categories in a more scalable and efficient manner, and separates the administration of categories from policy. See "Section C: Configuring a Local Database" on page 20.

The policy trigger category= is used to test the category or categories assigned to the request URL, and thus make a policy decision. For example, to block all requests for URLs that are categorized as Sports: DENY category=Sports

The following example demonstrates a condition that is true when a request contains the Websense content categories Sexuality and Drugs: category=(sexuality, drugs)

You can block multiple categories with a single rule: category=(Sports, Gambling, Shopping) exception(content_filter_denied)

In this example, three categories are blocked and instead the predefined exception page content_filter_denied is served; by default this indicates that the request was denied due to its content and specifies the categories found. The following example shows a condition that includes an extensive number of categories: category=(Abortion, Activist, Adult, Gambling, Illegal, Hacking, Militancy, Racism, Shopping, Tasteless, Violence, Weapons)

URLs that are not categorized are assigned the system category none. This is not an error condition; many sites (such as those inside a corporate intranet) are unlikely to be categorized by a commercial service. Use category=none to detect uncategorized sites and apply relevant policy. The following example disallows access to uncategorized sites outside of the corporate network: define subnet intranet 10.0.0.0/8 ; internal network 192.168.123.45; external gateway end ; allow unrestricted access to internal addresses ALLOW url.address=intranet ; otherwise (internet), restrict Sports, Shopping and uncategorized sites DENY category=(Sports, Shopping, none)

35

Volume 7: Managing Content Section F: Applying Policy Such category tests can also be combined with other types of triggers to produce more complex policy, such as: ❐

Restrict access by category and time: block sports from 6 am to 6 pm: category=Sports time=0600..1800 DENY

❐

Restrict by category and user identity: only members of the group Sales are permitted to visit Shopping sites: category=Shopping group=!Sales DENY

❐

Require special authentication for access to certain categories: category=Hacking authenticate(restricted_realm)

where restricted_realm is an authentication realm you have configured. ❐

Log certain types of access: category=Adult action.Log_adult_site_access(yes)

where Log_adult_site_access is a policy action defined elsewhere that records extra information about this request in the event log. Typically, category= can be used in policy anywhere that a basic URL test can be used. Refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide for more details. Depending on which provider you have selected and whether you have defined any of your own categories in policy (see “Defining Custom Categories in Policy” on page 38), you have a number of possible category names that can be used with category=. To review the valid category names, use the categories CLI command or click View Categories in the Management Console: Configuration > Content Filtering > General. The category= expressions are normally put in Layers (VPM: Web Access Layers) because the goal of content filtering policy is to control requests from users. They can also be used in (VPM: Web Content Layers) Layers. Either way, policy is enforced on all user requests. It is possible for an attempt to categorize a URL to fail—for example, if no database is loaded, your license is expired, or if a system error occurs. In such a case, the category is considered unavailable and triggers such as: category=Sports

are false, even if the URL is actually a sports site, because the SG appliance is unable to determine the category. When the policy depends on the category of a URL, you do not want such errors to inadvertently allow ordinarily restricted content to be served by the SG appliance. You can control how the SG appliance treats these situations with the condition: category=unavailable

which is true in these cases. In continuing with the example, to make sure that Sports is always blocked, even when errors occur (this is a mode of operation called fail-closed), use a rule such as: category=(sports, unavailable) exception(name_of_exception page)

This rule is true if the category is sports or if the category could not be determined, and in either case the proper exception page is served instead of the restricted content. The category unlicensed is assigned in addition to unavailable when the failure to categorize occurred because of license expiry. That can be caused by the expiration of your Blue Coat license to use content filtering, or because of expiration of your license from the provider. You can use

36

Chapter 2: Filtering Web Content

Section F: Applying Policy category=unlicensed

to detect this situation as a distinct case from other causes of unavailability. You can also use this feature with custom exception pages (refer to Volume 6: VPM and Advanced Policy): category=sports time=0800..1800 exception(sports_during_bus_hrs) category=unlicensed exception(contact_admin_re_license) category=unavailable exception(content_filter_unavailable)

where sports_during_bus_hrs is a custom exception page you have created to respond to requests for Sports pages between 8 am and 6 pm local time. contact_admin_re_license is another page that instructs the user to inform the

administrator about license expiry, and is served if a license check fails. When the category is unavailable for some other reason, the pre-defined exception (content_filter_unavailable) is served. The most common reason (other than license expiry) why categories are unavailable is that a provider is selected but no database is installed. Barring hardware or network problems that might cause a downloaded database to become corrupted and unreadable, it is unlikely that the database will suddenly become unavailable. To define policies on the SG appliance, use either the VPM or manually edit Policy files. Content filtering policies are usually found in and layers. If you are using content filtering to manage a type of content globally, create these rules in the layer. However, if your content filtering policy is dependent on user identity or request characteristics, create these rules in the layer.

Using Content Filtering Vendors with Blue Coat Policies The SG appliance provides the ability to define flexible Web access and control policies. With content filtering, you can set up policies to provide a customized level of Web-site access control. With vendor-based content filtering, these policies use and can supplement vendor categories. By supplementing content filtering vendor categories, you can further refine the type of content filtering the SG appliance performs. For example, if Travel is a vendor-defined content category, you can define a policy that allows only Human Resources staff to access travel sites. You can define policies that filter by a variety of conditions, including category, protocol (including MMS and RTSP streaming protocols), time of day, and user or user groups.

37

Volume 7: Managing Content Section F: Applying Policy Example Policy: Limit employee access to travel Web sites. The first step is to rephrase this policy as a set of rules. In this example, the model of a general rule and exceptions to that rule is used: ❐

Rule 1: All users are denied access to travel sites

❐

Rule 2: As an exception to the above, Human Resources users are allowed to visit Travel sites

Before you can write the policy, you must be able to identify users in the Human Resources group. You can do this with an external authentication server, or define the group locally on the SG appliance. For information on identifying and authenticating users, refer to Volume 4: Securing the Blue Coat SG Appliance. In this example, a group called human_resources is identified and authenticated through an external server called my_auth_server. This then translates into a fairly straightforward policy written in the local policy file: ; Ensure all access is authenticated Authenticate(my_auth_server) ; Rule 1: All users denied access to travel DENY category=travel ; Rule 2: Exception for HR ALLOW category=travel group=human_resources DENY category=sites

Example Policy: Student access to Health sites is limited to a specified time of day, when the Health 100 class is held. This time the policy contains no exceptions: ❐

Rule 1: Health sites can be accessed Monday, Wednesday, and Friday from 10-11am.

❐

Rule 2: Health sites can not be accessed at other times. define condition Health_class time weekday=(1, 3, 5) time=1000..1100 end ; 1) Allow access to health while class in session ALLOW category=health condition=health_class_time ; 2) at all other times, deny access to health DENY category=health

Defining Custom Categories in Policy You can use CPL to create your own categories and assign URLs to them. This is done with the define category construct (for more complete information on the define category construct, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide). To add URLs to a category, list them in the definition. You only need to specify a partial URL: ❐

hosts and subdomains within the domain you specify will automatically be included

38

Chapter 2: Filtering Web Content

Section F: Applying Policy ❐

if you specify a path, all paths with that prefix are included (if you specify no path, the whole site is included)

Example: define category Grand_Canyon kaibab.org www2.nature.nps.gov/air/webcams/parks/grcacam nps.gov/grca grandcanyon.org end

Any URL at kaibab.org is now put into the Grand_Canyon category (in addition to any category it might be assigned by a provider). Only those pages in the /grca directory of nps.gov are put in this category. Nested Definitions and Subcategories You can define subcategories and nest category definitions by adding a category= rule. To continue the example, you could add: define category Yellowstone yellowstone-natl-park.com nps.gov/yell/ end define category National_Parks category=Grand_Canyon; Grand_Canyon is a subcategory of National_Parks category=Yellowstone; Yellowstone is a subcategory of National_Parks nps.gov/yose; Yosemite – doesn’t have its own category (yet) end

With these definitions, pages at kaibab.org are assigned two categories: Grand_Canyon and National_Parks. You can add URLs to the Grand_Canyon category and they are automatically added by implication to the National_Parks category as well. Multiple unrelated categories can also be assigned by CPL. For example, by adding: define category Webcams www2.nature.nps.gov/air/webcams/parks/grcacam end

the URL, http://www2.nature.nps.gov/air/webcams/parks/grcacam/grcacam.htm, will have three categories assigned to it: ❐

Grand_Canyon (because it appears in the definition directly)

❐

National_Parks (because Grand_Canyon is included as a subcategory)

❐

Webcams (because it also appears in this definition)

However, the other sites in the Grand_Canyon category are not categorized as Webcams. This can be seen by testing the URL (or any other you want to try) clicking the Test button on the Management Console or the test-url command in the CLI. You can test for any of these categories independently. For example, the following example is a policy that depends on the above definitions, and assumes that your provider has a category called Travel into which most national park sites probably fall. The policy is intended to prevent access to travel sites during the day, with the exception of those designated National_Parks sites. But the Grand_Canyon webcam is an exception to that exception.

39

Volume 7: Managing Content Section F: Applying Policy Example: category=Webcams DENY category=National_Parks ALLOW category=Travel time =0800..1800 DENY

Click the Test button on the Management Console or the test-url command in CLI to validate the categories assigned to any URL. This can help you to ensure that your policy rules have the expected effect (refer to “Configuring Policy Tracing” in Volume 10: Blue Coat SG Appliance Content Policy Language Guide). If you are using policy-defined categories and a content-filter provider at the same time, be sure that your custom category names do not coincide with the ones supplied by your provider. You can also use the same names—this adds your URLs to the existing categories, and extends those categories with your own definitions. For example, if the webcam mentioned above was not actually categorized as Travel by your provider, you could do the following to add it to the Travel category (for the purpose of policy): define category Travel ; extending a vendor category www2.nature.nps.gov/air/webcams/parks/grcacam/ ; add the GC webcam end Note: The policy definitions described in this section can also be used as definitions in a local database. See “Configuring a Local Database” on page 20 for information about local databases.

Notes ❐

When you use an expired database, the category unlicensed is assigned to all URLs and no lookups occur on the database. This can occur even if your download license with the database vendor is still valid, but you have not downloaded a database for a long time (databases expire after a certain number of days). You can view the date that your database expires (or expired) in the download log or by using the view command in the CLI. When you download a database, you can see the download log as soon as the download is complete. To see the download log when you download a database, click Results in the Installation Status dialog when the download is complete. To see the last download log without doing another download, enter the following CLI (config) commands: SGOS#(config) content-filter SGOS#(config content-filter) view

❐

When your license with the database vendor expires, you can no longer download. This does not have an immediate effect—you can still use the database you have for a period of time. But eventually, the database expires and you receive the category unlicensed, as described above.

❐

If HTTPS Intercept is disabled and a requested HTTPS host is categorized in a content filtering database, then filtering applies. However, if the request contains a path and the categorization relies on the host/relative path, content filtering only filters on the host name because the path is not accessible. This might result in a different categorization than if the host plus path were used.

40

Chapter 2: Filtering Web Content

Section F: Applying Policy ❐

If you receive an error message when downloading a content filtering database, check the error message (in the Management Console, click Results on the Installation status dialog; in the CLI, the results message displays in the event of an error). If you see an error message such as ERROR: HTTP 401 - Unauthorized, verify that you entered your username and password correctly. For example, the following error message was generated by entering an incorrect username and attempting to download a SmartFilter database: Download log: SmartFilter download at: Thu, 21 June 2007 18:03:08 Checking incremental update Checking download parameters Fetching:http://example.com/ Warning: HTTP 401 - Unauthorized Downloading full control file SmartFilter download at: Thu, 21 June 2007 18:03:17 Downloading from http://example.com/ Fetching:http://example.com/ ERROR: HTTP 401 - Unauthorized Download failed Download failed Previous download: ...

41

Volume 7: Managing Content Section G: Configuring Websense Off-box Content Filtering

Section G: Configuring Websense Off-box Content Filtering This section describes how to configure the SG appliance to communicate with a separate Websense server to perform content filtering tasks. This involves creating an external service on the SG appliance. Note: The SG appliance supports Websense off-box server versions 4.4 and higher.

To configure Websense Off-box: 1.

In the Management Console, select Configuration > External Services > Websense.

2b

2a

2.

Add a new service: a.

Click New. The Add list item dialog displays.

b.

Enter a name for the service. This example uses WS_1.

c.

Click OK to close the dialog and add the Websense service

3.

Click Apply to commit the changes to the SG appliance.

4.

Click Edit. The Edit Websense Service dialog displays.

42

Chapter 2: Filtering Web Content

Section G: Configuring Websense Off-box Content Filtering

5.

Configure the service: a.

From the Websense Version drop-down list, select the version. The default is 4.4 and higher; you can also select 4.3.

b.

In the Host field, enter the hostname or IP address of the remote Websense server.

c.

In the Port field, enter the port number of the Websense server; or leave as is to accept the default (15868).

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 (seconds) field, enter the number of seconds the SG Appliance waits for replies from the Websense server. The range is 60 to 65535. The default timeout is 70 seconds.

The following settings are optional: 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

43

Volume 7: Managing Content Section G: Configuring Websense Off-box Content Filtering exception page originates from the SG Appliance; if not selected, the Websense server provides the exception page. 7.

Click OK to close the Websense dialog. To perform a health check on this service, see “Performing a Health Check on a Websense Off-box Service” on page 44.

8.

Click Apply to commit the changes to the SG appliance.

9.

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

Because this is an external service feature, you can create service groups that contain two or more Websense services. Then you can point the ProxySG to the service group to allow for greater efficiency. See Chapter 4: "Configuring Service Groups" on page 77.

Performing a Health Check on a Websense Off-box Service 1.

To perform a health check on the Websense service, click Health Check. The Confirm Health Check dialog displays.

2.

Make sure that you save changes to any open dialogs before proceeding.

3.

Click OK to perform the health check. When the health check is complete, the Health Check Results dialog displays information about the health check.

4.

Click Close to close the Health Check Results dialog.

Related CLI Syntax to Configure Websense Off-box Content Filtering ❐

To enter configuration mode: SGOS#(config) external-services

❐

The following subcommands are available: SGOS# (config external-services) create websense service_name SGOS# (config external-services) {edit | delete} service_name SGOS# (config websense service_name) version {4.3 | 4.4} SGOS# (config websense service_name) host {hostname | IP_address} SGOS# (config websense service_name) port port_number SGOS# (config websense service_name) max-conn number SGOS# (config websense service_name) timeout timeout_seconds

44

Chapter 2: Filtering Web Content

Section G: Configuring Websense Off-box Content Filtering SGOS# (config websense service_name) send {client-address | authenticated-user} SGOS# (config websense service_name) sense-categories SGOS# (config websense service_name) apply-by-default SGOS# (config websense service_name) fail-open SGOS# (config websense service_name) test-url url

45

Volume 7: Managing Content

46

Chapter 3: Malicious Content Scanning Services

This chapter describes how to configure the SG appliance to interact with external Internet Content Adaptation Protocol (ICAP) clients and servers to provide content scanning and transformation. This chapter contains the following sections: ❐

"Section A: About Content Scanning"

❐

"Section B: Configuring SG Appliance ICAP Communications"

❐

"Section C: Creating ICAP Policy"

❐

"Section D: Managing Virus Scanning"

47

Volume 7: Managing Content Section A: About Content Scanning

Section A: About Content Scanning This section provides conceptual information about anti-virus (AV) scanning and the SG appliance solution. When integrated with a supported ICAP server, such as the Blue Coat AV™, the SG appliance provides content scanning, filtering, and repair service for Internet-based malicious code. To eliminate threats to the network and to maintain caching performance, the SG appliance sends objects to the 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 rescanning the same object for each request.

Determining Which Files to Scan In determining which files to scan, this integrated solution uses the content scanning server’s filtering in addition to SG appliance capabilities. The following table describes the supported content types and protocols. Table 3-1. Content Types Scanned By ICAP Server and the SG Appliance ICAP Server supported content types

SG appliance supported protocols

Unsupported content protocols

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

• HTTP objects

• Streaming content (for example, RTSP and MMS)

Examples: .exe (executable programs), .bat (batch files), .doc and .rtf (document files), and .zip (archive files); or specific MIME types.

• FTP objects (uploads and downloads)

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

• Transparent FTP responses HTTPS connections terminated at an SG appliance

HTTPS connections tunneled through an SG appliance

Whenever an object is requested or being refreshed and it was previously scanned, the SG appliance verifies whether the pattern file has been updated since it was last scanned. If it was, the object is scanned again, even if the content has not changed. If the content has changed, the object is rescanned. With the SG appliance, you can define flexible, yet enterprise-specific content scanning policies, which is discussed in the following two sections.

About Response Modification The SG appliance 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 SG appliance 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:

48

Chapter 3: Malicious Content Scanning Services

Section A: About Content Scanning ❐

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

The following diagram illustrates the response modification process flow.

Figure 3-1. Response Modification Process Flow

About Request Modification Request modification means the ICAP server scans contents that a client is attempting to send outside the network. This prevents unaware users from forwarding corrupted files or Webmail attachments. Request modification is also a method of content filtering and request transformation, which is used to protect network identification. Based on the results of the scan, the server might return an HTTP response to the client (for example, sports not allowed); or the client request might be modified, such as stripping a referrer header, before continuing to the origin content server. Note: Some ICAP servers do not support virus scanning for request modification, but

support only content filtering.

49

Volume 7: Managing Content Section A: About Content Scanning The following diagram illustrates the request modification process flow.

Figure 3-2. Request Modification Process Flow

Returning the Object to the Blue Coat Appliance For response modification, the returned object can 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. Note: For request modifiction, an object is never returned, regardless of whether it is infected or clean.

Caching and Serving the Object After an object has been scanned and is determined to be cacheable, the SG appliance saves it and serves it for the subsequent content requests. When the appliance detects that the cached content has changed on the origin server, it fetches a fresh version, then forwards it to the ICAP server for scanning. If the SG appliance uses policies in the ICAP configuration, the policy applies to content fetches, distributions, refreshes, and pipelining fetches. For more information on policies, see "Section C: Creating ICAP Policy" on page 67. For more information on the layer, refer to Volume 10: Blue Coat SG Appliance Content Policy Language Guide.

50

Chapter 3: Malicious Content Scanning Services

Section A: About Content Scanning

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

Sense Settings The Sense Settings feature allows the SG appliance 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 56.

ISTags An ICAP v1.0 server is required to return in each response an ICAP header ISTag, which indicates 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 SG appliance. To force the SG appliance to recognize the old values, use the Sense Settings option, which is described in the configuration section.

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 subsequent requests. If a connection error occurs, the connection closes to prevent more errors.

Improving the User Experience Object scanning adds another operation to the user process of requesting and receiving Web content. Therefore, the user might experience extremely slightly noticeble delays during Web browsing as ICAP servers scan content. The SG appliance allows you to mitigate slower browse times and educate your users about what is occuring on their systems. This section describes those functionalities.

About Patience Pages Patience pages are HTML pages displayed to the user if an ICAP content scan exceeds the specified duration (seconds). You can configure the content of these pages to include a custom message and a help link. Patience pages refresh every five seconds and disappear when object scanning is complete. Notes ❐

Patience pages are not compatible with infinite stream connections—or live content streamed over HTTP—such as a cam or video feed. ICAP scanning cannot begin until the object download completes. Because this never occurs with this type of content, the SG appliance continues downloading until the maximum ICAP file size limit is breached. At that point, the SG appliance either returns an error or attempts to serve the content to the client (depending on fail open/closed policy). However, even when configured to fail open and serve the content, the delay added to downloading this large amount of data is often enough to cause the a user give up before reaching that point.

51

Volume 7: Managing Content Section A: About Content Scanning ❐

Patience pages are limited to Web browsers.

About Data Trickling Patience pages provide a solution to appease users during relatively short delays in object scans. However, scanning relatively large objects, scanning objects over a smaller bandwidth pipe, or high loads on servers might disrupt the user experience because connection timeouts occur. To prevent such timeouts, you can allow data trickling to occur. Depending on the trickling mode you enable, the SG appliance either trickles—or allows at a very slow rate—bytes to the client at the beginning of the scan or near the very end. The SG appliance begins serving server content without waiting for the ICAP scan result. However, to maintain security, the full object is not delivered until the results of the content scan are complete (and the object is determined to not be infected). Note: This feature is supported for the HTTP proxy only; FTP connections are not supported.

Trickling Data From the Start In trickle from start mode, the SG appliance buffers a small amount of the beginning of the response body. As the ICAP server continues to scan the response, the SG appliance allows one byte per second to the client.

Figure 3-3. A client receives only the initial bytes of a transaction during the ICAP scan.

After the ICAP server completes its scan: ❐

If the object is deemed to be clean (no response modification is required), the SG appliance sends the rest of the object bytes to the client at the best speed allowed by the connection.

❐

If the object is deemed to be malicious, the SG appliance terminates the connection and the remainder of the response object bytes—which in this case are the majority of the bytes—are not sent to the client.

Deployment Notes ❐

This method is the more secure option because the client receives only a small amount of data pending the outcome of the virus scan.

52

Chapter 3: Malicious Content Scanning Services

Section A: About Content Scanning ❐

One drawback is that users might become impatient, especially if they notice the browser display of bytes received. They might assume the connection is poor or the server is busy, close the client, and restart a connection.

Trickling Data at the End In trickle at end mode, the SG appliance sends the response to the client at the best speed allowed by the connection, except for the last 16 KB of data. As the ICAP server performs the content scan, the SG appliance allows one byte per second to the client.

Figure 3-4. A client receives most of the bytes immediately during the ICAP scan.

After the ICAP server completes its scan, the behavior is the same as described in “Trickling Data From the Start” on page 52. Deployment Notes ❐

Blue Coat recommends this method for media content, such as flash objects.

❐

This method is more user-friendly than trickle at start. This is because users tend to be more patient when they notice that 99% of the object is downloaded versus 1%, and are less likely to perform a connection restart. However, network administrators might perceive this method as the less secure method, as a majority of the object is delivered before the results of the ICAP scan.

General Deployment Notes This section provides comments about data trickling deployments. The Decision Between Data Trickling and Patience Pages Blue Coat SG appliance configuration options plus policy allow you to provide different ICAP feedback actions depending upon the type of traffic detected: ❐

Blue Coat defines interactive as the request involving a Web browser. Web browsers support data trickling and patience pages.

53

Volume 7: Managing Content Section A: About Content Scanning ❐

Non-interactive traffic originates from non-browser applications, such as automatic software download or update clients. Such clients are not compatible with patience pages; therefore, data trickling or no feedback are the only supported options.

Based on whether the requirements of your enterprise places a higher value either on security or availability, the SG appliance allows you to specify the appropriate policy. However, you must also consider the user agents involved when determining the appropriate feedback method. For example, streaming clients cannot deliever patience pages, but they are susceptible to connection timeouts. Therefore, trickling is the suggested method. The following diagram provides basic guidelines for deciding which feedback method to implement.

Figure 3-5. Deciding which ICAP feedback method to employ.

Infinite Streams Data trickling does not solve the issue of HTTP infinite streams. These are connections such as webcams or flash media—traffic over an HTTP connection—that conceivably have no end. Because the object cannot be fully downloaded, the ICAP content scan cannot start; however, the connection between the SG appliance and the AV appliance remains, which wastes finite connection resources. Strategic policy implementation, however, might be able to identify infinite streams and mark them to not be anti-virus scanned. If you employ the data trickle at end method, the user experience with infinite streams improves because the data is always delivered at the best connection speed possible.

54

Chapter 3: Malicious Content Scanning Services

Section A: About Content Scanning Proxy Chaining Deployments Proxy chaining deployments are common in enterprises, especially in core/branch office scenarios. Data trickling is achievable, but behavior is dependent upon how the SG appliances are configured. The following are common deployment scenarios. ❐

The downstream SG appliance is performing ICAP scanning, and the upstream SG appliance is not: Data trickling and patience pages are not affected in this scenario.

❐

The upstream SG appliance is performing ICAP scanning, and the downstream SG appliance is not: The only issue with this deployment is that user agent-specific policy

cannot be applied at the core SG appliance because the branch SG appliance consolidates multiple client requests in one out-going request to the upstream SG appliance. If data trickling is employed at the upstream SG appliance and if ICAP scanning detects a virus, the upstream SG appliance resets the client connection. This also deletes the corrupted object from the downstream SG appliance cache. ❐

Both SG appliances (upstream and downtream) are scanning: Behavior is mostly determined by the configuration of the upstream SG appliance.

•

If the upstream SG appliance is configured to deliver patience pages, then the downstream SG appliance also attempts to serve patience pages, including to non-graphical user agents. Therefore, this method is not recommended.

•

If the upstream SG appliance employs data trickle from start, the downstream SG appliance is not able to send any bytes to the client for a long period of time. If a patience page is not configured on the downstream SG appliance, users might experience connection timeouts.

•

If the upstream SG appliance employs trickle at end, the downstream SG appliance allows for all options of patience page and data trickling.

About ICAP Server Failover When creating an ICAP action, you can specify a list of ICAP servers or groups to use, in order of preference. If the first server or group in the list does not pass the health checks, the SG appliance moves down the list until it finds a server or group that is healthy and uses that to perform the scanning. The primary server resumes ICAP processing when the next health check is successful; the standby server or server group does not retain the primary responsibility. Notes ❐

Failover is configured as part of the ICAP policy definition.

❐

You cannot configure failover policy until ICAP services are configured on the SG appliance.

❐

To avoid errors, ICAP service names cannot be named fail_open or fail_closed (the CLI commands prevent these names from being created).

55

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications

Section B: Configuring SG Appliance ICAP Communications This section describes how to configure the SG appliance to communicate with an ICAP server to perform content scanning tasks.

Configuration Tasks Configuring ICAP on the SG appliance involves the following steps: ❐

Install the ICAP server.

❐

Configure the SG appliance to use ICAP and configure basic features.

❐

Specify feedback method (patience pages or data trickling).

❐

Define scanning policies, then load the policy file on the SG appliance.

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

Creating an ICAP Service An ICAP service on the SG appliance 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 SG appliance 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: 1.

Select Configuration > External Services > ICAP Services.

56

Chapter 3: Malicious Content Scanning Services

Section B: Configuring SG Appliance ICAP Communications

2a

2b

2.

3.

Add a new service: a.

Click New; the Add List Item dialog appears.

b.

In the Add ICAP Service field, enter an alphanumeric name. This example uses Response1.

c.

Click OK to close the dialog. The new ICAP object appears in the services list.

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

4a 4b 4c 4d 4e

4.

Configure the service communication options: Note: The default ICAP version is 1.0 and cannot be changed.

a.

In the Service URL field, enter the ICAP server URL (AV appliance), which includes the URL schema, ICAP server hostname or IP address, and the ICAP port number. For example:

57

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications icap://10.x.x.x/

The default port number is 1344, which can be changed. For example: icap://10.x.x.x:99. You can also enter an HTTP URL, but you must define a port number. Note: An ICAP service pointing to a WebWasher server must use icap as the protocol in the URL. Blue Coat also recommends that you review your specific ICAP server documentation, as each vendor might require additional URL information.

b.

The Maximum Number of Connections field specifies the maximum possible connections at any given time between the SG appliance and the ICAP server. The range is a number from 1 to 65535. The default is 5. The number of recommended connections depends on the capabilities of the ICAP server. Refer to the vendor’s product information.

c.

The Connection timeout field specifies the number of seconds the SG appliance waits for replies from the ICAP server. The range is 1 to 65536. The default timeout is 70 seconds.

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

Select Virus found page: Use vendor’s “virus found” page to display the default vendor error exception page to the client instead of the SG appliance exception page. This is the default behavior for SGOS upgrades from previous versions. This feature maintains the same appearance of previous versions, but also retains the inherent timestamp issues involved with cache hits. If this option is not selected, the exception pags originate from the SG appliance, and they employ the accurate timestamps for cache hits.

58

Chapter 3: Malicious Content Scanning Services

Section B: Configuring SG Appliance ICAP Communications

5b 5c 5d

5a

5e

5.

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

(Optional) Clicking Sense Settings automatically configures the ICAP service using the ICAP server parameters.

b.

Select the ICAP method: response modification or request modification. Note: An ICAP server might have separate URLs for response modification and request modification services.

c.

In the Preview size (bytes) field, enter a byte value and select enabled. 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.

d. (Optional) The Send options allow additional information to be forwarded to the ICAP server. Select one or more of the following: Client address, Server address, Authenticated user, or Authenticated groups.

6.

e.

Click Health check to perform an immediate health check on this service.

f.

Click OK to close the dialog.

Click Apply.

Managing ICAP Health Checks SG appliance health check features allow you to perform tasks such as immediate checking, disable health checks, and override various notifications and settings. To manage ICAP health checks: 1.

Select Configuration > Health Checks > General.

59

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications

2.

Select an ICAP service or service group.

3.

Click Perform health check to get an immediate connection status for the AV appliance or service group.

4.

Click Edit to display the Edit ICAP Health Check dialog.

5.

Select the Enabled state:

6.

•

Enabled: Marks the ICAP service or group as enabled and functioning.

•

Disabled, reporting as healthy: Marks the ICAP service as healthy, but not able to receive connections. One reason to select this option is to preserve current statistics; the disabled state is temporary.

•

Disabled, reporting as sick: Marks the ICAP service as down and not able to receive connections. One reason to select this is that you are taking the server offline for maintanance or replacement.

Click Apply.

The Health Check chapter in Volume 5: Advanced Networking provides more detailed information about all of the health check configuration options, including override features.

Deleting an ICAP Service The following steps describe how to delete an ICAP service. Note: You cannot delete an ICAP service used in an SG appliance policy (that is, if a policy rule uses the ICAP service name) or that belongs to a service group.

To delete an ICAP service: 1.

Select Configuration > External Services > ICAP.

2.

Select the service to be deleted.

3.

Click Delete; click OK to confirm.

4.

Click Apply.

60

Chapter 3: Malicious Content Scanning Services

Section B: Configuring SG Appliance ICAP Communications

Configuring ICAP Feedback This section describes how to specify what type of feedback is provided to users during an ICAP scan. See “Improving the User Experience” on page 51. To specify and configure the ICAP feedback method: 1.

Select Configuration > External Services > ICAP > ICAP Feedback.

2a 2b 2c

3a 3b 3c

2.

Configure options for interactive traffic (browser-based requests): a.

The Do not provide feedback... option means that if users experience delays in receiving content, they are not notified as to the reason (ICAP scanning). Selecting this option greys out the other options.

b.

The default duration to wait before notifiying a client that an ICAP scan is occuring is five seconds. You can change this value in the Provide feedback after field, but if you make the value too long, users might become impatient and manually close the client, believing the connection is hung.

c.

Select the feedback method: •

Return patience pages: The client displays a Web page to the user providing a description of the delay (ICAP scanning). This page is customizable, as described in the next section.

•

Trickle object data from start: The client receives 1 byte per second, which

should prevent connection timeouts while the ICAP server performs the scan. If the response from the ICAP server is clean, the client receives the rest of the object data at the best connection speed possible. If the scan detects malicious content, the connection is dropped. This is the more secure method.

61

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications •

3.

4.

Trickle object data at end: The client receives most (99%) of the object data, but the final bytes are sent at the rate of one per second while the ICAP scanner performs the scan. If the response from the ICAP server is clean, the client receives the rest of the object data at the best connection speed possible. If the scan detects malicious content, the connection is dropped. This is the least secure method, as most of the data has already been delivered to the client. However, this method provides the best user experience because there most of the object is already delivered.

Configure options for non-interactive traffic (content such as flash animation over HTTP): a.

The Do not provide feedback... option means that if users experience delays in receiving content, they are not notified as to the reason (ICAP scanning). Selecting this option greys out the other options.

b.

The default duration to wait before notifiying a client that an ICAP scan is occuring is five seconds. You can change this value in the Provide feedback after field, but if you make the value too long, users might become impatient and manually close the client, believing the connection is hung.

c.

Select the feedback method: •

Trickle object data from start: See the descriptions in Step 2.

•

Trickle object data at end: See the descriptions in Step 2.

Click Apply.

These configurations are global. You can define further feedback policy that applies to specific user and conditional subsets. In the VPM, the object is located in the Web Access Layer: Return ICAP Feedback.

Customizing ICAP Patience Text This section describes how to customize text displayed during ICAP scanning. Patience pages are displayed if the appropriate option is selected, as described in the previous section: “Improving the User Experience” on page 51.

HTTP Patience Text The SG appliance allows you to customize the patience page components and text that are displayed to users when HTTP clients experience delays as Web content is scanned. To customize HTTP patience pages: 1.

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

62

Chapter 3: Malicious Content Scanning Services

Section B: Configuring SG Appliance ICAP Communications

2a 2b 2c 2d

2.

In the HTTP Patience Page Customization section, click Header, Summary, Details, or Help. The corresponding customize dialog appears. Customize the information as appropriate.

a.

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

b.

Custom Patience Summary Message—HTML and text that informs users that

a content scan is occurring.

63

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications

c.

Custom Patience Details Message—Uses data to indicate scanning progress.

The information includes the URL currently being scanned, the number of bytes processed, and the elapsed time of the scan.

d. Custom Patience Help Message—Displays instructions for users should they experience a problem with the patience page. 3.

Click Apply.

All of these components are displayed on the patience page.

Windows XP, Service Pack 2 Behavior Microsoft is continually updating Windows XP security measures, which impacts how the SG appliance 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 SG appliance 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.

64

Chapter 3: Malicious Content Scanning Services

Section B: Configuring SG Appliance ICAP Communications

Interactivity Notes ❐

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 attempts 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 error); 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 SG appliance pipelines the object in the Location header. After the SG appliance 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 SG appliance from pipelining these requests (which decreases performance) and to retain the ability to provide a patience page, configure HTTP as follows: #SGOS (config) http no pipeline client redirects

❐

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

❐

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 displays in a separate 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 For content over FTP, the patience text displayed to FTP clients during an ICAP scan can be modified. To customize FTP patience text: 1.

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

65

Volume 7: Managing Content Section B: Configuring SG Appliance ICAP Communications

2

2.

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

3.

Click OK.

4.

Click Apply.

Related CLI Syntax to Manage ICAP Communications ❐

To enter configuration mode: SGOS# (config) external-services

❐

The following subcommands are available: SGOS# (config external-services) create icap service_name SGOS# (config external-services) edit service_name SGOS# (config icap service_name) url icap://url SGOS# (config icap service_name) max-conn number SGOS# (config icap service_name) timeout timeout_seconds SGOS# (config icap service_name) notify virus-detected SGOS# (config icap service_name) methods {REQMOD | RESPMOD} SSGOS# (config icap service_name) preview-size bytes SGOS# (config icap service_name) send {client-address | serveraddress} SGOS# (config icap service_name) send {authenticated-user | authenticated-groups} SGOS# (config icap services service_name) sense-settings SGOS# (config icap services service_name) patience-page seconds SGOS# (config external-service) delete service_name SGOS# (config external-services) inline http icap-patience {details | header | help | javascript | summary} eof SGOS# (config external-services) inline ftp icap-patience-text eof SGOS# (config external-services) icap feedback interactive patiencepage {seconds) SGOS# (config external-services) icap feedback {interactive | noninteractive} {trickle-start | trickle-end | none}{seconds)

66

Chapter 3: Malicious Content Scanning Services

Section C: Creating ICAP Policy

Section C: Creating ICAP Policy Defined ICAP policy dictates the anti-virus and ICAP server failover 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, refer to Volume 6: VPM and Advanced Policy. Use the request.icap_service() (request modification) or response.icap_service() (response modification) properties to manage the SG appliance ICAP services.

VPM Objects The VPM contains the following objects specific to AV scanning (linked to their descriptions in the VPM chapter). Table 3-2. AV Scanning Objects Object

Layer>Column

Virus Detected

Web Access>Service

ICAP Error Code

Web Access>Service

Return ICAP Feedback

Web Access>Action

Set ICAP Request Service

Web Access>Action

Set ICAP Request Service

Web Content>Action

Set ICAP Response Service

Web Content>Action

Note: For CPL policy, refer to Volume 10: Blue Coat SG Appliance Content Policy Language

Guide.

Example ICAP Scanning 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), and provides failover with backup ICAP services. For this example: ❐

The SG appliance has configured ICAP services. The response service is avresponse1 and the request service is avrequest1.

❐

Two backup response services are configured: avreponse2 and avresponse3.

❐

The Blue Coat AV is the virus scanner and it is configured to serve passwordprotected files.

❐

A group named IT is configured on the SG appliance.

❐

The IT group wants the ability to download password protected files, but deny everyone else from doing the same.

67

Volume 7: Managing Content Section C: Creating ICAP Policy To perform virus scanning, protecting both the server side and the client side: 1.

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

2.

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

3.

Click New.

4.

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

5a

5b

5c

5.

Configure the request service object: a.

Select Use ICAP request service.

b.

Select the avrequest1 and click Add (this moves the service name to the field on the right).

c.

Accept the default: 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 and is denied.

d. Click OK; click OK again to add the object to the rule.

68

Chapter 3: Malicious Content Scanning Services

Section C: Creating ICAP Policy

Figure 3-6. Request

6.

In the VPM, select Policy > Web Content Rule. Name the rule ResponseAV.

7.

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

8.

Click New.

9.

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

10a

10b 10c

10d

10. Configure the response service object: a.

Select Use ICAP response service.

b.

Select avresponse1 and click Add.

c.

Repeat Step b for to add the additional (failover) services.

d. Select Deny the client request. This scans the responses for viruses before the object is delivered to the client. If a virus is found, the content is not served. e.

Click OK; click OK again to add the object to the rule.

69

Chapter 3: Malicious Content Scanning Services

Section C: Creating ICAP Policy To log a detected virus: 1.

In the VPM, select Policy > Web Access Layer. Name the layer AVErrors.

2.

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

Select Virus Detected (static object).

b.

Click OK to add the object to the rule.

3.

Right-click the Action column. Select Delete.

4.

Right-click the Track column. Select Set; the Set Track Object dialog appears. a.

Click New; select Event Log. The Event Log dialog appears.

b.

In the Name field, enter VirusLog1.

c.

From the scroll-list, select icap_virus_details, localtime, and clientaddress. Click Insert.

d. Click OK; click OK again to add the object to the rule.

Figure 3-7. The AVErrors rule

To create an exception for IT group: 1.

In VPM, select Policy > Add Web Access Layer. Name the rule AVExceptions.

2.

Add the IT group object to the Source column.

3.

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

4.

Click New; select ICAP Error Code. The Add ICAP Error Code Object appears.

70

Volume 7: Managing Content Section C: Creating ICAP Policy

5.

Add the error code: a.

Select Selected Errors.

b.

From the list of errors, select Password Protected Archive; click Add.

c.

Name the object password_protected.

d. Click OK; click OK again to add the object to the rule. 6.

Right-click the Action column and select Allow.

7.

Click Add Rule.

8.

In the Service column, add the password_protected object.

9.

Right-click the Action column; select Deny.

After this policy is installed: ❐

Virus scanning is performed for client attempts to upload content and content responses to client requests.

❐

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

71

Chapter 3: Malicious Content Scanning Services

Section C: Creating ICAP Policy ❐

As the Blue Coat AV 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 Note 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 a workaround policy to bypass the ICAP request modification service for HTTP progressive downloads: 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 the serving of objects without ICAP processing if the server is down. request.icap_service(service_name, fail_open) response.icap_service(service_name, fail_open)

When the ICAP service is restored, these objects are scanned and served from the cache if they are requested again. Note: Blue Coat recommends this CPL to be used for internal sites; use with caution.

72

Volume 7: Managing Content Section C: Creating ICAP Policy ❐

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

73

Chapter 3: Malicious Content Scanning Services

Section D: Managing Virus Scanning

Section D: Managing Virus Scanning You might need to perform additional SG appliance 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 SG appliance 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, refer to Chapter 4: "Configuring Service Groups" on page 77.

Improving Virus Scanning Performance You can overcome request-handling limitations of ICAP servers. Generally, SG appliances 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 SG appliance, 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, refer to Chapter 4: "Configuring Service Groups" on page 77. For more information about defining policies, refer to the Managing Policy Files chapter in Volume 6: VPM and Advanced Policy, as well as Volume 11: Blue Coat SG Appliance Command Line Reference. When the virus definitions are updated, the SG appliance stores a signature. This signature consists of the server name plus a virus definition version. If either of these changes, the SG appliance 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 SG appliance and a supported ICAP server after a version update of the server, you might need to configure the preview size the appliance uses. For information, see “Creating an ICAP Service” on page 56.

74

Chapter 3: Malicious Content Scanning Services

Section D: Managing Virus Scanning

Replacing the ICAP Server If you replace an ICAP server with another supported ICAP server, reconfigure the ICAP service on the SG appliance: 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 56.

Access Logging The SG appliance provides access log support for Symantec 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.

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”

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. Also, if the access log string is already 250 characters and the SG appliance 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, refer to Volume 8: Access Logging.

75

Volume 7: Managing Content

76

Chapter 4: Configuring Service Groups

This chapter describes how to create and manage ICAP or Websense service groups. In high-traffic network environments, a service group accelerates response time by a performing a higher volume of scanning.

About Weighted Load Balancing The SG appliance supports weighted load balancing in forwarding requests to service groups. By default, the SG appliance 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. 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. 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.

Note: External services (ICAP, Websense off-box) have a reserved connection for health checks (if you created health check services). This means that as the load goes up and the number of connections to the external service reaches the maximum, with additional requests being queued up and waiting, the maximum simultaneous connections is actually one less than the limit.

The following diagram provides an example of how weighting works with a service group of three Blue Coat AV ICAP servers.

77

Volume 7: Managing Content

Figure 4-1. Service Group Process Flow 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.

Creating a Service Group Create the service group and add the relevant ICAP or Websense services to the group. Services within group must be the same type (ICAP or Websense). To configure a service group: 1.

Select Configuration > External Services > Service-Groups.

78

Chapter 4: Configuring Service Groups

2b

2a

2.

3.

Add a new group: a.

Click New; the Add List Item dialog appears.

b.

In the Add Service Group field, enter an alphanumeric name. This example creates a group called ICAP_Response.

c.

Click OK.

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

79

Volume 7: Managing Content

4b

4c

4a

4.

Select existing services: a.

Click New; the Add Service Group Entry dialog appears.

b.

If this SG appliance contains many configured ICAP or Websense (off-box) services, you can narrow the viewable list by selecting List ICAP services or List Websense services.

c.

From the list of existing services, select the ones to add to this group. Hold the Control or Shift key to select multiple services.

d. Click OK to add the selected services to group.

80

Chapter 4: Configuring Service Groups

5b 5a

5.

Assign weights to services: a.

Select a service and click Edit; the Edit Service Group Entry weight dialog appears.

b.

In the Entry Weight field, assign a weight value. The valid range is 0-255. For conceptual information about service weighting, see “About Weighted Load Balancing” on page 77.

c.

Repeat steps a and b for other services, as required.

d. Click OK to close the dialog. e. 6.

Click OK again to close the Edit Service Group Entry dialog

Click Apply.

Result: When instructed by created policies, the SG appliance sends ICAP response modification requests to ICAP servers in the service group. The load carried by each service in the group is determined by the weight values.

Deleting a Service Group or Group Entry You can delete the configuration for an entire service group from the SG appliance, or you can delete individual entries from a service group. Note: A service or service group used in a SG appliance policy (that is, if a policy rule uses the entry) cannot be deleted; it must first be removed from the policy.

81

Volume 7: Managing Content To delete a service group: 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 entry: 1.

Select Configuration > External Services > Service-Groups.

2.

Select the service group to be modified.

3.

Click Edit.

4.

Select the service entry to be deleted; click Delete.

5.

Click OK.

6.

Click Apply.

Displaying External Service and Group Information After configuring a service group, you can display aggregate service group (and other External Services) information. To display information about all external services and groups: 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

82

Chapter 4: Configuring Service Groups

; External Service-Groups CorpICAP total weight 5 entries: ICAP1 weight 4 ICAP2 weight 1 BranchWebsense total weight entries: Websense1 weight 1 Websense2 weight 1

2

Related CLI Syntax to Manage External Services ❐

To enter configuration mode: SGOS# (config) external-services

❐

The following commands are available: SGOS# (config external-services) create service-group name SGOS# (config service-group name) add service_name SGOS# (config service-group name) edit service_name SGOS# (config service-group name) weight value SGOS# (config external-services) delete service_group_name SGOS# (config type name) remove entry_name SGOS# (config external-services) view SGOS# (config type name) view

83

Volume 7: Managing Content

84

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

85

Volume 7: Managing Content

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

86

Appendix A: Glossary

cache control

Allows you to configure which content the SG appliance stores.

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

87

Volume 7: Managing Content

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

88

Appendix A: Glossary

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

89

Volume 7: Managing Content

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

90

Appendix A: Glossary

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

91

Volume 7: Managing Content

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

92

Appendix A: Glossary

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

93

Volume 7: Managing Content

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

94

Appendix A: Glossary

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S

95

Volume 7: Managing Content

secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

96

Appendix A: Glossary

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

97

Volume 7: Managing Content

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

98

Appendix A: Glossary

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

99

Volume 7: Managing Content

100

Index

Numerics

D

3rd party configuring 28 specifying a time period 33 specifying time period 33

data trickling, about 52 document conventions 7 Dynamic Categorization about 12

A access logging, ICAP 75

B

F FTP, content scanning 48

H

Blue Coat SG ICAP service configuration 56 Blue Coat Web Filter configuring 14 specifying a time period 16 update time period 16

headers request modification 49 response modification 48 HTTP, scanning HTTP objects 48 HTTPS, content scanning 48

C

I

content filtering 3rd party configuring 28 3rd party, automatic download 33 Blue Coat Web Filter configuring 14 example of category= 35 expired database, using 40 expired license, downloading a database with 40 IWF automatic download 26 configuring 24 local database configuring 20 policy with vendor categories 37 provider, selecting 19 SmartFilter configuring 30 Websense on-box configuring 31 content scanning ICAP service 56 policy for 48

ICAP configuring Blue Coat SG for 56 data trickling 52 failover, about 55 feedback, configuring 61 health checks, managing 59 installing server 56 ISTags 51 patience pages, about 51 patience text, customizing 62 policy examples 67 replacing the server 75 request modification, about 49 response modification, about 48 sense settings 51 service, creating 56 IWF configuring 24 custom time frame update 26 scheduling download 26

L local database configuring 20

101

Volume 7: Managing Content

P

S

patience pages, about 51 policy content scanning 48 example, limit access to certain Web sites 38 example, limit access to specified time of day 38 vendor categories, using with 37

SmartFilter configuring 30

V

R

virus scanning advanced configurations 74 managing 74 replacing the ICAP server 75

request modification, about 49 response modification, about 48

W Websense on-box configuring 31

102

Blue Coat® Systems SG Appliance

Volume 8: Access Logging

Version SGOS 5.2.2

Volume 8: Access Logging

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02845 Document Revision: SGOS 5.2.2 09/2007

ii

Contents Contact Information Chapter 1: About Access Logging Overview ..............................................................................................................................................................5 Understanding Facilities ....................................................................................................................................5 Understanding Protocols and Formats ............................................................................................................6 Enabling or Disabling Access Logging ............................................................................................................7 Document Conventions......................................................................................................................................8 Chapter 2: Creating and Editing Log Formats Creating a Custom or ELFF Log Format........................................................................................................11 Chapter 3: Creating and Editing An Access Log Facility Editing an Existing Log Facility ......................................................................................................................16 Associating a Log Facility with a Protocol ....................................................................................................17 Disabling Access Logging for a Particular Protocol.....................................................................................18 Configuring Global Settings ............................................................................................................................18 Chapter 4: Configuring the Upload Client Encrypting the Access Log...............................................................................................................................22 Importing an External Certificate ...................................................................................................................22 Deleting an External Certificate ...............................................................................................................23 Digitally Signing Access Logs .........................................................................................................................23 Disabling Log Uploads .....................................................................................................................................26 Decrypting an Encrypted Access Log ............................................................................................................26 Verifying a Digital Signature ...........................................................................................................................26 Editing Upload Clients .....................................................................................................................................26 Editing the FTP Client ...............................................................................................................................27 Editing the HTTP Client............................................................................................................................28 Editing the Custom Client ........................................................................................................................29 Editing the Custom SurfControl Client ..................................................................................................30 Editing the Websense Client.....................................................................................................................30 Chapter 5: Configuring the Upload Schedule Testing Access Log Uploading ........................................................................................................................35 Viewing Access-Log Statistics .........................................................................................................................35 Viewing the Access Log Tail.....................................................................................................................35 Viewing the Log File Size..........................................................................................................................36 Viewing Access Logging Status ...............................................................................................................37 Viewing Access-Log Statistics ..................................................................................................................38 Example: Using VPM to Prevent Logging of Entries Matching a Source IP ............................................39

iii

Volume 8: Access Logging

Appendix A: Glossary Appendix B: Access Log Formats Custom or W3C ELFF Format......................................................................................................................... 55 Example Access Log Formats................................................................................................................... 57 SQUID-Compatible Format ............................................................................................................................. 58 Action Field Values.................................................................................................................................... 58 NCSA Common Access Log Format .............................................................................................................. 59 Access Log Filename Formats.................................................................................................................. 60 Fields Available for Creating Access Log Formats ...................................................................................... 61 Index

iv

Chapter 1: About Access Logging

Access logging allows you to track Web usage for the entire network or specific information on user or department usage patterns. These logs and reports can be made available in real-time or on a scheduled basis. Note: Event logging is not the same as access logging. Event logging allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring.

Overview SGOS can create access logs for the traffic flowing through the system; in fact, each protocol can create an access log record at the end of each transaction for that protocol (such as for each HTTP request). Note: The only data that can be logged in an access log on the SG appliance are the

access-log fields and the CPL fields (found in Appendix A: "Access Log Formats"). These log records can be directed to one or more log facilities, which associates the logs with their configured log formats, upload schedules, and other customizable components. In addition, access logs can be encrypted and digitally signed prior to upload. Data stored in log facilities can be automatically uploaded to a remote location for analysis and archive purposes. The uploads can take placing using HTTP, FTP, or one of several proprietary protocols. Once uploaded, reporting tools such as Blue Coat Reporter can be used to analyze the log files. For information on using Blue Coat Reporter, refer to the Blue Coat Reporter Configuration and Management Guide.

Understanding Facilities A log facility is a separate log that contains a single logical file and supports a single log format. The facility contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded. Multiple access log facilities are supported, although each access log supports a single log format. You can log a single transaction to multiple log facilities through a global configuration setting for the protocol that can be modified on a per-transaction basis via policy.

5

Volume 8: Access Logging

Understanding Protocols and Formats The following protocols support configurable access logging: ❐

CIFS

❐

Endpoint Mapper

❐

FTP

❐

HTTP

❐

HTTPS Forward Proxy

❐

HTTPS Reverse Proxy

❐

ICP

❐

Instant Messaging

❐

Peer-to-peer (P2P)

❐

RealMedia/QuickTime

❐

SOCKS

❐

SSL

❐

TCP Tunnel

❐

Telnet

❐

Windows Media

6

Chapter 1: About Access Logging

SGOS can create access logs with any one of a number of log formats, and you can create additional types using custom or ELFF format strings. The log types supported are: ❐

NCSA common log format

❐

SQUID-compatible format

❐

ELFF (W3C Extended Log File Format)

❐

Custom, using the strings you enter

❐

SmartReporter, an ELFF log format compatible with the SmartFilter Reporter tool

❐

SurfControl, a log format compatible with the SurfControl Reporter tool

❐

Websense, a log format compatible with the Websense Reporter tool

The log facilities, each containing a single logical file and supporting a single log format, are managed by policy (created through VPM or CPL), which specifies the destination log format and log file.

Enabling or Disabling Access Logging You can globally enable or disable access logging. If access logging is disabled, logging is turned off for all log objects, even if logging policy exists or logging configurations are set. Once globally enabled, connection information is sent to the default log facility for the service. For example, HTTP traffic is logged to the main file. By default, access logging is disabled on all new systems, but certain protocols are configured to use specific logs by default. When access logging is enabled, logging begins immediately for all configured protocols. To enable or disable access logging: 1.

Select Configuration > Access Logging > General > Default Logging.

2

2.

Select Enable to enable access logging or deselect it to disable access logging.

3.

Click Apply to commit the changes to the SG appliance.

Volume 8: Access Logging contains the following topics: ❐

Chapter 2: "Creating and Editing Log Formats" on page 9

7

Volume 8: Access Logging

❐

Chapter 3: "Creating and Editing An Access Log Facility" on page 15

❐

Chapter 4: "Configuring the Upload Client" on page 21

❐

Chapter 5: "Configuring the Upload Schedule" on page 33

❐

Appendix A: "Glossary" on page 41

❐

Appendix A: "Access Log Formats" on page 55

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

8

Chapter 2: Creating and Editing Log Formats

You should first decide what protocols and log formats you want to use, the logging policy, and the upload schedule. Then you can do the following: ❐

Associate a log format with the log facility.

❐

Associate a log facility with a protocol and/or create policies for protocol association and to manage the access logs and generate entries in them (if you do both, policy takes precedence).

❐

Determine the upload parameters for the log facility.

The Format tab allows you to create a format to use for your log facilities. Several log formats ship with the SGOS software, and they might be sufficient for your needs. If the formats that exist do not meet your needs, you can use the Format tab to create a custom or ELFF format and specify the string and other qualifiers used. Several log formats already exist. For a description of each value in the log, see Appendix A: "Access Log Formats" on page 55. ❐

cifs: This is an ELFF format with the custom strings of date time c-ip r-ip r-port x-cifs-method x-cifs-server x-cifs-share x-cifs-path x-cifs-orig-path x-cifs-client-bytes-read x-cifs-serverbytes-read x-cifs-bytes-written s-action cs-username cs-auth-group s-ip

❐

mapi: This is an ELFF format with the custom strings of date time c-ip c-port r-ip r-port x-mapi-user x-mapi-method cs-bytes sr-bytes rs-bytes sc-bytes x-mapi-cs-rpc-count x-mapi-sr-rpc-count x-mapi-rs-rpc-count x-mapi-sc-rpc-count s-action cs-username csauth-group s-ip

❐

im (Instant Messaging): This is an ELFF format with the custom strings of: date time c-ip cs-username cs-auth-group cs-protocol x-im-method xim-user-id x-im-user-name x-im-user-state x-im-client-info x-imbuddy-id x-im-buddy-name x-im-buddy-state x-im-chat-room-id x-imchat-room-type x-im-chat-room-members x-im-message-text x-immessage-size x-im-message-route x-im-message-type x-im-file-path xim-file-size s-action

❐

main: This is an ELFF format with custom strings of: date time time-taken c-ip sc-status s-action sc-bytes cs-bytes csmethod cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uri-query cs-username cs-auth-group s-hierarchy s-supplier-name rs(ContentType) cs(User-Agent) sc-filter-result cs-category x-virus-id s-ip ssitename

❐

ncsa: This is a reserved format that cannot be edited. The NCSA/Common format

contains the following strings: remotehost rfc931 authuser [date] “request” status bytes

The ELFF/custom access log format strings that represent the strings above are: $(c-ip) - $(cs-username) $(localtime) $(cs-request-line) $(scstatus) $(sc-bytes)

9

Volume 8: Access Logging

❐

p2p: This is an ELFF format with custom strings of: date time c-ip c-dns cs-username cs-auth-group cs-protocol x-p2pclient-type x-p2p-client-info x-p2p-client-bytes x-p2p-peer-bytes duration s-action

❐

smartreporter: This is a reserved format that cannot be edited. It contains the following string: localtime s-computername c-ip c-uri sc-filter-result cs-categories csuser sc-bytes

❐

squid: This is a reserved format that cannot be edited. You can create a new SQUID log format using custom strings. The default SQUID format is SQUID-1.1 and SQUID-2 compatible.

SQUID uses several definitions for its field formats: SQUID-1:time elapsed remotehost code/status/peerstatus bytes method URL SQUID-1.1: time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type

SQUID-2 has the same fields as SQUID-1.1, although some of the field values have changed. ❐

ssl: This is an ELFF format with custom strings of: date time time-taken c-ip s-action x-rs-certificate-validate-status xrs-certificate-observed-errors cs-host s-hierarchy s-supplier-name xrs-connection-negotiated-ssl-version x-rs-connection-negotiated-cipher x-rs-connection-negotiated-cipher-size x-rs-certificate-hostname x-rscertificate-hostname-category x-cs-connection-negotiated-ssl-version x-cs-connection-negotiated-cipher x-cs-connection-negotiated-ciphersize x-cs-certificate-subject s-ip s-sitename

❐

streaming: This is an ELFF format with custom strings of: c-ip date time c-dns cs-uri-scheme cs-host cs-uri-port cs-uri-path csuri-query c-starttime x-duration c-rate c-status c-playerid cplayerversion c-playerlanguage cs(User-Agent) cs(Referer) c-hostexe chostexever c-os c-osversion c-cpu filelength filesize avgbandwidth protocol transport audiocodec videocodec channelURL sc-bytes c-bytes s-pkts-sent c-pkts-received c-pkts-lost-client c-pkts-lost-net c-pktslost-cont-net c-resendreqs c-pkts-recovered-ECC c-pkts-recoveredresent c-buffercount c-totalbuffertime c-quality s-ip s-dns stotalclients s-cpu-util x-cache-user s-session-id x-cache-info xclient-address

❐

surfcontrol, surfcontrolv5, and smartfilter: These are reserved formats that cannot be

edited. ❐

websense: This is a reserved format that cannot be edited.

❐

bcreportermain_v1: This is a reserved format that cannot be edited: date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories cs(Referer) sc-status s-action cs-method rs(Content-Type) cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uriquery cs-uri-extension cs(User-Agent) s-ip sc-bytes cs-bytes x-virusid

10

Chapter 2: Creating and Editing Log Formats

❐

bcreporterssl_v1: This is a reserved format that cannot be edited. It only contains fields that do not reveal private or sensitive information, unlike the bcreportermain_v1

format: date time time-taken c-ip cs-username cs-auth-group x-exception-id scfilter-result cs-categories sc-status s-action cs-method rs(ContentType) cs-uri-scheme cs-host cs-uri-port cs-uri-extension cs(UserAgent) s-ip sc-bytes cs-bytes x-virus-id x-rs-certificate-observederrors x-rs-connection-negotiated-cipher-strength x-rs-certificatehostname x-rs-certificate-hostname-category ❐

bcreportercifs_v1: This is a reserved format that cannot be edited: date time c-ip c-port r-ip r-port x-cifs-uid x-cifs-tid x-cifs-fid xcifs-method x-cifs-server x-cifs-share x-cifs-path x-cifs-orig-path xcifs-client-bytes-read x-cifs-server-bytes-read x-cifs-bytes-written x-client-connection-bytes x-server-connection-bytes x-server-adnconnection-bytes x-cifs-client-read-operations x-cifs-client-writeoperations x-cifs-client-other-operations x-cifs-server-operations saction x-cifs-error-code cs-username cs-auth-group s-ip

Note: If you had previously created formats with the name smartreporter or surfcontrolv5 and you upgrade the device, those formats are changed to smartreporter_user or surfcontrolv5_user. If you already have a log format named smartreporter_user or surfcontrolv5_user, then the names become smartreporter_user1 or surfcontrolv5_user1. This naming protocol continues (_user2, _user3...) as necessary. The logs associated with

these formats are automatically associated with the new format name.

Creating a Custom or ELFF Log Format Complete the following steps to create a custom or ELFF log format. To create or edit the log format: 1.

Select Configuration > Access Logging > Formats.

2.

Click New (or highlight a format and click Edit). The Create Format dialog displays. If you select an unconfigurable format, you receive an error message.

11

Volume 8: Access Logging

3a 3b 3c 3d

3.

Create or modify the format: a.

Give the format a meaningful name.

b.

Select Custom format string (to manually add your own format field)s or W3C ELFF (to customize using the standard format fields).

c.

Add log formats or remove from the current list. Note: ELFF strings cannot start with spaces.

The access log ignores any ELFF or custom format fields it does not understand. In a downgrade, the format still contains all the fields used in the upgraded version, but only the valid fields for the downgraded version display any information. d. Click Test Format to test whether the format-string syntax is correct. A line displays below the field that indicates that testing is in progress and then gives a result, such as Format is valid. Note: To double-check the format-string syntax, see “Creating a Custom or ELFF Log Format” on page 11.

4.

e.

From the Multiple-valued header policy drop-down list, select a header to log: Log last header, log first header, log all headers. This allows you to determine what happens with HTTP-headers that have multiple headers.

f.

Click OK.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Manage Access Logging ❐

To enter configuration mode: SGOS#(config) access-log

The following subcommands are available: SGOS#(config access-log) create log log_name SGOS#(config access-log) create format format_name SGOS#(config access-log) cancel-upload all SGOS#(config access-log) cancel-upload log log_name SGOS#(config access-log) default-logging {cifs | epmapper | ftp | http | https-forward-proxy | https-reverse-proxy | icp | im | mapi | mms | p2p | rtsp | socks | ssl | tcp-tunnel | telnet} log_name

12

Chapter 2: Creating and Editing Log Formats

SGOS#(config access-log) delete log log_name SGOS#(config access-log) delete format format_name SGOS#(config access-log) disable SGOS#(config access-log) early-upload megabytes SGOS#(config access-log) edit log log_name—changes the prompt to SGOS#(config edit log log_name) SGOS#(config access-log) edit format format_name—changes the prompt to SGOS#(config edit format format_name) SGOS#(config access-log) enable SGOS#(config access-log) exit SGOS#(config access-log) max-log-size megabytes SGOS#(config access-log) no default-logging {cifs | epmapper | ftp | http | https-forward-proxy | https-reverse-proxy | icp | im | mapi | mms | p2p | rtsp | socks | ssl | tcp-tunnel | telnet} SGOS#(config access-log) overflow-policy delete SGOS#(config access-log) overflow-policy stop SGOS#(config access-log) upload all SGOS#(config access-log) upload log log_name SGOS#(config access-log) view SGOS#(config access-log) view [log [brief | log_name]] SGOS#(config access-log) view [format [brief | format_name]] SGOS#(config access-log) view [statistics [log_name]] SGOS#(config access-log) view [default-logging]

13

Volume 8: Access Logging

14

Chapter 3: Creating and Editing An Access Log Facility

You can use existing log facilities and modify them for your needs. You can also create new log facilities for special circumstances, such as associating the SurfControl log format with a log facility. To create new log facilities, continue with the next section. To edit an existing log facility, skip to “Configuring Global Settings” on page 18. Note: Several log facilities have already been created. Before creating a new one, check the existing ones to see if they fit your needs. If you want to use a custom log format with the new log facility, you must create the log format before associating it with a log (see Chapter 2: "Creating and Editing Log Formats" on page 9).

To create a log facility: 1.

Select Configuration > Access Logging > Logs > Logs.

2.

The log facilities already created are displayed in the Logs tab. To create a new log, click New.

3a 3b 3c

4a 4b

3.

4.

Fill in the fields as appropriate: a.

Log Name: Enter a log facility name that is meaningful to you.

b.

Log Format: Select a log format from the drop-down list.

c.

Description: Enter a meaningful description of the log. It is used for display purposes only.

Fill in the Log file limits panel as appropriate. (You can edit these settings later. See “Configuring Global Settings” on page 18.)

15

Volume 8: Access Logging

a.

The maximum size for each remote log file (the file on the upload server) defaults to 0, meaning that all data is sent to the same log file. If you set a maximum size, a new log file opens when the file reaches that size. This setting is valid for both periodic and continuous uploads.

b.

Specify a size that triggers an early upload—the maximum upload size varies depending on the size of the appliance disks (the maximum allowed upload threshold appears below this field).

5.

Click OK.

6.

Click Apply to commit the changes to the SG appliance.

Editing an Existing Log Facility Several facilities exist, each associated with a log format. For a description of the format, see “Chapter 3: Creating and Editing An Access Log Facility” . ❐

im (Instant Messaging): Associated with the im format.

❐

main: Associated with the main format.

❐

p2p (Peer-to-Peer): Associated with the p2p format.

❐

ssl: Associated with the SSL format.

❐

streaming: Associated with the streaming format.

Use the following procedures to edit log facilities you have created. Note: If you change the log format of a log, remember that ELFF formats require an ELFF header in the log (the list of fields being logged are mentioned in the header) and that non-ELFF formats do not require this header.

The format of data written to the log changes as soon as the format change is applied; for best practices, do a log upload before the format change and immediately after (to minimize the number of log lines in a file with mixed log formats). Upload the log facility before you switch the format. To edit an existing log facility: 1.

Select Configuration > Access Logging > Logs > General Settings.

2a 2b 2c

3a 3b

16

Chapter 3: Creating and Editing An Access Log Facility

2.

Fill in the fields as appropriate: a.

Log: Select an already-existing log facility from the Log drop-down list.

b.

Log Format: Select the log format from the drop-down list.

c.

Description: Enter a meaningful description of the log. (If you chose an

existing log format, the default description for that log is displayed. You can change it.) 3.

Fill in the Log file limits panel as appropriate: a.

The maximum size for each remote log file (the file on the upload server) defaults to 0, meaning that all data is sent to the same log file. If you set a maximum size, a new log file opens when the file reaches that size. This setting is valid for both periodic and continuous uploads.

b.

Specify a size that triggers an early upload—the maximum upload size varies depending on the size of the appliance disks (the maximum allowed upload threshold appears below this field).

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Associating a Log Facility with a Protocol You can associate a log facility with a protocol at any point in the process. By default, new systems have specific protocols associated with specific logs. This allows you to begin access logging as soon as it is enabled (see Chapter 3: "Creating and Editing An Access Log Facility" on page 15). Note: If you have a policy that defines protocol and log association, that policy overrides any settings you make here.

The following list shows the protocols supported and the default log facilities assigned to them, if any: Table 3-1. Default Log Facility Assignments Protocol

Assigned Default Log Facility

Endpoint Mapper

main

FTP

main

HTTP

main

HTTPS-Reverse-Proxy

main (Set to the same log facility that HTTP is using upon upgrade.)

HTTPS-Forward-Proxy

ssl (If the facility for HTTP, TCP, or SOCKS is set before upgrade.)

ICP

none

Instant Messaging

im

MAPI

mapi

Peer to Peer

p2p

17

Volume 8: Access Logging

Table 3-1. Default Log Facility Assignments (Continued) Protocol

Assigned Default Log Facility

RealMedia/QuickTime

streaming

SOCKS

none

SSL

ssl (If the facility for HTTP, TCP or SOCKS is set before upgrade.)

TCP Tunnel

main

Telnet

main

Windows Media

streaming

Note: To disable access logging for a particular protocol, you must either disable the default logging policy for that protocol (see “Disabling Access Logging for a Particular Protocol” on page 18) or modify the access logging policy in VPM (refer to Volume 6: The Visual Policy Manager and Advanced Policy Tasks).

To associate a log facility with a protocol: 1.

Select Configuration > Access Logging > General > Default Logging.

2.

Highlight the protocol you want to associate with a log facility and click Edit.

3.

Select a log facility from the Default Log drop-down list. Note: To disable access logging for that protocol, select none.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Disabling Access Logging for a Particular Protocol To disable access logging for a particular protocol: 1.

Select Configuration > Access Logging > General > Default Logging.

2.

Highlight the protocol to disable access logging and click Edit.

3.

Select none from the drop-down menu.

4.

Click OK.

5.

Click Apply to commit the changes to the SG appliance.

Configuring Global Settings You can set global limits for log size and early upload times. These settings can be overridden by individual log facilities. To set global log facility limits: 1.

Select Configuration > Access Logging > General > Global Settings.

18

Chapter 3: Creating and Editing An Access Log Facility

2a 2b 2c

3

2.

Fill in the Global Log File Limits panel as appropriate: a.

Configure the maximum size occupied by all of the log files (in megabytes).

b.

Determine the behavior of the log when the maximum size is reached. You can have the log stop logging (and do an immediate upload) or have it delete the oldest log entries.

c.

Specify the size of the log that triggers an early upload.

3.

The Global Upload options affect all log facilities currently available. They do not affect scheduled upload times. You can upload logs now, using the periodic upload method, or you can cancel all the uploads that are currently in progress.

4.

Click Apply to commit the changes to the SG appliance.

19

Volume 8: Access Logging

20

Chapter 4: Configuring the Upload Client

Blue Coat supports four types of upload client: ❐

FTP client, the default

❐

HTTP client

❐

Custom client

❐

Websense client

Blue Coat also supports secure FTP, HTTP, and Custom client. The Custom client can be used for special circumstances, such as working with SurfControl Reporter. Custom client is based on plain sockets. Note: You must have a socket server to use the Custom client.

The general options you enter in the Upload Client tab affect all clients. Specific options that affect individual clients are discussed in the FTP client, HTTP client, Custom client, or Websense client panes or the access-log ftp-client, https-client, customclient, or websense-client CLI commands. Only one client can be used at any one time. All four can be configured, but only the selected client is used. The SGOS software provides access logging with two types of uploads to a remote server: ❐

continuous uploading, where the device continuously streams new access log entries from the device memory to a remote server.

❐

scheduled (periodic) uploading, where the device transmits log entries on a scheduled basis. See Chapter 5: "Configuring the Upload Schedule" for more information.

The SGOS software allows you to upload either compressed access logs or plain-text access logs. The device uses the gzip format to compress access logs. Gzip-compressed files allow more log entries to be stored in the device. Advantages of using file compression include: ❐

Reduces the time and resources used to produce a log file because fewer disk writes are required for each megabyte of log-entry text.

❐

Uses less bandwidth when the device sends access logs to an upload server.

❐

Requires less disk space.

Compressed log files have the extension .log.gz. Text log files have the extension .log. Note: You cannot upload gzip access-log files for the Websense client.

21

Volume 8: Access Logging

For greater security, you can configure the SGOS software to: ❐

encrypt the access log

❐

sign the access log

Encrypting the Access Log To encrypt access log files, you must first place an external certificate on the SG appliance (see “Importing an External Certificate” on page 22). The device derives a session key from the public key in the external certificate and uses it to encrypt the log. When an access log is encrypted, two access log files are produced: an ENC file (extension .enc), which is the encrypted access log file, and a DER file (extension .der), which contains the SG appliance session key and other information. You need four things to decrypt an encrypted access log: ❐

The ENC file

❐

The DER file

❐

The external (public key) certificate

❐

The corresponding private key

For information about decrypting a log, see “Decrypting an Encrypted Access Log” on page 26. Note: The encryption feature is not available for custom or Websense clients.

Importing an External Certificate You can import an X.509 certificate into the SG appliance to use for encrypting data. To Import an external certificate: 1.

Copy the certificate onto the clipboard.

2.

Select Configuration > SSL > External Certificates.

3.

Click Import.

22

Chapter 4: Configuring the Upload Client

4.

Enter the name of the external certificate into the External Cert Name field and paste the certificate into the External Certificate field. Be sure to include the ----BEGIN CERTIFICATE---- and -----END CERTIFICATE---- statements.

5.

Click OK.

6.

Click Apply to commit the changes to the SG appliance.

Deleting an External Certificate To delete an external certificate: 1.

Select Configuration > SSL > External Certificates.

2.

Highlight the name of the external certificate to be deleted.

3.

Click Delete.

4.

Click OK in the Confirm delete dialog that appears.

5.

Click Apply to commit the changes to the SG appliance.

Digitally Signing Access Logs You can digitally sign access logs to certify that a particular SG appliance wrote and uploaded this log file. Signing is supported for both content types— text and gzip—and for both upload types—continuous and periodic. Each log file has a signature file associated with it that contains the certificate and the digital signature for verifying the log file. The signature file has the same name as the access log file but with a .sig extension; that is, filename.log.sig, if the access log is a text file, or filename.log.gzip.sig, if the access log is a gzip file.

23

Volume 8: Access Logging

Note: Signing is disabled by default.

You can digitally sign your access log files with or without encryption. If the log is both signed and encrypted, the signing operation is done first, meaning that the signature is calculated on the unencrypted version of the file. You must decrypt the log file before verifying the file. Attempting to verify an encrypted file fails. When you create a signing keyring (which must be done before you enable digital signing), keep in mind the following: ❐

The keyring must include an external certificate. (An external certificate is one for which the SG appliance does not have the private key.).

❐

The certificate purpose must be set for smime signing. If the certificate purpose is set to anything else, you cannot use the certificate for signing.

❐

Add the %c parameter in the filenames format string to identify the keyring used for signing. If encryption is enabled along with signing, the %c parameter expands to keyringName_Certname.

Note: The signing feature is not available for custom or Websense clients.

For information about verifying a log, see “Verifying a Digital Signature” on page 26. To configure the upload client: 1.

Select Configuration > Access Logging > Logs > Upload Client.

2

3b

3a 4

2. 3.

From the Log drop-down list, select the log facility to configure. The facility must exist before it displays in this list. Select and configure the client type: a.

From the Client type drop-down list, select the upload client to use. Only one client can be configured for each log facility.

b.

Click Settings to customize the upload client. For information on customizing the clients, skip to “Editing the FTP Client” on page 27, “Editing the HTTP Client” on page 28, “Editing the Custom Client” on page 29, “Editing the Custom SurfControl Client” on page 30, or “Editing the Websense Client” on page 30.

24

Chapter 4: Configuring the Upload Client

For information about testing the upload client, see Chapter 4: "Configuring the Upload Client". 4.

Configure Transmission Parameters, if applicable: a.

(Optional) To use an external certificate to encrypt the uploaded log facility, select an external certificate from the Encryption Certificate drop-down list. You must first import the external certificate to the SG appliance (see “Importing an External Certificate” on page 22). The encryption option is not available for Websense or Custom clients.

b.

(Optional) To enable the digital signature of the uploaded access log, select a keyring from the Keyring Signing drop-down list. The signing keyring, with a certificate set to smime, must already exist. A certificate set to any other purpose cannot be used for digital signatures. The digital signing option is not available for Websense or Custom clients.

c.

Select one of the Save the log file as radio buttons to determine whether the access log that is uploaded is compressed (gzip file, the default) or not (text file). Note: If you are configuring a SurfControl Custom client, select the text file radio

button. If you chose text file, you can change the Send partial buffer after n seconds field to the time you need (30 seconds is the default). This field configures the maximum time between text log packets, meaning that it forces a text upload after the specified length of time even if the internal log buffer is not full. If the buffer fills up before the time specified in this setting, the text uploads right away, and is not affected by this maximum setting. Note: If you chose gzip file, the Send partial buffer after n seconds field is not

configurable. Also, this setting is only valid for continuous uploading (see Chapter 5: "Configuring the Upload Schedule" for information about continuous uploading). d. (Optional) To manage the bandwidth for this log facility, select a bandwidth class from the Bandwidth Class drop-down list. The default setting is none, which means that bandwidth management is disabled for this log facility by default. Note: Before you can manage the bandwidth for this log facility, you must first create a bandwidth-management class. It is the log facility that is bandwidthmanaged—the upload client type does not affect this setting. Refer to Volume 5: Advanced Networking for information about enabling bandwidth management and creating and configuring the bandwidth class.

Less bandwidth slows down the upload, while more could flood the network. 5.

Click Apply to commit the changes to the SG appliance.

25

Volume 8: Access Logging

Disabling Log Uploads To disable log uploads, set the upload client-type to none. To disable an upload: 1.

Select Configuration > Access Logging > Logs > Upload Client.

2.

Select the log facility for which you want to disable an upload from the Log dropdown menu.

3.

Select NONE from the Client type drop-down menu.

4.

Click Apply to commit the changes to the SG appliance.

Decrypting an Encrypted Access Log To decrypt an encrypted access log, you must concatenate the DER and ENC files (with the DER file in front of the ENC file) and use a program such as OpenSSL for decryption. For example, use the following UNIX command and a tool such as OpenSSL to concatenate the DER and ENC files and decrypt the resulting file: cat path/filename_of_DER_file path/filename_of_ENC_file | openssl smime -decrypt -inform DER -binary -inkey path/filename_of_private_key -recip path/filename_of_external_certificate -out path/ filename_for_decrypted_log_file

You can also download a script based on the OpenSSL tool for decryption. Go to https:// download.bluecoat.com/release/SG4/files/accesslog_decrypt.zip.

Verifying a Digital Signature If the file whose digital signature you want to verify is also encrypted, you must decrypt the file prior to verifying the signature. (See “Decrypting an Encrypted Access Log” on page 26 above for more information.) You can use a program such as OpenSSL to verify the signature. For example, use the following command in OpenSSL: openssl smime -CAfile cacrt -verify -in filename.sig -content filename.log -inform DER -out logFile

where cacrt

The CA certificate used to issue the certificate in the signature file.

filename.sig

The file containing the digital signature of the log file.

filename.log

The log file generated after decryption. If the access log is a gzip file, it contains a .gz extension.

logFile

The filename that is generated after signature verification.

Editing Upload Clients Four upload clients are supported by Blue Coat: FTP, HTTP, Custom, and Websense. Each of these clients are described below. You can also create a SurfControl or SmartFilter upload client. Multiple upload clients can be configured per log facility, but only one can be enabled and used per upload.

26

Chapter 4: Configuring the Upload Client

Editing the FTP Client To edit the FTP client: 1.

Select Configuration > Access Logging > Logs > Upload Client. See Chapter 4: "Configuring the Upload Client" for configuration information.

2.

Select FTP Client from the Client type drop-down list. Click the Settings button.

3 4a

4b

4c 4d 4e 5 6 7 8

3.

Select the primary or alternate FTP server to configure from the Settings for dropdown list.

4.

Fill in the server fields, as appropriate: a.

Host: The name of the upload client host. If the Use secure connections (SSL) checkbox is selected, the hostname must match the hostname in the certificate presented by the server.

b.

Port: The default is 21; it can be changed.

c.

Path: The directory path where the access log is uploaded on the server.

d. Username: This is the username that is known on the host you are configuring. e. 5.

Change Password: Change the password on the FTP; the Change Password dialog displays; enter and confirm the new password; click OK.

Filename: The Filename field is comprised of text and/or specifiers. The default filename includes specifiers and text that indicate the log name (%f), name of the external certificate used for encryption, if any (%c), the fourth parameter of the SG appliance IP address (%l), the date and time (Month: %m, Day: %d, Hour: %H, Minute: %M, Second: %S), and the .log or .gzip.log file extension. Note: Be cautious if you change the Filename field. If an ongoing series of access logs files are produced and you do not have time-specifiers in this field, each access log file produced overwrites the old file. Also, if you use more than one external certificate to encrypt logs, include the %c specifier in the Filename field to keep track of which external certificate was used to encrypt the uploaded log file.

6.

Secure Connections: If you use FTPS, select the Use secure connections (SSL)

checkbox. The remote FTP server must support FTPS. 7.

Local Time: If you want the upload to reflect the local time it was uploaded instead of Universal Time Coordinates (UTC), select Local Time.

27

Volume 8: Access Logging

8.

Use PASV: With Use PASV selected (the default), the SG appliance connects to the FTP server. With Use PASV de-selected, the FTP server uses the PORT command to connect to the SG appliance.

9.

Click OK.

10. Click Apply to commit the changes to the SG appliance.

Editing the HTTP Client Access log uploads done through an HTTP/HTTPS client use the HTTP PUT method. The destination HTTP server (where the access logs are being uploaded) must support this method. Microsoft's IIS allows the server to be directly configured for write (PUT/ DELETE) access. Other servers, such as Apache, require installing a new module for the PUT method for access log client uploads. You can create either an HTTP or an HTTPS upload client through the HTTP Client dialog. (Create an HTTPS client by selecting Use secure connections (SSL).) Note: To create an HTTPS client, you must also import the appropriate CA Certificate. For information, refer to Volume 2: Proxies and Proxy Services.

To edit the HTTP client: 1.

Select Configuration > Access Logging > Logs > Upload Client. See Chapter 4: "Configuring the Upload Client" on page 21 for configuration information.

2.

Select HTTP Client from the Client type drop-down list. Click Settings.

3 4a

4b

4c 4d 4e 5 6 7

3.

From the Settings for drop-down list, select the primary or alternate HTTP server to configure.

4.

Fill in the server fields, as appropriate: a.

Host: The name of the upload host. If Use secure connections (SSL) is selected, the hostname must match the hostname in the certificate presented by the server.

b.

Port: The default is 80, but you can change it. Note: For HTTPS, change the port to 443.

28

Chapter 4: Configuring the Upload Client

c.

Path: The directory path where the access log facility is uploaded on the server.

d. Username: This is the username that is known on the host you are configuring. e.

Change Password: Change the password on the HTTP host; the Change

Password dialog displays; enter and confirm the new password and click OK. 5.

Filename: The Filename field is comprised of text and/or specifiers. The default filename includes specifiers and text that indicate the log name (%f), name of the external certificate used for encryption, if any (%c), the fourth parameter of the SG appliance IP address (%l), the date and time (Month: %m, Day: %d, Hour: %H, Minute: %M, Second: %S), and the .log or .gzip.log file extension. Note: Be cautious if you change the Filename field. If an ongoing series of access log files are produced and you do not have time-specifiers in this field, each access log file produced overwrites the old file. Also, if you use more than one external certificate to encrypt logs, include the %c specifier in the Filename field to keep track of which external certificate can decrypt the uploaded log file.

6.

Local Time: If you want the upload to reflect the local time it was uploaded instead of Universal Time Coordinate (UTC), select Local Time.

7.

Use secure connections (SSL): Select this to create an HTTPS client. To create an HTTPS client, you must also create a keypair, import or create a certificate, and, if necessary, associate the keypair and certificate (called a keyring), with the SSL-client.

8.

Click OK.

9.

Click Apply to commit the changes to the SG appliance.

Editing the Custom Client To edit the custom client: 1.

Select Configuration > Access Logging > Logs > Upload Client. See Chapter 4: "Configuring the Upload Client" for configuration information.

2.

Select Custom Client from the Client type drop-down list. Click the Settings button.

3 4a

4b

4c

3.

From the Settings for drop-down list, select to configure the primary or alternate custom server.

29

Volume 8: Access Logging

4.

Fill in the server fields, as appropriate: a.

Host: Enter the hostname of the upload destination. If Use secure connections (SSL) is selected, the hostname must match the hostname in the certificate

presented by the server. b.

Port: The default is 69; it can be changed.

c.

Use secure connections (SSL): Select this if you are using secure connections.

5.

Click OK.

6.

Click Apply to commit the changes to the SG appliance.

Editing the Custom SurfControl Client You can use the Custom Client to create an upload client that uploads information to SurfControl Reporter. Before you begin, verify that: ❐

You have created a log (see Chapter 3: "Creating and Editing An Access Log Facility").

❐

You have associated the SurfControl log format with the log you created (see Chapter 3: "Creating and Editing An Access Log Facility").

To edit the SurfControl client: 1.

Select Configuration > Access Logging > Logs > Upload Client. See Chapter 4: "Configuring the Upload Client" for configuration information.

2.

From the Log drop-down list, select the SurfControl log that you associated with the SurfControl log format.

3.

Verify the Save the log file as radio button is set to text file, not gzip file.

4.

Select Custom Client from the Client type drop-down list. Note: For specific information on managing upload clients, see “Editing the Custom

Client” on page 29. 5.

Click the Settings button for that client.

6.

Customize the upload client for SurfControl Reporter. a.

Enter the hostname, path, and username, if necessary, for the SurfControl Reporter server.

b.

Make sure the filename extension is .tmp and not .gzip or .log. SurfControl only recognizes files with a .tmp extension.

c.

If your SurfControl server supports SSL, select the Use secure connections (SSL) checkbox.

7.

Click OK.

8.

Click Apply to commit the changes to the SG appliance.

Editing the Websense Client Before you begin, make sure you have created a Websense log using the Websense log format and configured the log to your environment. See Chapter 3: "Creating and Editing An Access Log Facility".

30

Chapter 4: Configuring the Upload Client

Note: You cannot upload gzip access log files with the Websense client.

To edit the Websense client: 1.

Select Configuration > Access Logging > Logs > Upload Client. See Chapter 4: "Configuring the Upload Client" for configuration information.

2.

Select the Websense Client from the Client type drop-down list. Click Settings.

3.

From the Settings for drop-down list, select the primary or alternate server you want to configure.

4.

Fill in the fields as appropriate: a.

Host: Enter the hostname of the primary Websense Server.

b.

Port: The default is 55805, but you can change it if the Websense Server is

using a different port. 5.

Repeat for the Alternate Websense Server.

6.

Click OK.

7.

Click Apply to commit the changes to the SG appliance.

31

Volume 8: Access Logging

32

Chapter 5: Configuring the Upload Schedule

The Upload Schedule allows you to configure the frequency of the access logging upload to a remote server, the time between connection attempts, the time between keep-alive packets, the time at which the access log is uploaded, and the protocol that is used. You can specify either periodic uploading or continuous uploading. Both periodic and continuous uploading can send log information from an SG appliance farm to a single log analysis tool. This allows you to treat multiple appliances as a single entity and to review combined information from a single log file or series of related log files. With periodic uploading, the SGOS software transmits log entries on a scheduled basis (for example, once daily or at specified intervals) as entries are batched, saved to disk, and uploaded to a remote server. Note: When you configure a log for continuous uploading, it continues to upload until you stop it. To stop continuous uploading, switch to periodic uploading temporarily. This is sometimes required for gzip or encrypted files, which must stop uploading before you can view them.

With continuous uploading, the SG appliance continuously streams new access log entries from the device memory to a remote server. Here, streaming refers to the realtime transmission of access log information. The SGOS software transmits access log entries using the specified client, such as FTP client. A keep-alive is sent to keep the data connection open. Continuous uploading allows you to view the latest logging information almost immediately, send log information to a log analysis tool for real-time processing and reporting, maintain the SG appliance performance by sending log information to a remote server (avoiding disk writes), and save device disk space by saving log information on the remote server. If the remote server is unavailable to receive continuous upload log entries, the SGOS software saves the log information on the device disk. When the remote server is available again, the appliance resumes continuous uploading. Note: If you do not need to analyze the upload entries in real time, use periodic

uploading because it is more reliable than continuous uploading. If there is a problem configuring continuous uploading to Microsoft Internet Information Server (IIS), use periodic uploading instead. To configure the upload schedule: 1.

Select Configuration > Access Logging > Logs > Upload Schedule.

33

Volume 8: Access Logging

2

3a 3b 3c

4a

5

4b

2.

From the Log drop-down list, select the log type.

3.

Select the Upload Type: a.

Select continuously (stream access log entries to a remote server) or periodically (transmit on a scheduled basis).

b.

To change the time between connection attempts, enter the new time (in seconds) in the Wait between connect attempts field.

c.

(Only accessible if you are updating continuously) To change the time between keep-alive packets, enter the new time (in seconds) in the Time between keep-alive log packets field. Keepalives maintain the connection during low periods of system usage. When no logging information is being uploaded, the SGOS software sends a keep-alive packet to the remote server at the interval you specify, from 1 to 65535 seconds. If you set this to 0 (zero), you effectively disable the connection during low usage periods. The next time that access log information needs to be uploaded, the SG appliance automatically reestablishes the connection.

4.

5.

Determine when logs are uploaded or rotated: a.

(Optional) From the Daily at drop-down list, specify the time of day to log update (for periodic uploads) or rotate (for continuous uploads).

b.

(Optional) To have the log uploaded or rotated on a daily basis, select Every and enter the time between uploads.

Rotate or Upload Now:

•

Continuous Upload: Log rotation helps prevent logs from growing excessively large. Especially with a busy site, logs can grow quickly and become too big for easy analysis. With log rotation, the SGOS software periodically creates a new log file, and archives the older one without disturbing the current log file.

•

Periodic Upload: You can upload the access logs now or you can cancel any access-log upload currently in progress (if you are doing periodic uploads). You can rotate the access logs now (if you are doing continuous uploads). These actions do not affect the next scheduled upload time.

•

Cancel upload (for periodic uploads) allows you to stop repeated upload attempts

if the Web server becomes unreachable while an upload is in progress. Clicking this sets log uploading back to idle if the log is waiting to retry the upload. If the log file is in the process of uploading, it takes time for it to take effect. 6.

Click Apply to commit the changes to the SG appliance.

34

Chapter 5: Configuring the Upload Schedule

Testing Access Log Uploading For the duration of the test, configure the event log to use the verbose event level (refer to Volume 9: Managing the Blue Coat SG Appliance). This logs more complete log information. After you test uploading, you can check the event log for the test upload event and determine whether any errors occurred (go to Statistics > Event Logging). You cannot check the event log. To test access log uploading: You can do a test access log upload. Before you begin, make sure you have configured the upload client completely. 1.

Select Configuration > Access Logging > Logs > Upload Client.

2.

Click Test Upload.

3.

Click OK in the Test upload dialog.

4.

Check the event log for upload results: go to Statistics > Event Logging.

Viewing Access-Log Statistics Access-log statistics can be viewed from the Management Console or the CLI, although not all statistics you can view in the Management Console are available in the CLI. You can also view some access log statistics by navigating to Statistics > Advanced and clicking Access Log. Statistics you can view from Statistics > Advanced include: ❐

Show list of all logs: The access log manages multiple log objects internally. These are put together as one logical access log file when the file is uploaded.

The show list shows the available internal log objects for easy access. To download part of the access log instead of the whole log file, click on the individual log object shown in the list. The latest log object can be identified by its timestamp. Note: If you have multiple access logs, each access log has its own list of objects. ❐

Show access log statistics: The statistics of an individual access log is shown.

❐

Show statistics of all logs: The statistics of all the access logs on the system are

displayed in a single list. ❐

Show last N bytes in the log: The last N bytes in the log are shown.

❐

Show last part of log every time it changes: A stream of the latest log entries is shown

on the page as they are written in the system. ❐

Show access log tail with optional refresh time: A refresh from the browser displays the

latest log entries. ❐ ❐

Show access log objects: The statistics of individual access log objects are displayed. Show all access log objects: The statistics of all access log object are displayed in a

single list.

Viewing the Access Log Tail This option is not available through the CLI.

35

Volume 8: Access Logging To display the access log tail: 1.

Select Statistics > Access Logging > Log Tail.

2.

From the Log drop-down list, select the log you want to view.

3.

Click Start Tail to display the access log tail. The SG appliance displays a maximum of 500 lines. Entries that pre-date these 500 lines are not displayed.

4.

Click Stop Tail to stop the display or Clear Tail to clear the display.

Viewing the Log File Size The Log Size tab displays current log statistics: ❐

Whether the log is being uploaded (Table 5-1 describes upload statuses)

❐

The current size of all access log objects

❐

Disk space usage

❐

Last modified time

❐

Estimated size of the access log file, once uploaded

Table 5-1.

Log Writing Status Description

Status

Description

active

Log writing is active.

active - early upload

The early upload threshold has been reached.

disabled

An administrator has disabled logging.

idle

Log writing is idle.

initializing

The system is initializing.

shutdown

The system is shutting down.

36

Chapter 5: Configuring the Upload Schedule

Table 5-1.

Log Writing Status Description (Continued)

stopped

The access log is full. The maximum log size has been reached.

unknown

A system error has occurred.

Estimated compressed size of the uploaded access log and SG appliance access log size might differ during uploading. This occurs because new entries are created during the log upload. To view the access log size statistic: 1.

Select Statistics > Access Logging > Log Size.

2.

From the Log drop-down list, select a log to view.

Viewing Access Logging Status The SGOS software displays the current access logging status on the Management Console. This includes separate status information about: ❐

The writing of access log information to disk

❐

The client the SG appliance uses to upload access log information to the remote server

To view access logging upload status: 1.

Select Statistics > Access Logging > Upload Status.

2.

Under Status of Last Upload, check the appropriate status information displayed in the Upload client field.

3.

Check the other status information. For information about the status, see the table below.

37

Volume 8: Access Logging

Table 5-2. Upload Status Information Status

Description

Connect time

The last time a client connection was made or attempted.

Remote filename

The most recent upload filename. If an access log was encrypted, only the encrypted access log file (the ENC file) displays.

Remote size

The current size of the upload file. If an access log was encrypted, only the encrypted access log file size (the ENC file) displays. The private key file (the DER file) varies, but is usually about 1 Kb.

Maximum bandwidth

The maximum bandwidth used in the current or last connection.

Current bandwidth

The bandwidth used in the last second (available only if currently connected).

Final result

The result of the last upload attempt (success or failure). This is available only if not connected.

Viewing Access-Log Statistics In the CLI, you can view all access log statistics at once, or you can view the statistics of a specific access log. For details of the meaning of these statistics, see “Viewing the Log File Size” on page 36 and “Viewing Access Logging Status” on page 37. To view access logging statistics: 1.

To view the statistics for all access logs at once, enter the following command: SGOS# show access-log statistics

2.

To view the statistics for a specific access log, enter the following command: SGOS# show access-log statistics log_name

The statistics for the access log Main are displayed below as an example: SGOS#(config) show access-log statistics main Statistics: Access Log (main) Statistics: Log Manager Version 3 Log entry lifetime counter: 0 System Status: Log manager: enabled and running Upload client: disabled Log writer: idle Log reader: idle Log Information: Current log size: 0 bytes Early upload threshold: 1736 MB Maximum log size: 2170 MB Max size policy: stop logging Bytes in write buffer : 0 Tail sockets in use : 0 Modified time: 2004-08-26 22:10:49+00:00UTC Next Upload: Client type: ftp Next attempt: uploading disabled Connect type: daily upload Connect reason: regular upload

38

Chapter 5: Configuring the Upload Schedule

Estimated upload size: compressed: uncompressed: Upload format: Last Upload Attempt: Time: Maximum bandwidth: Result: Current/Last Upload File: Remote filename: Remote size: Using Access Logging with Policy Rules

nothing to upload nothing to upload gzip never uploaded 0.00 KB/sec failure Never rotated 0 bytes

After configuration is complete, you must create rules to manage the access logs you set up. You can create rules through the Visual Policy Manager module of the Management Console, or you can use Content Policy Language (CPL) directly (refer to Volume 10: Content Policy Language Guide). Actions you can do to manage access logging: ❐

Reset logging to its default

❐

Disable all logging

❐

Add logging to a log file

❐

Disable logging to a log file

❐

Override specific access-log fields

You can also set the list of logs to be used, but you must use CPL to create this action. It is not available through VPM. The first two actions—reset logging to its default and disable all logging—are referred to as constant actions, just like the allow/deny actions. Select only one per rule. All of the actions are allowed in all layers. If you use VPM, the access-logging actions display in the VPM policy; if you use CPL, you can put the actions into any file, but Blue Coat recommends you use the Local file.

Example: Using VPM to Prevent Logging of Entries Matching a Source IP Complete the following steps to prevent a source IP address from being logged. To prevent a source IP address from being logged: 1.

Create a Web Access Layer: a.

Select Configuration > Policy > Visual Policy Manager; click Launch.

39

Volume 8: Access Logging

2.

b.

In the VPM, select Policy > Add Web Access Layer.

c.

Enter a layer name into the dialog that appears and click OK.

Add a Source object:

2a

2b

3.

a.

Right click on the item in the Source column; select Set.

b.

Click New; select Client IP Address/Subnet.

Enter an IP address or Subnet Mask in the dialog that appears and click Add; click Close (or add additional addresses and then click Close); click OK.

4.

5.

Add an Action object to this rule: a.

Right-click on the item in the Action column; select Set.

b.

Click New in the Set Action Object dialog that appears; select Modify Access Logging.

c.

To disable a particular log, click Disable logging to and select that log from the drop-down list; to disable all access logging, click Disable all access logging.

Click OK; click OK again; close the VPM window and click Yes in the dialog to save your changes.

40

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

41

Volume 8: Access Logging

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

42

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

43

Volume 8: Access Logging

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

44

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

45

Volume 8: Access Logging

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

46

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

47

Volume 8: Access Logging

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

48

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

49

Volume 8: Access Logging

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

50

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

51

Volume 8: Access Logging

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

52

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

53

Volume 8: Access Logging

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

54

Appendix A: Access Log Formats

The SG appliance can create access logs in one of the following formats: ❐

“Custom or W3C ELFF Format”

❐

“SQUID-Compatible Format” on page 58

❐

“NCSA Common Access Log Format” on page 59

ELFF is a log format defined by the W3C that contains information about Windows Media and RealProxy logs. The SG appliance can create access logs with any one of six formats. Four of the six are reserved formats and cannot be configured. However, you can create additional logs using custom or ELFF format strings. When using an ELFF or custom format, a blank field is represented by a dash character. When using the SQUID or NCSA log format, a blank field is represented according to the standard of the format.

Custom or W3C ELFF Format The W3C Extended Log File Format (ELFF) is a subset of the Blue Coat Systems format. The ELFF format is specified as a series of space delimited fields. Each field is described using a text string. The types of fields are described in Table B-1. Table B-1. Field Types Field Type

Description

Identifier

A type unrelated to a specific party, such as date and time.

prefix-identifier

Describes information related to a party or a transfer, such as c-ip (client’s IP) or sc-bytes (how many bytes were sent from the server to the client)

prefix (header)

Describes a header data field. The valid prefixes are: c = Client s = Server r = Remote sr = Server to Remote

cs = Client to Server sc = Server to Client rs = Remote to Server

ELFF formats are created by selecting a corresponding custom log format using the table below. Unlike the Blue Coat custom format, ELFF does not support character strings and require a space between fields. Selecting the ELFF format does the following: ❐

Puts one or more W3C headers into the log file. Each header contains the following lines: #Software: SGOS x.x.x #Version: 1.0 #Date: 2002-06-06 12:12:34 #Fields: date time cs-ip…

55

Volume 8: Access Logging

❐

Changes all spaces within fields to + or %20. The ELFF standard requires that spaces only be present between fields.

ELFF formats are described in Table B-2. Table B-2. Blue Coat Custom Format and Extended Log File Format Blue Coat Custom Format

Extended Log File Format

Description

space character

N/A

Multiple consecutive spaces are compressed to a single space.

%

-

Denotes an expansion field.

%%

-

Denotes '%' character.

%a

c-ip

IP address of the client

%b

sc-bytes

Number of bytes sent from appliance to client

%c

rs(Content-Type)

Response header: Content-Type

%d

s-supplier-name

Hostname of the upstream host (not available for a cache hit)

%e

time-taken

Time taken (in milliseconds) to process the request

%f

sc-filter-category

Content filtering category of the request URL

%g

timestamp

Unix type timestamp

%h

c-dns

Hostname of the client (uses the client's IP address to avoid reverse DNS)

%i

cs-uri

The 'log' URL.

%j

-

[Not used.]

%k

-

[Not used.]

%l

x-bluecoat-specialempty

Resolves to an empty string

%m

cs-method

Request method used from client to appliance

%n

-

[Not used.]

%o

-

[Not used.]

%p

r-port

Port from the outbound server URL

%q

-

[Not used.]

%r

cs-request-line

First line of the client's request

%s

sc-status

Protocol status code from appliance to client

%t

gmttime

GMT date and time of the user request in format: [DD/MM/YYYY:hh:mm:ss GMT]

%u

cs-user

Qualified username for NTLM. Relative username for other protocols

%v

cs-host

Hostname from the client's request URL. If URL rewrite policies are used, this field's value is derived from the 'log' URL

%w

s-action

What type of action did the Appliance take to process this request.

%x

date

GMT Date in YYYY-MM-DD format

%y

time

GMT time in HH:MM:SS format

%z

s-icap-status

ICAP response status

56

Appendix A: Access Log Formats

Table B-2. Blue Coat Custom Format and Extended Log File Format (Continued) Blue Coat Custom Format

Extended Log File Format

Description

%A

cs(User-Agent)

Request header: User-Agent

%B

cs-bytes

Number of bytes sent from client to appliance

%C

cs(Cookie)

Request header: Cookie

%D

s-supplier-ip

IP address used to contact the upstream host (not available for a cache hit)

%E

-

[Not used.]

%F

-

[Not used.]

%G

-

[Not used.]

%H

s-hierarchy

How and where the object was retrieved in the cache hierarchy.

%I

s-ip

IP address of the appliance on which the client established its connection

%J

-

[Not used.]

%K

-

[Not used.]

%L

localtime

Local date and time of the user request in format: [DD/MMM/YYYY:hh:mm:ss +nnnn]

%M

-

[Not used.]

%N

s-computername

Configured name of the appliance

%O

-

[Not used.]

%P

s-port

Port of the appliance on which the client established its connection

%Q

cs-uri-query

Query from the 'log' URL.

%R

cs(Referer)

Request header: Referer

%S

s-sitename

The service type used to process the transaction

%T

duration

Time taken (in seconds) to process the request

%U

cs-uri-path

Path from the 'log' URL. Does not include query.

%V

cs-version

Protocol and version from the client's request, e.g. HTTP/1.1

%W

sc-filter-result

Content filtering result: Denied, Proxied or Observed

%X

cs(X-ForwardedFor)

Request header: X-Forwarded-For

%Y

-

[Not used.]

%Z

s-icap-info

ICAP response information

Example Access Log Formats Squid log format: %g %e %a %w/%s %b %m %i %u %H/%d %c NCSA common log format: %h %l %u %t “%r” %s %b NCSA extended log format: %h %l %u %L "%r" %s %b "%R" "%A" Microsoft IIS format: %a, -, %x, %y, %S, %N, %I, %e, %b, %B, %s, 0, %m, %U, -

57

Volume 8: Access Logging

The Blue Coat custom format allows any combination of characters and format fields. Multiple spaces are compressed to a single space in the actual access log. You can also enter a string, such as My default is %d. The SG appliance goes through such strings and finds the relevant information. In this case, that information is %d.

SQUID-Compatible Format The SQUID-compatible format contains one line for each request. For SQUID-1.1, the format is: time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type

For SQUID-2, the columns stay the same, though the content within might change a little.

Action Field Values Table B-3 describes the possible values for the action field. Table B-3. Action Field Values Value

Description

ACCELERATED

(SOCKS only) The request was handed to the appropriate protocol agent for handling.

ALLOWED

An FTP method (other than the data transfer method) is successful.

DENIED

Policy denies a method.

FAILED

An error or failure occurred.

LICENSE_EXPIRED

(SOCKS only) The request could not be handled because the associated license has expired.

TUNNELED

Successful data transfer operation.

TCP_

Refers to requests on the HTTP port.

TCP_AUTH_HIT

The requested object requires upstream authentication, and was served from the cache.

TCP_AUTH_MISS

The requested object requires upstream authentication, and was not served from the cache. This is part of CAD (Cached Authenticated Data).

TCP_AUTH_REDIREC T

The client was redirected to another URL for authentication.

TCP_CLIENT_REFRE SH

The client forces a revalidation with the origin server with a Pragma: no-cache. If the server returns 304 Not Modified, this appears in the Statistics:Efficiency file as In Cache, verified Fresh.

TCP_DENIED

Access to the requested object was denied by a filter.

TCP_ERR_MISS

An error occurred while retrieving the object from the origin server.

TCP_HIT

A valid copy of the requested object was in the cache.

TCP_LOOP

The current connection is dropped because the upstream connection would result in a looped connection.

58

Appendix A: Access Log Formats

Table B-3. Action Field Values (Continued) Value

Description

TCP_MEM_HIT

The requested object was, in its entirety, in RAM.

TCP_MISS

The requested object was not in the cache.

TCP_NC_MISS

The object returned from the origin server was non-cacheable.

TCP_PARTIAL_MISS

The object is in the cache, but retrieval from the origin server is in progress.

TCP_POLICY_REDIR ECT

The client was redirected to another URL due to policy.

TCP_REFRESH_HIT

A GIMS request to the server was forced and the response was 304 Not Modified, this appears in the Statistics:Efficiency file as In Cache, verified Fresh.

TCP_REFRESH_MISS

A GIMS request to the server was forced and new content was returned.

TCP_RESCAN_HIT

The requested object was found in the cache but was rescanned because the virus-scanner-tag-id in the object was different from the current scanner tag.

TCP_SPLASHED

The user was redirected to a splash page.

TCP_SWAPFAIL

The object was believed to be in the cache, but could not be accessed.

TCP_TUNNELED

The CONNECT method was used to tunnel this request (generally proxied HTTPS).

UDP_

Refers to requests on the ICP port (3130).

UDP_DENIED

Access was denied for this request.

UDP_HIT

A valid copy of the requested object was in the cache. This value is also used with ICP queries.

UDP_INVALID

The ICP request was corrupt, short, or otherwise unintelligible.

UDP_MISS

The requested object was not in the cache. This value is also used with ICP queries.

UDP_MISS_NOFETCH

An ICP request was made to this cache for an object not in the cache. The requestor was informed that it could not use this cache as a parent to retrieve the object. (This is not supported at this time.)

UDP_OBJ

An ICP request was made to this cache for an object that was in cache, and the object was returned through UDP. (This is not supported at this time. This functionality is deprecated in the current ICP specification.)

NCSA Common Access Log Format The common log format contains one line for each request. The format of each log entry is shown below: remotehost rfc931 authuser [date] “request” status bytes

Each field is described in Table B-4.

59

Volume 8: Access Logging

Table B-4. Log Entry Fields Field Name

Description

remotehost

DNS hostname or IP address of remote server.

rfc931

The remote log name of the user. This field is always —.

authuser

The username as which the user has authenticated himself.

[date]

Date and time of the request.

“request”

The request line exactly as it came from the client.

status

The HTTP status code returned to the client.

bytes

The content length of the document transferred.

Access Log Filename Formats Table B-5 details the specifiers for the access log upload filenames. Table B-5. Specifies for Access Log Upload Filenames Specifier

Description

%%

Percent sign.

%a

Abbreviated weekday name.

%A

Full weekday name.

%b

Abbreviated month name.

%B

Full month name.

%c

The certificate name used for encrypting the log file (expands to nothing in nonencrypted case).

%C

The SG appliance name.

%d

Day of month as decimal number (01 – 31).

%f

The log name.

%H

Hour in 24-hour format (00 – 23).

%i

First IP address of the SG appliance, displayed in x_x_x_x format, with leading zeros removed.

%I

Hour in 12-hour format (01 – 12).

%j

Day of year as decimal number (001 – 366).

%l

The fourth part of the SG appliance’s IP address, using three digits (001.002.003.004)

%m

Month as decimal number (01 – 12).

%M

Minute as decimal number (00 – 59).

%p

Current locale’s A.M./P.M. indicator for 12-hour clock.

60

Appendix A: Access Log Formats

Table B-5. Specifies for Access Log Upload Filenames (Continued) %S

Second as decimal number (00 – 59).

%U

Week of year as decimal number, with Sunday as first day of week (00 – 53).

%w

Weekday as decimal number (0 – 6; Sunday is 0).

%W

Week of year as decimal number, with Monday as first day of week (00 – 53).

%y

Year without century, as decimal number (00 – 99).

%Y

Year with century, as decimal number.

%z, %Z

Time-zone name or abbreviation; no characters if time zone is unknown.

Fields Available for Creating Access Log Formats The following table lists all fields available for creating access log formats. When creating an ELFF format, you must use the values from the ELFF column. When creating a custom format, you can use values from the ELFF, CPL, or custom column. Table B-6. Access Log Formats ELFF

CPL

Custom

Description

Category: bytes cs-bodylength

cs-bytes

Number of bytes in the body (excludes header) sent from client to appliance %B

Number of bytes sent from client to appliance

cs-headerlength

Number of bytes in the header sent from client to appliance

rs-bodylength

Number of bytes in the body (excludes header) sent from upstream host to appliance

rs-bytes

Number of bytes sent from upstream host to appliance

rs-headerlength

Number of bytes in the header sent from upstream host to appliance

sc-bodylength

Number of bytes in the body (excludes header) sent from appliance to client

sc-bytes

%b

Number of bytes sent from appliance to client

sc-headerlength

Number of bytes in the header sent from appliance to client

sr-bodylength

Number of bytes in the body (excludes header) sent from appliance to upstream host

sr-bytes

Number of bytes sent from appliance to upstream host

sr-headerlength

Number of bytes in the header sent from appliance to upstream host

61

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

Category: cifs x-cifs-byteswritten

Total number of bytes written to the associated resource

x-cifs-client-bytesread

Total number of bytes read by CIFS client from the associated resource

x-cifs-client-readoperations

Total number of read operations issued by the CIFS client for the associated resource

x-cifs-client-otheroperations

Total number of non read/write operations issued by the CIFS client for the associated resource

x-cifs-client-writeoperations

Total number of write operations issued by the CIFS client for the associated resource

x-cifs-dos-errorclass

DOS error class generated by server, in hexadecimal

x-cifs-dos-errorcode

DOS error code generated by server, in hexadecimal

x-cifs-error-code

Error code generated by server

x-cifs-fid

ID representing a CIFS resource

x-cifs-file-size

Size in bytes of CIFS resource

x-cifs-file-type

Type of CIFS resource

x-cifs-method

The method associated with the CIFS request

x-cifs-nt-errorcode

NT error code generated by server, in hexadecimal

x-cifs-orig-path

Original path name of resource to be renamed

x-cifs-orig-uncpath

UNC path of original path name of resource to be renamed

x-cifs-path

CIFS resource name as specified in the UNC path

x-cifs-server

CIFS server as specified in the UNC path

x-cifs-serverbytes-read

Total number of bytes read by CIFS server from the associated resource

x-cifs-serveroperations

Total number of operations issued to the CIFS server for the associated resource

x-cifs-share

CIFS share name as specified in the UNC path

x-cifs-tid

ID representing instance of an authenticated connection to server resource

x-cifs-uid

ID representing an authenticated user instance

62

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

x-cifs-unc-path

Description CIFS path of form \\\\server\\share\\path where path may be empty

Category: connection cs-ip

proxy.address

IP address of the destination of the client's connection

c-connect-type

The type of connection made by the client to the appliance -'Transparent' or 'Explicit'

c-dns

%h

x-cs-dns

client.host

c-ip

client.address

c-port

Hostname of the client (uses the client's IP address to avoid reverse DNS) The hostname of the client obtained through reverse DNS.

%a

IP address of the client Source port used by the client

x-cs-netbioscomputer-name

netbios.computer-name

The NetBIOS name of the computer. This is an empty string if the query fails or the name is not reported. When using the $(netbios.*) substitutions to generate the username, the client machines must react to a NetBIOS over TCP/IP node status query.

x-cs-netbioscomputer-domain

netbios.computer-domain

The name of the domain to which the computer belongs. This is an empty string if the query fails or the name is not reported. When using the $(netbios.*) substitutions to generate the username, the client machines must react to a NetBIOS over TCP/IP node status query.

x-cs-netbiosmessengerusername

netbios.messengerusername

The name of the logged-in user. This is an empty string if the query fails or the name is not reported. It is also empty there is more than one logged-in user. When using the $(netbios.*) substitutions to generate the username, the client machines must react to a NetBIOS over TCP/IP node status query.

x-cs-netbiosmessengerusernames

netbios.messengerusernames

A comma-separated list of the all the messenger usernames reported by the target computer. This is an empty string if the query fails, or no names are reported. When using the $(netbios.*) substitutions to generate the username, the client machines must react to a NetBIOS over TCP/IP node status query.

63

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-cs-sessionusername

session.username

The username associated with this session as reported by RADIUS accounting. This is an empty string if no session is known.

x-cs-identusername

ident.username

The username associated with this session as returned from an ident query. This is an empty string if no session is known.

x-cs-connectionnegotiated-cipher

client.connection. negotiated_cipher

OpenSSL cipher suite negotiated for the client connection

x-cs-connectionnegotiated-cipherstrength

client.connection. negotiated_cipher.strength

Strength of the OpenSSL cipher suite negotiated for the client connection

x-cs-connectionnegotiated-ciphersize x-cs-connectionnegotiated-sslversion

Ciphersize of the OpenSSL cipher suite negotiated for the client connection client.connection. negotiated_ssl_version

Version of the SSL protocol negotiated for the client connection

r-dns

Hostname from the outbound server URL

r-ip

IP address from the outbound server URL

r-port

%p

Port from the outbound server URL

r-supplier-dns

Hostname of the upstream host (not available for a cache hit)

r-supplier-ip

IP address used to contact the upstream host (not available for a cache hit)

r-supplier-port

Port used to contact the upstream host (not available for a cache hit)

sc-adapter

proxy.card

Adapter number of the client's connection to the Appliance

sc-connection

Unique identifier of the client's connection (i.e. SOCKET)

x-bluecoat-server- server_connection.socket_e connection-socket- rrno errno

Error message associated with a failed attempt to connect to an upstream host

s-computername

proxy.name

%N

Configured name of the appliance

s-connect-type

Upstream connection type (Direct, SOCKS gateway, etc.)

s-dns

Hostname of the appliance (uses the primary IP address to avoid reverse DNS)

s-ip

%I

IP address of the appliance on which the client established its connection

64

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF s-port

CPL

Custom

Description

proxy.port

%P

Port of the appliance on which the client established its connection

%S

The service type used to process the transaction

s-sitename x-service-name

service.name

The name of the service that handled the transaction

x-module-name

module_name

The SGOS module that is handling the transaction

s-supplier-ip

%D

IP address used to contact the upstream host (not available for a cache hit)

s-supplier-name

%d

Hostname of the upstream host (not available for a cache hit)

x-bluecoattransaction-id

transaction.id

Unique per-request identifier generated by the appliance (note: this value is not unique across multiple appliances)

x-bluecoatappliance-name

appliance.name

Configured name of the appliance

x-bluecoatapplianceprimary-address

appliance.primary_address

Primary IP address of the appliance

x-bluecoat-proxyprimary-address

proxy.primary_address

Primary IP address of the appliance

x-bluecoatapplianceidentifier

appliance.identifier

Compact identifier of the appliance

x-applianceserial-number

appliance.serial_number

The serial number of the appliance

x-appliance-mccertificatefingerprint

appliance.mc_certificate_ fingerprint

The fingerprint of the management console certificate

x-applianceproduct-name

appliance.product_name

The product name of the appliance -- e.g. Blue Coat SG4xx

x-applianceproduct-tag

appliance.product_tag

The product tag of the appliance -e.g. SG4xx

x-appliance-fullversion

appliance.full_version

The full version of the SGOS software

x-appliance-firstmac-address

appliance.first_mac_ address

The MAC address of the first installed adapter

x-client-address

IP address of the client

x-clientconnection-bytes

Total number of bytes send to and received from the client

x-client-ip

IP address of the client

x-serverconnection-bytes

Total number of bytes send to and received from the server

65

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

x-server-adnconnection-bytes

Custom

Description Total number of compressed ADN bytes send to and received from the server

x-rs-connectionnegotiated-cipher

server.connection.negotiate d_cipher

OpenSSL cipher suite negotiated for the client connection

x-rs-connectionnegotiated-cipherstrength

server.connection.negotiate d_cipher.strength

Strength of the OpenSSL cipher suite negotiated for the server connection

x-rs-connectionnegotiated-ciphersize

Ciphersize of the OpenSSL cipher suite negotiated for the server connection

x-rs-connectionnegotiated-sslversion

server.connection.negotiate d_ssl_version

Version of the SSL protocol negotiated for the server connection

x-cs-connectiondscp

client.connection.dscp

DSCP client inbound value

x-rs-connectiondscp

server.connection.dscp

DSCP server inbound value

x-sc-connectiondscp-decision

DSCP client outbound value

x-sr-connectiondscp-decision

DSCP server outbound value

Category: dns x-dns-cs-transport

dns.client_transport

The transport protocol used by the client connection in a DNS query

x-dns-cs-address

dns.request.address

The address queried in a reverse DNS lookup

x-dns-cs-dns

dns.request.name

The hostname queried in a forward DNS lookup

x-dns-cs-opcode

dns.request.opcode

The DNS OPCODE used in the DNS query

x-dns-cs-qtype

dns.request.type

The DNS QTYPE used in the DNS query

x-dns-cs-qclass

dns.request.class

The DNS QCLASS used in the DNS query

x-dns-rs-rcode

dns.response.code

The DNS RCODE in the response from upstream

x-dns-rs-a-records

dns.response.a

The DNS A RRs in the response from upstream

x-dns-rs-cnamerecords

dns.response.cname

The DNS CNAME RRs in the response from upstream

x-dns-rs-ptrrecords

dns.response.ptr

The DNS PTR RRs in the response from upstream

66

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

Category: im x-im-buddy-id

Instant messaging buddy ID

x-im-buddy-name

Instant messaging buddy display name

x-im-buddy-state

Instant messaging buddy state

x-im-chat-roomid

Instant messaging identifier of the chat room in use

x-im-chat-roommembers

The list of chat room member Ids

x-im-chat-roomtype

The chat room type, one of 'public' or 'public', and possibly 'invite_only', 'voice' and/or 'conference'

x-im-client-info

The instant messaging client information

x-im-user-agent

im.user_agent

The instant messaging user agent string

x-im-file-path

Path of the file associated with an instant message

x-im-file-size

Size of the file associated with an instant message

x-im-httpgateway

The upstream HTTP gateway used for IM (if any)

x-im-messageopcode

im.message.opcode

The opcode utilized in the instant message

x-im-messagereflected

im.message.reflected

Indicates whether or not the IM message was reflected.

x-im-messageroute

The route of the instance message

x-im-messagesize

Length of the instant message

x-im-message-text

Text of the instant message

x-im-messagetype

The type of the instant message

x-im-method

The method associated with the instant message

x-im-user-id

Instant messaging user identifer

x-im-user-name

Display name of the client

x-im-user-state

Instant messaging user state

Category: mapi x-mapi-method

The method associated with the MAPI request

x-mapi-user-dn

The distinguished name of the user negotiated by MAPI

67

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-mapi-user

The name of the user negotiated by MAPI. See x-mapi-user-dn for the fully distinguished name.

x-mapi-cs-rpccount

The count of RPC messages received from the client

x-mapi-sr-rpccount

The count of RPC messages sent to the server

x-mapi-rs-rpccount

The count of RPC messages received from the server

x-mapi-sc-rpccount

The count RPC messages sent to the client

x-mapi-endpointrpc-count

Total number of RPC messages sent to the end point

x-mapi-peer-rpccount

Total number of RPC messages sent to the peer

Category: p2p x-p2p-client-bytes

Number of bytes from client

x-p2p-client-info

The peer-to-peer client information

x-p2p-client-type x-p2p-peer-bytes

p2p.client

The peer-to-peer client type Number of bytes from peer

Category: packets c-pkts-lost-client

Number of packets lost during transmission from server to client and not recovered at the client layer via error correction or at the network layer via UDP resends.

c-pkts-lost-contnet

Maximum number of continuously lost packets on the network layer during transmission from server to client

c-pkts-lost-net

Number of packets lost on the network layer

c-pkts-received

Number of packets from the server (s-pkts-sent) that are received correctly by the client on the first try

c-pkts-recoveredECC

Number of packets repaired and recovered on the client layer

c-pkts-recoveredresent

Number of packets recovered because they were resent via UDP.

c-quality

The percentage of packets that were received by the client, indicating the quality of the stream

68

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

c-resendreqs

Number of client requests to receive new packets

s-pkts-sent

Number of packets from the server

Category: req_rsp_line cs-method

method

%m

x-cs-http-method

http.method

HTTP request method used from client to appliance. Empty for nonHTTP transactions

cs-protocol

client.protocol

Protocol used in the client's request

cs-request-line

http.request_line

x-cs-raw-headerscount

request.raw_headers.count

Total number of 'raw' headers in the request

x-cs-raw-headerslength

request.raw_headers. length

Total length of 'raw' headers in the request

cs-version

request.version

x-bluecoat-proxyvia-http-version

proxy.via_http_version

Default HTTP protocol version of the appliance without protocol decoration (e.g. 1.1 for HTTP/1.1)

x-bluecoatredirect-location

redirect.location

Redirect location URL specified by a redirect CPL action

%r

%V

rs-response-line

Request method used from client to appliance

First line of the client's request

Protocol and version from the client's request, e.g. HTTP/1.1

First line (a.k.a. status line) of the response from an upstream host to the appliance

rs-status

response.code

Protocol status code of the response from an upstream host to the appliance

rs-version

response.version

Protocol and version of the response from an upstream host to the appliance, e.g. HTTP/1.1

sc-status

%s

Protocol status code from appliance to client

x-bluecoat-sslfailure-reason

ssl_failure_reason

Upstream SSL negotiation failure reason

x-cs-http-version

http.request.version

HTTP protocol version of request from the client. Does not include protocol qualifier (e.g. 1.1 for HTTP/1.1)

x-cs-socks-ip

socks.destination_address

Destination IP address of a proxied SOCKS request

x-cs-socks-port

socks.destination_port

Destination port of a proxied SOCKS request

x-cs-socksmethod

socks.method

Method of a proxied SOCKS request

69

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

x-cs-socks-version

socks.version

Custom

Description Version of a proxied SOCKS request.

x-cs-sockscompression

Used compression in SOCKS client side connection.

x-sr-sockscompression

Used compression in SOCKS server side connection.

x-sc-http-status

http.response.code

HTTP response code sent from appliance to client

x-rs-http-version

http.response.version

HTTP protocol version of response from the upstream host. Does not include protocol qualifier (e.g. 1.1 for HTTP/1.1)

x-sc-http-version

HTTP protocol version of response to client. Does not include protocol qualifier (e.g. 1.1 for HTTP/1.1)

x-sr-http-version

HTTP protocol version of request to the upstream host. Does not include protocol qualifier (e.g. 1.1 for HTTP/1.1)

sc(ContentEncoding)

Client Response header: ContentEncoding

sr(AcceptEncoding)

Server Request header: AcceptEncoding

Category: special_token x-bluecoatspecial-amp

amp

The ampersand character

x-bluecoatspecial-apos

apos

The apostrophe character (a.k.a. single quote)

x-bluecoatspecial-cr

cr

Resolves to the carriage return character

x-bluecoatspecial-crlf

crlf

Resolves to a carriage return/line feed sequence

x-bluecoatspecial-empty

empty

x-bluecoatspecial-esc

esc

Resolves to the escape character (ASCII HEX 1B)

x-bluecoatspecial-gt

gt

The greater-than character

x-bluecoatspecial-lf

lf

The line feed character

x-bluecoatspecial-lt

lt

The less-than character

x-bluecoatspecial-quot

quot

The double quote character

x-bluecoatspecial-slash

slash

The forward slash character

%l

Resolves to an empty string

70

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

Category: ssl x-rs-certificatehostname

server.certificate.hostname

Hostname from the server's SSL certificate

x-rs-certificatehostnamecategories

All content categories of the server's SSL certificate's hostname

x-rs-certificatehostnamecategories-policy

All content categories of the server's SSL certificate's hostname that are defined by CPL.

x-rs-certificatehostnamecategories-local

All content categories of the server's SSL certificate's hostname that are defined by a Local database.

x-rs-certificatehostnamecategoriesbluecoat

All content categories of the server's SSL certificate's hostname that are defined by Blue Coat Web Filter.

x-rs-certificatehostnamecategoriesprovider

All content categories of the server's SSL certificate's hostname that are defined by the current 3rd-party provider.

x-rs-certificatehostnamecategoriesqualified

All content categories of the server's SSL certificate's hostname, qualified by the provider of the category.

x-rs-certificatehostnamecategory

server.certificate.hostname. category

Single content category of the server's SSL certificate's hostname

x-rs-certificatevalid-from

Date from which the certificate presented by the server is valid

x-rs-certificatevalid-to

Date until which the certificate presented by the server is valid

x-rs-certificateserial-number

Serial number of the certificate presented by the server

x-rs-certificateissuer

Issuer of the certificate presented by the server

x-rs-certificatesignaturealgorithm

Signature algorithm in the certificate presented by the server

x-rs-certificatepubkey-algorithm

Public key algorithm in the certificate presented by the server

x-rs-certificateversion

Version of the certificate presented by the server

x-rs-certificatesubject

server.certificate.subject

Subject of the certificate presented by the server

x-cs-certificatecommon-name

client.certificate.common_ name

Common name in the client certificate

71

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-cs-certificatevalid-from

Date from which the certificate presented by the client is valid

x-cs-certificatevalid-to

Date until which the certificate presented by the client is valid

x-cs-certificateserial-number

Serial number of the certificate presented by the client

x-cs-certificateissuer

Issuer of the certificate presented by the client

x-cs-certificatesignaturealgorithm

Signature algorithm in the certificate presented by the client

x-cs-certificatepubkey-algorithm

Public key algorithm in the certificate presented by the client

x-cs-certificateversion

Version of the certificate presented by the client

x-cs-certificatesubject

client.certificate.subject

Subject of the certificate presented by the client

x-rs-certificatevalidate-status

Result of validating server SSL certificate

x-rs-certificateobserved-errors

Errors observed in the server certificate

Category: status x-bluecoatrelease-id

release.id

The release ID of the ProxySG operating system

x-bluecoatrelease-version

release.version

The release version of the ProxySG operating system

cs-categories

All content categories of the request URL

cs-categoriesexternal

All content categories of the request URL that are defined by an external service.

cs-categoriespolicy

All content categories of the request URL that are defined by CPL.

cs-categories-local

All content categories of the request URL that are defined by a Local database.

cs-categoriesbluecoat

All content categories of the request URL that are defined by Blue Coat Web Filter.

cs-categoriesprovider

All content categories of the request URL that are defined by the current 3rd-party provider.

cs-categoriesqualified

All content categories of the request URL, qualified by the provider of the category.

72

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs-category

Single content category of the request URL (a.k.a. sc-filtercategory)

cs-uri-categories

All content categories of the request URL

cs-uri-categoriesexternal

All content categories of the request URL that are defined by an external service.

cs-uri-categoriespolicy

All content categories of the request URL that are defined by CPL.

cs-uri-categorieslocal

All content categories of the request URL that are defined by a Local database.

cs-uri-categoriesbluecoat

All content categories of the request URL that are defined by Blue Coat Web Filter.

cs-uri-categoriesprovider

All content categories of the request URL that are defined by the current 3rd-party provider.

cs-uri-categoriesqualified

All content categories of the request URL, qualified by the provider of the category.

cs-uri-category

Single content category of the request URL (a.k.a. sc-filtercategory)

x-cs(Referer)-uricategories

All content categories of the Referer header URL

x-cs(Referer)-uricategories-policy

All content categories of the Referer header URL that are defined by CPL.

x-cs(Referer)-uricategories-local

All content categories of the Referer header URL that are defined by a Local database.

x-cs(Referer)-uricategoriesbluecoat

All content categories of the Referer header URL that are defined by Blue Coat Web Filter.

x-cs(Referer)-uricategoriesprovider

All content categories of the Referer header URL that are defined by the current 3rd-party provider.

x-cs(Referer)-uricategoriesqualified

All content categories of the Referer header URL, qualified by the provider of the category.

x-cs(Referer)-uricategory

Single content category of the Referer header URL (a.k.a. sc-filtercategory)

r-hierarchy

How and where the object was retrieved in the cache hierarchy.

73

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

category

%f

Content filtering category of the request URL

sc-filter-result

%W

Deprecated content filtering result: Denied, Proxied or Observed

s-action

%w

What type of action did the Appliance take to process this request.

sc-filter-category

s-cpu-util

Average load on the proxy's processor (0%-100%)

s-hierarchy

%H

How and where the object was retrieved in the cache hierarchy.

s-icap-info

%Z

ICAP response information

s-icap-status

%z

ICAP response status

x-bluecoatsurfcontrolcategory-id

The SurfControl specific content category ID.

x-bluecoatsurfcontrol-isdenied

'1' if the transaction was denied, else '0'

x-bluecoatsurfcontrol-isproxied

'0' if transaction is explicitly proxied, '1' if transaction is transparently proxied

x-bluecoatsurfcontrolreporter-id

Specialized value for SurfControl reporter

x-bluecoatsurfcontrolreporter-v4

The SurfControl Reporter v4 format

x-bluecoatsurfcontrolreporter-v5

The SurfControl Reporter v5 format

x-bluecoatwebsensecategory-id

The Websense specific content category ID

x-bluecoatwebsensekeyword

The Websense specific keyword

x-bluecoatwebsensereporter-id

The Websense specific reporter category ID

x-bluecoatwebsense-status

The Websense specific numeric status

x-bluecoatwebsense-user

The Websense form of the username

x-bluecoatwebsensereporter-protocol3

The Websense reporter format protocol version 3

74

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-exceptioncompany-name

exception.company_name

The company name configured under exceptions

x-exceptioncontact

exception.contact

Describes who to contact when certain classes of exceptions occur, configured under exceptions (empty if the transaction has not been terminated)

x-exceptiondetails

exception.details

The configurable details of a selecte policy-aware response page (empty if the transaction has not been terminated)

x-exceptionheader

exception.header

The header to be associated with an exception response (empty if the transaction has not been terminated)

x-exception-help

exception.help

Help text that accompanies the exception resolved (empty if the transaction has not been terminated)

x-exception-id

exception.id

Identifier of the exception resolved (empty if the transaction has not been terminated)

x-exception-lasterror

exception.last_error

The last error recorded for the current transaction. This can provide insight when unexpected problems are occurring (empty if the transaction has not been terminated)

x-exceptionreason

exception.reason

Indicates the reason why a particular request was terminated (empty if the transaction has not been terminated)

x-exceptionsourcefile

exception.sourcefile

Source filename from which the exception was generated (empty if the transaction has not been terminated)

x-exceptionsourceline

exception.sourceline

Source file line number from which the exception was generated (empty if the transaction has not been terminated)

x-exceptionsummary

exception.summary

Summary of the exception resolved (empty if the transaction has not been terminated)

x-exceptioncategory-reviewmessage

exception.category_review _message

Exception page message that includes a link allowing content categorization to be reviewed and/ or disputed.

x-exceptioncategory-reviewurl

exception.category_review _url

URL where content categorizations can be reviewed and/or disputed.

75

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-patiencejavascript

patience_javascript

Javascript required to allow patience responses

x-patienceprogress

patience_progress

The progress of the patience request

x-patience-time

patience_time

The elapsed time of the patience request

x-patience-url

patience_url

The url to be requested for more patience information

x-virus-id

icap_virus_id

Identifier of a virus if one was detected

x-virus-details

icap_virus_details

Details of a virus if one was detected

x-icap-error-code

icap_error_code

ICAP error code

x-icap-errordetails

icap_error_details

ICAP error details

Category: streaming audiocodec

Audio codec used in stream.

avgbandwidth

Average bandwidth (in bits per second) at which the client was connected to the server.

channelURL

URL to the .nsc file

c-buffercount

Number of times the client buffered while playing the stream.

c-bytes

An MMS-only value of the total number of bytes delivered to the client.

c-cpu

Client computer CPU type.

c-hostexe

Host application

c-hostexever

Host application version number

c-os

Client computer operating system

c-osversion

Client computer operating system version number

c-playerid

Globally unique identifier (GUID) of the player

c-playerlanguage

Client language-country code

c-playerversion

Version number of the player

c-rate

Mode of Windows Media Player when the last command event was sent

c-starttime

Timestamp (in seconds) of the stream when an entry is generated in the log file.

c-status

Codes that describe client status

76

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

c-totalbuffertime

Time (in seconds) the client used to buffer the stream

filelength

Length of the file (in seconds).

filesize

Size of the file (in bytes).

protocol

Protocol used to access the stream: mms, http, or asfm.

s-totalclients

Clients connected to the server (but not necessarily receiving streams).

transport

Transport protocol used (UDP, TCP, multicast, etc.)

videocodec

Video codec used to encode the stream.

x-cache-info

Values: UNKNOWN, DEMAND_MISS, DEMAND_PARTIAL_HIT, DEMAND_HIT, LIVE_FROM_ORIGIN, LIVE_PARTIAL_SPLIT, LIVE_SPLIT

x-duration

Length of time a client played content prior to a client event (FF, REW, Pause, Stop, or jump to marker).

x-wm-c-dns

Hostname of the client determined from the Windows Media protocol

x-wm-c-ip

The client IP address determined from the Windows Media protocol

x-cs-streamingclient

streaming.client

Type of streaming client in use (windows_media, real_media, or quicktime).

x-rs-streamingcontent

streaming.content

Type of streaming content served. (e.g. windows_media, quicktime)

x-streamingbitrate

bitrate

The reported client-side bitrate for the stream

Category: time connect-time date

Total ms required to connect to the origin server date.utc

%x

dnslookup-time

GMT Date in YYYY-MM-DD format Total ms cache required to perform the DNS lookup

duration

%T

Time taken (in seconds) to process the request

gmttime

%t

GMT date and time of the user request in format: [DD/MM/ YYYY:hh:mm:ss GMT]

77

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-bluecoat-dayutc

day.utc

GMT/UTC day (as a number) formatted to take up two spaces (e.g. 07 for the 7th of the month)

x-bluecoat-hourutc

hour.utc

GMT/UTC hour formatted to always take up two spaces (e.g. 01 for 1AM)

x-bluecoatminute-utc

minute.utc

GMT/UTC minute formatted to always take up two spaces (e.g. 01 for 1 minute past)

x-bluecoatmonth-utc

month.utc

GMT/UTC month (as a number) formatted to take up two spaces (e.g. 01 for January)

x-bluecoatmonthname-utc

monthname.utc

GMT/UTC month in the shortform string representation (e.g. Jan for January)

x-bluecoatsecond-utc

second.utc

GMT/UTC second formatted to always take up two spaces (e.g. 01 for 1 second past)

x-bluecoatweekday-utc

weekday.utc

GMT/UTC weekday in the shortform string representation (e.g. Mon for Monday)

x-bluecoat-yearutc

year.utc

GMT/UTC year formatted to always take up four spaces

localtime

%L

Local date and time of the user request in format: [DD/MMM/ YYYY:hh:mm:ss +nnnn]

x-bluecoat-day

day

Localtime day (as a number) formatted to take up two spaces (e.g. 07 for the 7th of the month)

x-bluecoat-hour

hour

Localtime hour formatted to always take up two spaces (e.g. 01 for 1AM)

x-bluecoat-minute

minute

Localtime minute formatted to always take up two spaces (e.g. 01 for 1 minute past)

x-bluecoat-month

month

Localtime month (as a number) formatted to take up two spaces (e.g. 01 for January)

x-bluecoatmonthname

monthname

Localtime month in the short-form string representation (e.g. Jan for January)

x-bluecoat-second

second

Localtime second formatted to always take up two spaces (e.g. 01 for 1 second past)

x-bluecoatweekday

weekday

Localtime weekday in the shortform string representation (e.g. Mon for Monday)

x-bluecoat-year

year

Localtime year formatted to always take up four spaces

78

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

time

time.utc

%y

GMT time in HH:MM:SS format

timestamp

%g

Unix type timestamp

time-taken

%e

Time taken (in milliseconds) to process the request

rs-time-taken

Total time taken (in milliseconds) to send the request and receive the response from the origin server

x-bluecoat-endtime-wft

End local time of the transaction represented as a windows file time

x-bluecoat-starttime-wft

Start local time of the transaction represented as a windows file time

x-bluecoat-endtime-mssql

End local time of the transaction represented as a serial date time

x-bluecoat-starttime-mssql

Start local time of the transaction represented as a serial date time

x-cookie-date

cookie_date

Current date in Cookie time format

x-http-date

http_date

Current date in HTTP time format

x-timestamp-unix

Seconds since UNIX epoch (Jan 1, 1970) (local time)

x-timestampunix-utc

Seconds since UNIX epoch (Jan 1, 1970) (GMT/UTC)

cs-categorizationtime-dynamic

Time taken (in milliseconds) to dynamically categorize the request URL

Category: url cs-host

%v

%i

Hostname from the client's request URL. If URL rewrite policies are used, this field's value is derived from the 'log' URL

cs-uri

log_url

cs-uri-address

log_url.address

IP address from the 'log' URL. DNS is used if URL uses a hostname.

cs-uri-extension

log_url.extension

Document extension from the 'log' URL.

cs-uri-host

log_url.host

Hostname from the 'log' URL.

cs-uri-hostname

log_url.hostname

Hostname from the 'log' URL. RDNS is used if the URL uses an IP address.

cs-uri-path

log_url.path

cs-uri-pathquery

log_url.pathquery

Path and query from the 'log' URL.

cs-uri-port

log_url.port

Port from the 'log' URL.

cs-uri-query

log_url.query

cs-uri-scheme

log_url.scheme

%U

%Q

The 'log' URL.

Path from the 'log' URL. Does not include query.

Query from the 'log' URL. Scheme from the 'log' URL.

79

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

cs-uri-stem

Custom

Description Stem from the 'log' URL. The stem includes everything up to the end of path, but does not include the query.

c-uri

url

The original URL requested.

c-uri-address

url.address

IP address from the original URL requested. DNS is used if the URL is expressed as a hostname.

c-uri-cookiedomain

url.cookie_domain

The cookie domain of the original URL requested

c-uri-extension

url.extension

Document extension from the original URL requested

c-uri-host

url.host

Hostname from the original URL requested

c-uri-hostname

url.hostname

Hostname from the original URL requested. RDNS is used if the URL is expressed as an IP address

c-uri-path

url.path

Path of the original URL requested without query.

c-uri-pathquery

url.pathquery

Path and query of the original URL requested

c-uri-port

url.port

Port from the original URL requested

c-uri-query

url.query

Query from the original URL requested

c-uri-scheme

url.scheme

Scheme of the original URL requested

c-uri-stem

Stem of the original URL requested

sr-uri

server_url

URL of the upstream request

sr-uri-address

server_url.address

IP address from the URL used in the upstream request. DNS is used if the URL is expressed as a hostname.

sr-uri-extension

server_url.extension

Document extension from the URL used in the upstream request

sr-uri-host

server_url.host

Hostname from the URL used in the upstream request

sr-uri-hostname

server_url.hostname

Hostname from the URL used in the upstream request. RDNS is used if the URL is expressed as an IP address.

sr-uri-path

server_url.path

Path from the upstream request URL

sr-uri-pathquery

server_url.pathquery

Path and query from the upstream request URL

sr-uri-port

server_url.port

Port from the URL used in the upstream request.

80

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

sr-uri-query

server_url.query

Query from the upstream request URL

sr-uri-scheme

server_url.scheme

Scheme from the URL used in the upstream request

sr-uri-stem

Path from the upstream request URL

s-uri

cache_url

The URL used for cache access

s-uri-address

cache_url.address

IP address from the URL used for cache access. DNS is used if the URL is expressed as a hostname

s-uri-extension

cache_url.extension

Document extension from the URL used for cache access

s-uri-host

cache_url.host

Hostname from the URL used for cache access

s-uri-hostname

cache_url.hostname

Hostname from the URL used for cache access. RDNS is used if the URL uses an IP address

s-uri-path

cache_url.path

Path of the URL used for cache access

s-uri-pathquery

cache_url.pathquery

Path and query of the URL used for cache access

s-uri-port

cache_url.port

Port from the URL used for cache access

s-uri-query

cache_url.query

Query string of the URL used for cache access

s-uri-scheme

cache_url.scheme

Scheme from the URL used for cache access

s-uri-stem

Stem of the URL used for cache access

x-cs(Referer)-uri

request.header.Referer.url

The URL from the Referer header.

x-cs(Referer)-uriaddress

request.header.Referer.url. address

IP address from the 'Referer' URL. DNS is used if URL uses a hostname.

x-cs(Referer)-uriextension

request.header.Referer.url. extension

Document extension from the 'Referer' URL.

x-cs(Referer)-urihost

request.header.Referer.url. host

Hostname from the 'Referer' URL.

x-cs(Referer)-urihostname

request.header.Referer.url. hostname

Hostname from the 'Referer' URL. RDNS is used if the URL uses an IP address.

x-cs(Referer)-uripath

request.header.Referer.url. path

Path from the 'Referer' URL. Does not include query.

x-cs(Referer)-uripathquery

request.header.Referer.url. pathquery

Path and query from the 'Referer' URL.

x-cs(Referer)-uriport

request.header.Referer.url. port

Port from the 'Referer' URL.

81

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-cs(Referer)-uriquery

request.header.Referer.url. query

Query from the 'Referer' URL.

x-cs(Referer)-urischeme

request.header.Referer.url. scheme

Scheme from the 'Referer' URL.

x-cs(Referer)-uristem

Stem from the 'Referer' URL. The stem includes everything up to the end of path, but does not include the query.

x-cs-raw-uri

raw_url

The 'raw' request URL.

x-cs-raw-uri-host

raw_url.host

Hostname from the 'raw' URL.

x-cs-raw-uri-port

raw_url.port

Port string from the 'raw' URL.

x-cs-raw-urischeme

raw_url.scheme

Scheme string from the 'raw' URL.

x-cs-raw-uri-path

raw_url.path

Path from the 'raw' request URL. Does not include query.

x-cs-raw-uripathquery

raw_url.pathquery

Path and query from the 'raw' request URL.

x-cs-raw-uriquery

raw_url.query

Query from the 'raw' request URL.

x-cs-raw-uri-stem

Stem from the 'raw' request URL. The stem includes everything up to the end of path, but does not include the query.

Category: user cs-auth-group

group

One group that an authenticated user belongs to. If a user belongs to multiple groups, the group logged is determined by the Group Log Order configuration specified in VPM. If Group Log Order is not specified, an arbitrary group is logged. Note that only groups referenced by policy are considered.

cs-auth-groups

groups

List of groups that an authenticated user belongs to. Note that only groups referenced by policy are included.

cs-auth-type cs-realm

Client-side: authentication type (basic, ntlm, etc.) realm

cs-user

cs-userdn

Authentication realm that the user was challenged in. %u

user

Qualified username for NTLM. Relative username for other protocols Full username of a client authenticated to the proxy (fully distinguished)

82

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-cs-userauthorizationname

user.authorization_name

Username used to authorize a client authenticated to the proxy

x-cs-usercredential-name

user.credential_name

Username entered by the user to authenticate to the proxy.

cs-username

user.name

Relative username of a client authenticated to the proxy (i.e. not fully distinguished)

sc-auth-status

Client-side: Authorization status

x-agent-ssocookie

The authentication agent single signon cookie

x-cache-user

Relative username of a client authenticated to the proxy (i.e. not fully distinguished) (same as csusername)

x-cs-auth-domain

user.domain

The domain of the authenticated user.

x-scauthenticationerror

The user authentication error.

x-scauthorizationerror

The user authorization error.

x-cs-user-type

The type of authenticated user.

x-cs-auth-formaction-url

The URL to submit the authentication form to.

x-cs-auth-formdomain-field

The authentication form input field for the user's domain.

x-cs-auth-requestid

The bas64 encoded string containing the original request information during forms based authentication

x-cs-username-orip

Used to identify the user using either their authenticated proxy username or, if that is unavailable, their IP address.

x-radius-splashsession-id

Session ID made available through RADIUS when configured for session management

x-radius-splashusername

Username made available through RADIUS when configured for session management

x-user-x509-issuer

user.x509.issuer

If the user was authenticated via an X.509 certificate, this is the issuer of the certificate as an RFC2253 DN

83

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

x-user-x509serial-number

user.x509.serialNumber

If the user was authenticated via an X.509 certificate, this is the serial number from the certificate as a hexadecimal number.

x-user-x509subject

user.x509.subject

If the user was authenticated via an X.509 certificate, this is the subject of the certificate as an RFC2253 DN

x-auth-challengestring

The authentication challenge to display to the user.

x-auth-privatechallenge-state

The private state required to manage an authentication challenge

x-cs-user-logintime

user.login.time

The number of seconds the user had been logged in.

x-cs-user-logincount

user.login.count

The number of workstations the user is currently logged in at.

x-cs-clientaddress-logincount

client.address.login.count

The number of users currently logged in at the client ip address.

x-cs-user-loginaddress

user.login.address

The ip address that the user was authenticated in.

Category: ci_request_header cs(Accept)

request.header.Accept

Request header: Accept

cs(Accept)-length

request.header.Accept. length

Length of HTTP request header: Accept

cs(Accept)-count

request.header.Accept. count

Number of HTTP request header: Accept

cs(AcceptCharset)

request.header.AcceptCharset

Request header: Accept-Charset

cs(AcceptCharset)-length

request.header.AcceptCharset.length

Length of HTTP request header: Accept-Charset

cs(AcceptCharset)-count

request.header.AcceptCharset.count

Number of HTTP request header: Accept-Charset

cs(AcceptEncoding)

request.header.AcceptEncoding

Request header: Accept-Encoding

cs(AcceptEncoding)-length

request.header.AcceptEncoding.length

Length of HTTP request header: Accept-Encoding

cs(AcceptEncoding)-count

request.header.AcceptEncoding.count

Number of HTTP request header: Accept-Encoding

cs(AcceptLanguage)

request.header.AcceptLanguage

Request header: Accept-Language

cs(AcceptLanguage)-length

request.header.AcceptLanguage.length

Length of HTTP request header: Accept-Language

cs(AcceptLanguage)-count

request.header.AcceptLanguage.count

Number of HTTP request header: Accept-Language

84

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(AcceptRanges)

request.header.AcceptRanges

Request header: Accept-Ranges

cs(AcceptRanges)-length

request.header.AcceptRanges.length

Length of HTTP request header: Accept-Ranges

cs(AcceptRanges)-count

request.header.AcceptRanges.count

Number of HTTP request header: Accept-Ranges

cs(Age)

request.header.Age

Request header: Age

cs(Age)-length

request.header.Age.length

Length of HTTP request header: Age

cs(Age)-count

request.header.Age.count

Number of HTTP request header: Age

cs(Allow)

request.header.Allow

Request header: Allow

cs(Allow)-length

request.header.Allow. length

Length of HTTP request header: Allow

cs(Allow)-count

request.header.Allow.count

Number of HTTP request header: Allow

cs(Authentication -Info)

request.header. Authentication-Info

Request header: AuthenticationInfo

cs(Authentication -Info)-length

request.header. Authentication-Info.length

Length of HTTP request header: Authentication-Info

cs(Authentication -Info)-count

request.header. Authentication-Info.count

Number of HTTP request header: Authentication-Info

cs(Authorization)

request.header. Authorization

Request header: Authorization

cs(Authorization) -length

request.header. Authorization.length

Length of HTTP request header: Authorization

cs(Authorization) -count

request.header. Authorization.count

Number of HTTP request header: Authorization

cs(Cache-Control)

request.header.CacheControl

Request header: Cache-Control

cs(CacheControl)-length

request.header.CacheControl.length

Length of HTTP request header: Cache-Control

cs(CacheControl)-count

request.header.CacheControl.count

Number of HTTP request header: Cache-Control

cs(Client-IP)

request.header.Client-IP

Request header: Client-IP

cs(Client-IP)length

request.header.ClientIP.length

Length of HTTP request header: Client-IP

cs(Client-IP)count

request.header.ClientIP.count

Number of HTTP request header: Client-IP

cs(Connection)

request.header.Connection

Request header: Connection

cs(Connection)length

request.header.Connection. length

Length of HTTP request header: Connection

cs(Connection)count

request.header.Connection. count

Number of HTTP request header: Connection

cs(ContentDisposition)

request.header.ContentDisposition

Request header: ContentDisposition

85

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF cs(ContentDisposition)length

CPL request.header.ContentDisposition.length

Custom

Description Length of HTTP request header: Content-Disposition

cs(Contentrequest.header.ContentDisposition)-count Disposition.count

Number of HTTP request header: Content-Disposition

cs(ContentEncoding)

request.header.ContentEncoding

Request header: Content-Encoding

cs(ContentEncoding)-length

request.header.ContentEncoding.length

Length of HTTP request header: Content-Encoding

cs(ContentEncoding)-count

request.header.ContentEncoding.count

Number of HTTP request header: Content-Encoding

cs(ContentLanguage)

request.header.ContentLanguage

Request header: Content-Language

cs(ContentLanguage)-length

request.header.ContentLanguage.length

Length of HTTP request header: Content-Language

cs(ContentLanguage)-count

request.header.ContentLanguage.count

Number of HTTP request header: Content-Language

cs(ContentLength)

request.header.ContentLength

Request header: Content-Length

cs(ContentLength)-length

request.header.ContentLength.length

Length of HTTP request header: Content-Length

cs(ContentLength)-count

request.header.ContentLength.count

Number of HTTP request header: Content-Length

cs(ContentLocation)

request.header.ContentLocation

Request header: Content-Location

cs(ContentLocation)-length

request.header.ContentLocation.length

Length of HTTP request header: Content-Location

cs(ContentLocation)-count

request.header.ContentLocation.count

Number of HTTP request header: Content-Location

cs(Content-MD5)

request.header.ContentMD5

Request header: Content-MD5

cs(Content-MD5)- request.header.Contentlength MD5.length

Length of HTTP request header: Content-MD5

cs(Content-MD5)- request.header.Contentcount MD5.count

Number of HTTP request header: Content-MD5

cs(ContentRange)

request.header.ContentRange

Request header: Content-Range

cs(ContentRange)-length

request.header.ContentRange.length

Length of HTTP request header: Content-Range

cs(ContentRange)-count

request.header.ContentRange.count

Number of HTTP request header: Content-Range

cs(Content-Type)

request.header.ContentType

Request header: Content-Type

cs(Content-Type)length

request.header.ContentType.length

Length of HTTP request header: Content-Type

86

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(Content-Type)count

request.header.ContentType.count

Number of HTTP request header: Content-Type

cs(Cookie)

request.header.Cookie

cs(Cookie)-length

request.header.Cookie. length

Length of HTTP request header: Cookie

cs(Cookie)-count

request.header.Cookie. count

Number of HTTP request header: Cookie

cs(Cookie2)

request.header.Cookie2

Request header: Cookie2

cs(Cookie2)length

request.header.Cookie2. length

Length of HTTP request header: Cookie2

cs(Cookie2)-count

request.header.Cookie2. count

Number of HTTP request header: Cookie2

cs(Date)

request.header.Date

Request header: Date

cs(Date)-length

request.header.Date.length

Length of HTTP request header: Date

cs(Date)-count

request.header.Date.count

Number of HTTP request header: Date

cs(Etag)

request.header.Etag

Request header: Etag

cs(Etag)-length

request.header.Etag.length

Length of HTTP request header: Etag

cs(Etag)-count

request.header.Etag.count

Number of HTTP request header: Etag

cs(Expect)

request.header.Expect

Request header: Expect

cs(Expect)-length

request.header.Expect. length

Length of HTTP request header: Expect

cs(Expect)-count

request.header.Expect. count

Number of HTTP request header: Expect

cs(Expires)

request.header.Expires

Request header: Expires

cs(Expires)-length

request.header.Expires. length

Length of HTTP request header: Expires

cs(Expires)-count

request.header.Expires. count

Number of HTTP request header: Expires

cs(From)

request.header.From

Request header: From

cs(From)-length

request.header.From. length

Length of HTTP request header: From

cs(From)-count

request.header.From.count

Number of HTTP request header: From

cs(Front-EndHTTPS)

request.header.Front-EndHTTPS

Request header: Front-End-HTTPS

cs(Front-EndHTTPS)-length

request.header.Front-EndHTTPS.length

Length of HTTP request header: Front-End-HTTPS

cs(Front-EndHTTPS)-count

request.header.Front-EndHTTPS.count

Number of HTTP request header: Front-End-HTTPS

cs(Host)

request.header.Host

Request header: Host

%C

Request header: Cookie

87

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(Host)-length

request.header.Host.length

Length of HTTP request header: Host

cs(Host)-count

request.header.Host.count

Number of HTTP request header: Host

cs(If-Match)

request.header.If-Match

Request header: If-Match

cs(If-Match)length

request.header.IfMatch.length

Length of HTTP request header: IfMatch

cs(If-Match)count

request.header.IfMatch.count

Number of HTTP request header: If-Match

cs(If-ModifiedSince)

request.header.IfModified-Since

Request header: If-Modified-Since

cs(If-ModifiedSince)-length

request.header.IfModified-Since.length

Length of HTTP request header: IfModified-Since

cs(If-ModifiedSince)-count

request.header.IfModified-Since.count

Number of HTTP request header: If-Modified-Since

cs(If-None-Match)

request.header.If-NoneMatch

Request header: If-None-Match

cs(If-NoneMatch)-length

request.header.If-NoneMatch.length

Length of HTTP request header: IfNone-Match

cs(If-NoneMatch)-count

request.header.If-NoneMatch.count

Number of HTTP request header: If-None-Match

cs(If-Range)

request.header.If-Range

Request header: If-Range

cs(If-Range)length

request.header.IfRange.length

Length of HTTP request header: IfRange

cs(If-Range)count

request.header.IfRange.count

Number of HTTP request header: If-Range

cs(If-UnmodifiedSince)

request.header.IfUnmodified-Since

Request header: If-UnmodifiedSince

cs(If-UnmodifiedSince)-length

request.header.IfUnmodified-Since.length

Length of HTTP request header: IfUnmodified-Since

cs(If-UnmodifiedSince)-count

request.header.IfUnmodified-Since.count

Number of HTTP request header: If-Unmodified-Since

cs(Last-Modified)

request.header.LastModified

Request header: Last-Modified

cs(LastModified)-length

request.header.LastModified.length

Length of HTTP request header: Last-Modified

cs(LastModified)-count

request.header.LastModified.count

Number of HTTP request header: Last-Modified

cs(Location)

request.header.Location

Request header: Location

cs(Location)length

request.header.Location. length

Length of HTTP request header: Location

cs(Location)count

request.header.Location. count

Number of HTTP request header: Location

cs(Max-Forwards)

request.header.MaxForwards

Request header: Max-Forwards

88

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(MaxForwards)-length

request.header.MaxForwards.length

Length of HTTP request header: Max-Forwards

cs(MaxForwards)-count

request.header.MaxForwards.count

Number of HTTP request header: Max-Forwards

cs(Meter)

request.header.Meter

Request header: Meter

cs(Meter)-length

request.header.Meter. length

Length of HTTP request header: Meter

cs(Meter)-count

request.header.Meter.count

Number of HTTP request header: Meter

cs(P3P)

request.header.P3P

Request header: P3P

cs(P3P)-length

request.header.P3P.length

Length of HTTP request header: P3P

cs(P3P)-count

request.header.P3P.count

Number of HTTP request header: P3P

cs(Pragma)

request.header.Pragma

Request header: Pragma

cs(Pragma)length

request.header.Pragma. length

Length of HTTP request header: Pragma

cs(Pragma)-count

request.header.Pragma. count

Number of HTTP request header: Pragma

cs(ProxyAuthenticate)

request.header.ProxyAuthenticate

Request header: ProxyAuthenticate

cs(ProxyAuthenticate)length

request.header.ProxyAuthenticate.length

Length of HTTP request header: Proxy-Authenticate

cs(ProxyAuthenticate)count

request.header.ProxyAuthenticate.count

Number of HTTP request header: Proxy-Authenticate

cs(ProxyAuthorization)

request.header.ProxyAuthorization

Request header: ProxyAuthorization

cs(ProxyAuthorization)length

request.header.ProxyAuthorization.length

Length of HTTP request header: Proxy-Authorization

cs(ProxyAuthorization)count

request.header.ProxyAuthorization.count

Number of HTTP request header: Proxy-Authorization

cs(ProxyConnection)

request.header.ProxyConnection

Request header: Proxy-Connection

cs(ProxyConnection)length

request.header.ProxyConnection.length

Length of HTTP request header: Proxy-Connection

cs(Proxyrequest.header.ProxyConnection)-count Connection.count

Number of HTTP request header: Proxy-Connection

cs(Range)

request.header.Range

Request header: Range

cs(Range)-length

request.header.Range. length

Length of HTTP request header: Range

89

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(Range)-count

request.header.Range. count

cs(Referer)

request.header.Referer

cs(Referer)-length

request.header.Referer. length

Length of HTTP request header: Referer

cs(Referer)-count

request.header.Referer. count

Number of HTTP request header: Referer

cs(Refresh)

request.header.Refresh

Request header: Refresh

cs(Refresh)-length

request.header.Refresh. length

Length of HTTP request header: Refresh

cs(Refresh)-count

request.header.Refresh. count

Number of HTTP request header: Refresh

cs(Retry-After)

request.header.Retry-After

Request header: Retry-After

cs(Retry-After)length

request.header.RetryAfter.length

Length of HTTP request header: Retry-After

cs(Retry-After)count

request.header.RetryAfter.count

Number of HTTP request header: Retry-After

cs(Server)

request.header.Server

Request header: Server

cs(Server)-length

request.header.Server. length

Length of HTTP request header: Server

cs(Server)-count

request.header.Server. count

Number of HTTP request header: Server

cs(Set-Cookie)

request.header.Set-Cookie

Request header: Set-Cookie

cs(Set-Cookie)length

request.header.SetCookie.length

Length of HTTP request header: Set-Cookie

cs(Set-Cookie)count

request.header.SetCookie.count

Number of HTTP request header: Set-Cookie

cs(Set-Cookie2)

request.header.Set-Cookie2

Request header: Set-Cookie2

cs(Set-Cookie2)length

request.header.SetCookie2.length

Length of HTTP request header: Set-Cookie2

cs(Set-Cookie2)count

request.header.SetCookie2.count

Number of HTTP request header: Set-Cookie2

cs(TE)

request.header.TE

Request header: TE

cs(TE)-length

request.header.TE.length

Length of HTTP request header: TE

cs(TE)-count

request.header.TE.count

Number of HTTP request header: TE

cs(Trailer)

request.header.Trailer

Request header: Trailer

cs(Trailer)-length

request.header.Trailer. length

Length of HTTP request header: Trailer

cs(Trailer)-count

request.header.Trailer. count

Number of HTTP request header: Trailer

cs(TransferEncoding)

request.header.TransferEncoding

Request header: Transfer-Encoding

cs(TransferEncoding)-length

request.header.TransferEncoding.length

Length of HTTP request header: Transfer-Encoding

Number of HTTP request header: Range %R

Request header: Referer

90

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(TransferEncoding)-count

request.header.TransferEncoding.count

Number of HTTP request header: Transfer-Encoding

cs(Upgrade)

request.header.Upgrade

Request header: Upgrade

cs(Upgrade)length

request.header.Upgrade. length

Length of HTTP request header: Upgrade

cs(Upgrade)count

request.header.Upgrade. count

Number of HTTP request header: Upgrade

cs(User-Agent)

request.header.User-Agent

cs(User-Agent)length

request.header.UserAgent.length

Length of HTTP request header: User-Agent

cs(User-Agent)count

request.header.UserAgent.count

Number of HTTP request header: User-Agent

cs(Vary)

request.header.Vary

Request header: Vary

cs(Vary)-length

request.header.Vary.length

Length of HTTP request header: Vary

cs(Vary)-count

request.header.Vary.count

Number of HTTP request header: Vary

cs(Via)

request.header.Via

Request header: Via

cs(Via)-length

request.header.Via.length

Length of HTTP request header: Via

cs(Via)-count

request.header.Via.count

Number of HTTP request header: Via

cs(WWWAuthenticate)

request.header.WWWAuthenticate

Request header: WWWAuthenticate

cs(WWWAuthenticate)length

request.header.WWWAuthenticate.length

Length of HTTP request header: WWW-Authenticate

cs(WWWAuthenticate)count

request.header.WWWAuthenticate.count

Number of HTTP request header: WWW-Authenticate

cs(Warning)

request.header.Warning

Request header: Warning

cs(Warning)length

request.header.Warning. length

Length of HTTP request header: Warning

cs(Warning)count

request.header.Warning. count

Number of HTTP request header: Warning

cs(X-BlueCoatError)

request.header.X-BlueCoatError

Request header: X-BlueCoat-Error

cs(X-BlueCoatError)-length

request.header.X-BlueCoatError.length

Length of HTTP request header: XBlueCoat-Error

cs(X-BlueCoatError)-count

request.header.X-BlueCoatError.count

Number of HTTP request header: X-BlueCoat-Error

cs(X-BlueCoatMC-Client-Ip)

request.header.X-BlueCoatMC-Client-Ip

Request header: X-BlueCoat-MCClient-Ip

cs(X-BlueCoatMC-Client-Ip)length

request.header.X-BlueCoatMC-Client-Ip.length

Length of HTTP request header: XBlueCoat-MC-Client-Ip

%A

Request header: User-Agent

91

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

cs(X-BlueCoatMC-Client-Ip)count

request.header.X-BlueCoatMC-Client-Ip.count

Number of HTTP request header: X-BlueCoat-MC-Client-Ip

cs(X-BlueCoatVia)

request.header.X-BlueCoatVia

Request header: X-BlueCoat-Via

cs(X-BlueCoatVia)-length

request.header.X-BlueCoatVia.length

Length of HTTP request header: XBlueCoat-Via

cs(X-BlueCoatVia)-count

request.header.X-BlueCoatVia.count

Number of HTTP request header: X-BlueCoat-Via

cs(X-ForwardedFor)

request.header.XForwarded-For

cs(X-ForwardedFor)-length

request.header.XForwarded-For.length

Length of HTTP request header: XForwarded-For

cs(X-ForwardedFor)-count

request.header.XForwarded-For.count

Number of HTTP request header: X-Forwarded-For

%X

Request header: X-Forwarded-For

Category: si_response_header rs(Accept)

response.header.Accept

Response header: Accept

rs(AcceptCharset)

response.header.AcceptCharset

Response header: Accept-Charset

rs(AcceptEncoding)

response.header.AcceptEncoding

Response header: Accept-Encoding

rs(AcceptLanguage)

response.header.AcceptLanguage

Response header: Accept-Language

rs(Accept-Ranges)

response.header.AcceptRanges

Response header: Accept-Ranges

rs(Age)

response.header.Age

Response header: Age

rs(Allow)

response.header.Allow

Response header: Allow

rs(Authentication -Info)

response.header. Authentication-Info

Response header: AuthenticationInfo

rs(Authorization)

response.header. Authorization

Response header: Authorization

rs(Cache-Control)

response.header.CacheControl

Response header: Cache-Control

rs(Client-IP)

response.header.Client-IP

Response header: Client-IP

rs(Connection)

response.header. Connection

Response header: Connection

rs(ContentDisposition)

response.header.ContentDisposition

Response header: ContentDisposition

rs(ContentEncoding)

response.header.ContentEncoding

Response header: ContentEncoding

rs(ContentLanguage)

response.header.ContentLanguage

Response header: ContentLanguage

rs(ContentLength)

response.header.ContentLength

Response header: Content-Length

92

Appendix A: Access Log Formats

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

rs(ContentLocation)

response.header.ContentLocation

Response header: Content-Location

rs(Content-MD5)

response.header.ContentMD5

Response header: Content-MD5

rs(ContentRange)

response.header.ContentRange

Response header: Content-Range

rs(Content-Type)

response.header.ContentType

%c

Response header: Content-Type

rs(Cookie)

response.header.Cookie

Response header: Cookie

rs(Cookie2)

response.header.Cookie2

Response header: Cookie2

rs(Date)

response.header.Date

Response header: Date

rs(Etag)

response.header.Etag

Response header: Etag

rs(Expect)

response.header.Expect

Response header: Expect

rs(Expires)

response.header.Expires

Response header: Expires

rs(From)

response.header.From

Response header: From

rs(Front-EndHTTPS)

response.header.FrontEnd-HTTPS

Response header: Front-EndHTTPS

rs(Host)

response.header.Host

Response header: Host

rs(If-Match)

response.header.If-Match

Response header: If-Match

rs(If-ModifiedSince)

response.header.IfModified-Since

Response header: If-Modified-Since

rs(If-None-Match)

response.header.If-NoneMatch

Response header: If-None-Match

rs(If-Range)

response.header.If-Range

Response header: If-Range

rs(If-UnmodifiedSince)

response.header.IfUnmodified-Since

Response header: If-UnmodifiedSince

rs(Last-Modified)

response.header.LastModified

Response header: Last-Modified

rs(Location)

response.header.Location

Response header: Location

rs(Max-Forwards)

response.header.MaxForwards

Response header: Max-Forwards

rs(Meter)

response.header.Meter

Response header: Meter

rs(P3P)

response.header.P3P

Response header: P3P

rs(Pragma)

response.header.Pragma

Response header: Pragma

rs(ProxyAuthenticate)

response.header.ProxyAuthenticate

Response header: ProxyAuthenticate

rs(ProxyAuthorization)

response.header.ProxyAuthorization

Response header: ProxyAuthorization

rs(ProxyConnection)

response.header.ProxyConnection

Response header: ProxyConnection

rs(Range)

response.header.Range

Response header: Range

rs(Referer)

response.header.Referer

Response header: Referer

rs(Refresh)

response.header.Refresh

Response header: Refresh

93

Volume 8: Access Logging

Table B-6. Access Log Formats (Continued) ELFF

CPL

Custom

Description

rs(Retry-After)

response.header.RetryAfter

Response header: Retry-After

rs(Server)

response.header.Server

Response header: Server

rs(Set-Cookie)

response.header.SetCookie

Response header: Set-Cookie

rs(Set-Cookie2)

response.header.SetCookie2

Response header: Set-Cookie2

rs(TE)

response.header.TE

Response header: TE

rs(Trailer)

response.header.Trailer

Response header: Trailer

rs(TransferEncoding)

response.header.TransferEncoding

Response header: TransferEncoding

rs(Upgrade)

response.header.Upgrade

Response header: Upgrade

rs(User-Agent)

response.header.UserAgent

Response header: User-Agent

rs(Vary)

response.header.Vary

Response header: Vary

rs(Via)

response.header.Via

Response header: Via

rs(WWWAuthenticate)

response.header.WWWAuthenticate

Response header: WWWAuthenticate

rs(Warning)

response.header.Warning

Response header: Warning

rs(X-BlueCoatError)

response.header.XBlueCoat-Error

Response header: X-BlueCoat-Error

rs(X-BlueCoatMC-Client-Ip)

response.header.XBlueCoat-MC-Client-Ip

Response header: X-BlueCoat-MCClient-Ip

rs(X-BlueCoatVia)

response.header.XBlueCoat-Via

Response header: X-BlueCoat-Via

rs(X-ForwardedFor)

response.header.XForwarded-For

Response header: X-Forwarded-For

94

Index

A access logging adding to log file 39 bandwidth management, setting 25 continuous uploading 21 creating/editing log formats 9 custom format, creating/editing 11 log formats 55 custom client configuring 29 port number 30 disabling 18 ELFF format, creating/editing 11 log formats 55 file compression, discussed 21 filename formats 60 FTP upload client editing 27 port number 27 global settings 18 HTTP upload client configuring 28 port number 28 instant messaging format 9 log file creating 15 editing 16 log size, viewing statistics 36 log tail, viewing 36 maximum log size, setting 19 NCSA/common format 9 NCSA/common log format described 59 overriding 39 P2P format 10 PASV, configuring for FTP client 28 policy, using with 39 protocols, using with 17 remote max file size 16 resetting 39 scheduled uploading 21 show list of all logs 35

SQUID format 10 SQUID-compatible format 58 statistics viewing 35, 38 status statistics, viewing 37 streaming format 10 SurfControl client, editing 30 tail options 36 testing upload 35 upload behavior 19 upload client configuring 21 upload compression 25 upload filename, configuring 27 upload schedule configuring overview 33 Websense client port number 31 Websense client, editing 30 access logs digital signing overview 23 verifying 26

B bandwidth management access logging, setting for 25

C common access log format 59 custom client configuring for access logging 29 custom format, creating/editing 11

D digital signing overview 23 verifying 26 document, conventions 8

E ELFF access log formats 55 creating/editing 11

95

Volume 8: Access Logging

Extended Log File Format, see ELFF 55 external certificates, using with digital signing 24

Q

F

R

filename formats, access logging 60 FTP upload client, editing 27

RealMedia, access logging, using with 17

H HTTP upload client, configuring 28 HTTP, access logging, using with 17

I instant messaging, access log format 9

L log file creating 15 editing 16 log format, SSL 10

N NCSA, common access log format 9, 59

P P2P, access log format 10

96

QuickTime, access logging, using with 17

S SQUID access log format 10, 58 SSL, log format 10 statistics access logging log size 36 access logging, status 37 access logging, viewing 35, 38 show list of all logs 35 streaming media, access log format 10 SurfControl, configuring for access logging 30

T troubleshooting show list of all logs 35

W W3C Extended Log File Format, see ELFF 55 Websense upload client, editing 30 Windows Media access logging, using with 17

Blue Coat® Systems SG™ Appliance

Volume 9: Managing the Blue Coat SG Appliance

SGOS Version 5.2.2

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02846 Document Revision: SGOS 5.2.2—09/2007

Contents Contact Information Chapter 1: About Managing the SG Appliance Document Conventions......................................................................................................................................7 Chapter 2: Monitoring the SG Appliance Using Director to Manage SG Systems ............................................................................................................9 Setting up Director and SG Appliance Communication ......................................................................11 Monitoring the System and Disks...................................................................................................................12 System Summary........................................................................................................................................12 Viewing System Environment Sensors ...................................................................................................13 Viewing Disk Status...................................................................................................................................14 Viewing SSL Accelerator Card Information...........................................................................................15 Setting Up Event Logging and Notification ..................................................................................................15 Configuring Which Events to Log ...........................................................................................................15 Setting Event Log Size ...............................................................................................................................16 Enabling Event Notification .....................................................................................................................16 Syslog Event Monitoring...........................................................................................................................17 Viewing Event Log Configuration and Content....................................................................................18 Configuring SNMP ...........................................................................................................................................20 Enabling SNMP ..........................................................................................................................................20 Configuring SNMP Community Strings ................................................................................................21 Configuring SNMP Traps .........................................................................................................................22 Configuring Health Monitoring......................................................................................................................23 Health Monitoring Requirements............................................................................................................23 About the Health Monitoring Metric Types ..........................................................................................24 About Health Monitoring .........................................................................................................................24 About Health Monitoring Notification ...................................................................................................26 About the General Metrics........................................................................................................................26 About the Licensing Metrics.....................................................................................................................26 About the Status Metrics...........................................................................................................................27 Changing Threshold and Notification Properties .................................................................................28 Getting A Quick View of the SG Appliance Health..............................................................................29 Viewing Health Monitoring Statistics.....................................................................................................30 Troubleshooting .........................................................................................................................................31 Chapter 3: Maintaining the SG Appliance Restarting the SG Appliance............................................................................................................................33 Hardware and Software Restart Options ...............................................................................................33 Restoring System Defaults ...............................................................................................................................34

iii

Volume 9: Managing the Blue Coat SG Appliance

Restore-Defaults......................................................................................................................................... 34 Factory-Defaults......................................................................................................................................... 35 Keep-Console.............................................................................................................................................. 35 Clearing the DNS Cache .................................................................................................................................. 36 Clearing the Object Cache................................................................................................................................ 36 Clearing the Byte Cache ................................................................................................................................... 37 Troubleshooting Tip .................................................................................................................................. 37 Clearing Trend Statistics .................................................................................................................................. 37 Upgrading the SG Appliance .......................................................................................................................... 37 The SG Appliance 5.x Version Upgrade................................................................................................. 38 Troubleshooting Tip .................................................................................................................................. 40 Managing SG Appliance Systems................................................................................................................... 40 Setting the Default Boot System .............................................................................................................. 41 Locking and Unlocking SG Appliance Systems.................................................................................... 42 Replacing an SG Appliance System ........................................................................................................ 42 Deleting an SG Appliance System........................................................................................................... 43 Disk Reinitialization ......................................................................................................................................... 43 Multi-Disk SG Appliances ........................................................................................................................ 43 Single-Disk SG Appliance......................................................................................................................... 44 Deleting Objects from the SG Appliance....................................................................................................... 44 Chapter 4: Diagnostics Diagnostic Reporting (Service Information) ................................................................................................. 46 Sending Service Information Automatically.......................................................................................... 46 Managing the Bandwidth for Service Information............................................................................... 47 Configure Service Information Settings ................................................................................................. 48 Creating and Editing Snapshot Jobs ....................................................................................................... 50 Packet Capturing (the Job Utility) .................................................................................................................. 52 PCAP File Name Format........................................................................................................................... 52 Common PCAP Filter Expressions ......................................................................................................... 52 Configuring Packet Capturing................................................................................................................. 53 Core Image Restart Options ............................................................................................................................ 57 Diagnostic Reporting (Heartbeats) ................................................................................................................. 58 Diagnostic Reporting (CPU Monitoring)....................................................................................................... 59 Chapter 5: Statistics Selecting the Graph Scale................................................................................................................................. 61 Viewing Traffic Distribution Statistics........................................................................................................... 62 Understanding Chart Data ....................................................................................................................... 63 Refreshing the Data ................................................................................................................................... 63 About Bypassed Bytes............................................................................................................................... 63 About the Default Service Statistics ........................................................................................................ 64 Viewing Bandwidth Usage or Gain ........................................................................................................ 64 Viewing Client Byte and Server Byte Traffic Distribution .................................................................. 65

iv

Contents

Viewing Traffic History ................................................................................................................................... 65 Understanding Chart Data ....................................................................................................................... 67 Refreshing the Data ................................................................................................................................... 67 About Bypassed Bytes............................................................................................................................... 68 Viewing Bandwidth Usage or Gain or Client Byte and Server Byte Traffic History....................... 68 Viewing the ADN History ............................................................................................................................... 68 Viewing Bandwidth Management Statistics ................................................................................................. 68 Viewing Protocol Statistics .............................................................................................................................. 68 Viewing System Statistics ................................................................................................................................ 70 Resources Statistics .................................................................................................................................... 70 Contents Statistics ...................................................................................................................................... 74 Event Logging Statistics............................................................................................................................ 75 Failover Statistics ....................................................................................................................................... 76 Active Sessions—Viewing Per-Connection Statistics .................................................................................. 76 Analyzing Proxied Sessions ..................................................................................................................... 77 Filtering the Display .................................................................................................................................. 83 Viewing HTML and XML Views of Proxied Sessions Data ................................................................ 84 Analyzing Bypassed Connections Statistics .......................................................................................... 84 Filtering the Display .................................................................................................................................. 86 Viewing HTML and XML Views of Bypassed Connections Data ...................................................... 87 Viewing Health Monitoring Statistics............................................................................................................ 87 Viewing Health Check Statistics ..................................................................................................................... 87 Viewing the Access Log ................................................................................................................................... 87 Viewing Advanced Statistics........................................................................................................................... 87 Using the CLI show Command to View Statistics ....................................................................................... 88 Appendix A: Glossary Index

v

Volume 9: Managing the Blue Coat SG Appliance

vi

Chapter 1: About Managing the SG Appliance

Volume 9: Managing the Blue Coat SG Appliance describes how to monitor the SG appliance with SNMP (a brief introduction to Director is provided), event logging, or health monitoring. It also describes common maintenance and troubleshooting tasks. Discussed in this volume: ❐

Chapter 2: "Monitoring the SG Appliance"

❐

Chapter 3: "Maintaining the SG Appliance"

❐

Chapter 4: "Diagnostics"

❐

Chapter 5: "Statistics"

❐

Appendix A: "Glossary"

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

7

Volume 9: Managing the Blue Coat SG Appliance

8

Chapter 2: Monitoring the SG Appliance

This chapter describes the methods you can use to monitor your SG appliances, including event logging, SNMP, and health monitoring. A brief introduction to Director is also provided. This chapter contains the following sections: ❐

“Using Director to Manage SG Systems” on page 9

❐

“Monitoring the System and Disks” on page 12

❐

“Setting Up Event Logging and Notification” on page 15

❐

“Configuring SNMP” on page 20

❐

“Configuring Health Monitoring” on page 23

Using Director to Manage SG Systems Blue Coat Director allows you to manage multiple SG appliances, eliminating the need to configure and control the appliances individually. Director allows you to configure an SG appliance and then push that configuration out to as many appliances as required. Director also allows you to delegate network and content control to multiple administrators and distribute user and content policy across a Content Delivery Network (CDN). With Director, you can: ❐

Reduce management costs by centrally managing all Blue Coat appliances.

❐

Eliminate the need to manually configure each remote SG appliance.

❐

Recover from system problems with configuration snapshots and recovery.

Automatically Registering the SG Appliance with Director You can use the Blue Coat Director registration feature to automatically register the SG appliance with a Blue Coat Director, thus enabling that Director to establish a secure administrative session with the appliance. During the registration process, Director can “lock out” all other administrative access to the appliance so that all configuration changes are controlled and initiated by Director. This is useful if you want to control access to the appliance or if you want to ensure that appliances receive the same configuration. The registration process is fully authenticated; the devices use their Blue Coat appliance certificate or a shared secret (a registration password configured on Director) to confirm identities before exchanging public keys. If the SG appliance has an appliance certificate, that certificate is used to authenticate the SG appliance to Director as an SSL client. If the SG appliance does not have an appliance certificate, you must configure a registration secret on Director and specify that secret on the SG appliance. Refer to the Blue Coat Director Configuration and Management Guide for more information about specifying the shared secret.

9

Volume 9: Managing the Blue Coat SG Appliance

Note: The Blue Coat appliance certificate is an X.509 certificate that contains the

hardware serial number of a specific SG device as the Common Name (CN) in the subject field. Refer to the device authentication information in Volume 5: Advanced Networking for more information about appliance certificates.

Director Registration Requirements To register the appliance with Director, the SSH-Console service must be enabled. Director registration will fail if the ssh-console has been disabled or deleted, or if the SSHv2 host key has been removed. Registering the SG Appliance with Director Though usually initiated at startup (with the serial console setup), you can also configure Director registration from the Management Console, as described in the following procedure. To register the appliance with a Director: 1.

Select Maintenance > Director Registration.

2.

In the Director IP address field, enter the Director IP address.

3.

In the Director serial number field, enter the Director serial number or click Retrieve S/N from Director. If you retrieve the serial number from the Director, verify that the serial number matches the one specified for your Director.

4.

Optional—In the Appliance name field, enter the SG appliance name.

5.

If your appliance does not have an appliance certificate, enter the Director shared secret in the Registration password field. Note: Refer to the Blue Coat Director Configuration and Management Guide for more information about configuring the shared secret. For information about appliance certificates, refer to Volume 5: Advanced Networking.

6.

Click Register.

Related CLI Commands for Director Registration SGOS# register-with-director dir_ip_address [appliance_name dir_serial_number]

10

Chapter 2: Monitoring the SG Appliance

Setting up Director and SG Appliance Communication Director and the SG appliance use SSHv2 as the default communication mode. SSHv1 is not supported. For Director to successfully manage multiple appliances, it must be able to communicate with an appliance using SSH/RSA and the Director’s public key must be configured on each system that Director manages. When doing initial setup of the SG appliance from Director, Director connects to the device using the authentication method established on the device: SSH with simple authentication or SSH/RSA. SSH/RSA is preferred, and must also be set up on Director before connecting to the SG appliance. Director can create an RSA keypair for an SG appliance to allow connections. However, for full functionality, Director’s public key must be configured on each appliance. You can configure the key on the system using the following two methods: ❐

Use Director to create and push the key.

❐

Use the import-director-client-key CLI command from the SG appliance.

Using Director to create and push client keys is the recommended method. The CLI command is provided for reference. Complete the following steps to put Director’s public key on the SG appliance using the CLI of the appliance. You must complete this procedure from the CLI. The Management Console is not available. Note: For information on creating and pushing a SSH keypair on Director, refer to the Blue Coat Director Installation Guide.

Log in to the SG appliance you want to manage from Director. 1.

From the (config) prompt, enter the ssh-console submode: SGOS#(config) ssh-console SGOS#(config ssh-console)

2.

Import Director’s key that was previously created on Director and copied to the clipboard. Important:

You must add the Director identification at the end of the client key. The example shows the username, IP address, and MAC address of Director. “Director” (without quotes) must be the username, allowing you access to passwords in clear text.

SGOS#(config services ssh-console) inline director-client-key Paste client key here, end with "..." (three periods) ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvJIXt1ZausE9qrcXem2IK/mC4dY8Cxxo1/ B8th4KvedFY33OByO/pvwcuchPZz+b1LETTY/zc3SL7jdVffq00KBN/ ir4zu7L2XT68ML20RWa9tXFedNmKl/iagI3/QZJ8T8zQM6o7WnBzTvMC/ ZElMZZddAE3yPCv9+s2TR/[email protected] ... ok

To view the fingerprint of the key: SGOS#(config sshd) view director-client-key clientID [email protected] 83:C0:0D:57:CC:24:36:09:C3:42:B7:86:35:AC:D6:47

11

Volume 9: Managing the Blue Coat SG Appliance To delete a key: SGOS#(config sshd) delete director-client-key clientID

Monitoring the System and Disks The System and disks page in the Management Console has the following tabs: ❐

Summary

Provides configuration information and a general status information about the device. ❐

Tasks

Enables you to perform systems tasks, such as restarting the system and clearing the DNS or object cache. See Chapter 3: "Maintaining the SG Appliance" for information about these tasks. ❐

Environment

Displays hardware statistics. ❐

Disks

Displays details about the installed disks and enables you take them offline. ❐

SSL Cards

Displays details about any installed SSL cards. These statistics are also available in the CLI. Note: The SG 400 appliances do not have an Environment tab.

System Summary The device provides a variety of information on its status. The fields on the Summary tab are described below: ❐

Disks Installed—the number of disk drives installed in the device. The Disks tab

displays the status of each drive. ❐

Memory installed—the amount of RAM installed in the device.

❐

CPUs installed—the number of CPUs installed in the device.

❐

Software image—the version and release number of the device image.

❐

Serial number—the serial number of the machine, if available.

❐

System started—the time and date the device was started.

❐

CPU utilization—the current percent utilization of the device CPU.

To view the system summary statistics: Select Maintenance > System and disks > Summary.

12

Chapter 2: Monitoring the SG Appliance

Viewing System Environment Sensors The icons on the Environment tab are green when the related hardware environment is within acceptable parameters, and red when an out-of-tolerance condition exists. If an icon is red, click View Sensors to view detailed sensor statistics to learn more about the out-of-tolerance condition. Note: The health monitoring metrics on the Statistics > Health page also show the state

of environmental sensors. See “Configuring Health Monitoring” on page 23 for more information.

Note: You cannot view environment statistics on an SG 400 appliance.

To view the system environment statistics: 1.

Select Maintenance > System and disks > Environment. Note: This tab varies depending on the type of SG appliance that you are using.

2.

Click View Sensors to see detailed sensor values; close the window when you are finished.

13

Volume 9: Managing the Blue Coat SG Appliance

Viewing Disk Status You can view the status of each of the disks in the system and take a disk offline if needed. To view disk status or take a disk offline: 1.

Select Maintenance > System and disks > Environment. The default view provides information about the disk in slot 1. Note: The name and appearance of this tab differs, depending on the range of disks available to the SG appliance model you use.

2.

Select the disk to view or to take offline by clicking the appropriate disk icon.

3.

(Optional) To take the selected disk offline, click the Take disk x offline button (where x is the number of the disk you have selected); click OK in the Take disk offline dialog that displays.

14

Chapter 2: Monitoring the SG Appliance

Viewing SSL Accelerator Card Information Selecting the Maintenance > System and disks > SSL Cards tab allows you to view information about any SSL accelerator cards in the system. If no accelerator cards are installed, that information is stated on the pane. To view SSL accelerator cards: Note:

You cannot view statistics about SSL accelerator cards through the CLI.

Select Maintenance > System and disks > SSL Cards.

Setting Up Event Logging and Notification You can configure the SG appliance to log system events as they occur. Event logging allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by e-mail if an event is logged.

Configuring Which Events to Log The event level options are listed from the most to least important events. Because each event requires some disk space, setting the event logging to log all events fills the event log more quickly. To set the event logging level: 1.

Select Maintenance > Event Logging > Level.

2.

Select the events you want to log. When you select an event level, all levels above the selection are included. For example, if you select Verbose, all event levels are included.

3.

Click Apply.

15

Volume 9: Managing the Blue Coat SG Appliance

Related CLI Commands for Setting the Event Logging Level SGOS#(config event-log) level {severe | configuration | policy | informational | verbose} Table 2-1. Event Logging Level Options severe

Writes only severe error messages to the event log.

configuration

Writes severe and configuration change error messages to the event log.

policy

Writes severe, configuration change, and policy event error messages to the event log.

informational

Writes severe, configuration change, policy event, and information error messages to the event log.

verbose

Writes all error messages to the event log.

Setting Event Log Size You can limit the size of the appliances’s event log and specify what the appliance should do if the log size limit is reached. To set event log size: 1.

Select Maintenance > Event Logging > Size.

2.

In the Event log size field, enter the maximum size of the event log in megabytes.

3.

Select either Overwrite earlier events or Stop logging new events to specify the desired behavior when the event log reaches maximum size.

4.

Click Apply.

Related CLI Commands to Set the Event Log Size SSGOS#(config event-log) log-size megabytes SGOS#(config event-log) when-full {overwrite | stop}

Enabling Event Notification The SG appliance can send event notifications to Internet e-mail addresses using SMTP. You can also send event notifications directly to Blue Coat for support purposes. For information on configuring diagnostic reporting, see Chapter 4: "Diagnostics".

16

Chapter 2: Monitoring the SG Appliance

Note: The SG appliance must know the host name or IP address of your SMTP mail

gateway to mail event messages to the e-mail address(es) you have entered. If you do not have access to an SMTP gateway, you can use the Blue Coat default SMTP gateway to send event messages directly to Blue Coat. The Blue Coat SMTP gateway only sends mail to Blue Coat. It will not forward mail to other domains. To enable event notifications: 1.

Select Maintenance > Event Logging > Mail.

2.

Click New to add a new e-mail address; click OK in the Add list item dialog that appears.

3.

In the SMTP gateway name field, enter the host name of your mail server; or in the SMTP gateway IP field, enter the IP address of your mail server.

4.

(Optional) If you want to clear one of the above settings, select the radio button of the setting you want to clear. You can clear only one setting at a time.

5.

Click Apply.

Related CLI Commands to Enable Event Notifications SGOS#(config event-log) mail add email_address

Syslog Event Monitoring Syslog is an event-monitoring scheme that is especially popular in UNIX environments. Sites that use syslog typically have a log host node, which acts as a sink (repository) for several devices on the network. You must have a syslog daemon operating in your network to use syslog monitoring. The syslog format is: Date Time Hostname Event. Most clients using syslog have multiple devices sending messages to a single syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the syslog daemon. An event on one network device might trigger an event on other network devices, which, on occasion, can point out faulty equipment.

17

Volume 9: Managing the Blue Coat SG Appliance To enable syslog monitoring: 1.

Select Maintenance > Event Logging > Syslog.

2.

In the Loghost field, enter the domain name or IP address of your loghost server.

3.

Select Enable Syslog.

4.

Click Apply.

Related CLI Commands to Enable Syslog Monitoring SGOS#(config event-log) syslog {disable | enable}

Viewing Event Log Configuration and Content You can view the system event log, either in its entirety or selected portions of it.

Viewing the Event Log Configuration You can view the event log configuration, from show or from view in the event-log configuration mode. To view the event log configuration: At the prompt, enter the following command: ❐

From anywhere in the CLI SGOS> show event-log configuration Settings: Event level: severe + configuration + policy + informational Event log size: 10 megabytes If log reaches maximum size, overwrite earlier events Syslog loghost: Syslog notification: disabled Syslog facility: daemon Event recipients: SMTP gateway: mail.heartbeat.bluecoat.com

-or❐

From the (config) prompt: SGOS#(config) event-log SGOS#(config event-log) view configuration Settings: Event level: severe + configuration + policy + informational Event log size: 10 megabytes If log reaches maximum size, overwrite earlier events Syslog loghost:

18

Chapter 2: Monitoring the SG Appliance

Syslog notification: disabled Syslog facility: daemon Event recipients: SMTP gateway: mail.heartbeat.bluecoat.com

Viewing the Event Log Contents Again, you can view the event log contents from the show command or from the event-log configuration mode. The syntax for viewing the event log contents is SGOS# show event-log -orSGOS# (config event-log) view [start [YYYY-mm-dd] [HH:MM:SS]] [end [YYYY-mm-dd] [HH:MM:SS]] [regex regex | substring string]

Pressing shows the entire event log without filters. The order of the filters is unimportant. If start is omitted, the start of the recorded event log is used. If end is omitted, the end of the recorded event log is used. If the date is omitted in either start or end, it must be omitted in the other one (that is, if you supply just times, you must supply just times for both start and end, and all times refer to today). The time is interpreted in the current timezone of the appliance. Understanding the Time Filter The entire event log can be displayed, or either a starting date/time or ending date/time can be specified. A date/time value is specified using the notation ([YYYY-MM-DD] [HH:MM:SS]). Parts of this string can be omitted as follows: ❐

If the date is omitted, today's date is used.

❐

If the time is omitted for the starting time, it is 00:00:00

❐

If the time is omitted for the ending time, it is 23:59:59

At least one of the date or the time must be provided. The date/time range is inclusive of events that occur at the start time as well as dates that occur at the end time. Note: If the notation includes a space, such as between the start date and the start time,

the argument in the CLI should be quoted. Understanding the Regex and Substring Filters A regular expression can be supplied, and only event log records that match the regular expression are considered for display. The regular expression is applied to the text of the event log record not including the date and time. It is case-sensitive and not anchored. You should quote the regular expression. Since regular expressions can be difficult to write properly, you can use a substring filter instead to search the text of the event log record, not including the date and time. The search is case sensitive. Regular expressions use the standard regular expression syntax as defined by policy. If both regex and substring are omitted, then all records are assumed to match.

19

Volume 9: Managing the Blue Coat SG Appliance

Example SGOS# show event-log start "2004-10-22 9:00:00" end "2004-10-22 9:15:00" 2004-10-22 09:00:02+00:00UTC sysinfo-stats " 0 2D0006:96

"Snapshot sysinfo_stats has fetched / ../Snapshot_worker.cpp:183

2004-10-22 09:05:49+00:00UTC "NTP: Periodic query of server ntp.bluecoat.com, system clock is 0 seconds 682 ms fast compared to NTP time. Updated system clock. " 0 90000:1 ../ntp.cpp:631

Configuring SNMP You can view an SG appliance using a Simple Network Management Protocol (SNMP) management station. The appliance supports MIB-2 (RFC 1213), Proxy MIB, and the RFC2594 MIB, and can be downloaded at the following URL: https:// download.bluecoat.com/release/SGOS5/index.html (The SNMP link is in the lower right-hand corner.).

Enabling SNMP To view an SG appliance from an SNMP management station, you must enable and configure SNMP support on the appliance. To enable and configure SNMP: 1.

Select Maintenance > SNMP > SNMP General.

2.

Select Enable SNMP.

3.

(Optional) To reset the SNMP configuration to the defaults, click Reset SNMP settings. This erases any trap settings that were set as well as any community strings that had been created. You do not need to reboot the system after making configuration changes to SNMP.

4.

In the sysLocation field, enter a string that describes the appliance’s physical location.

5.

In the sysContact field, enter a string that identifies the person responsible for administering the appliance.

Related CLI Commands to Enable and Configure SNMP SGOS#(config snmp) {disable | enable} SGOS #(config snmp) sys-contact string SGOS#(config snmp) sys-location string

20

Chapter 2: Monitoring the SG Appliance

Configuring SNMP Community Strings Use community strings to restrict access to SNMP data. To read SNMP data on the SG appliance, specify a read community string. To write SNMP data to the appliance, specify a write community string. To receive traps, specify a trap community string. By default, all community string passwords are set to public. Note: If you enable SNMP, make sure to change all three community-string passwords to values that are difficult to guess. Use a combination of uppercase, lowercase, and numeric characters. An easily-guessed community-string password makes it easier to gain unauthorized access to the SG appliance and network.

To set or change community strings: 1.

Select Maintenance > SNMP > Community Strings.

2.

Click the community string button you want to change. The Change Read/Write/Trap Community dialog displays.

3.

Enter and confirm the community string; click OK.

4.

Click Apply.

To set or change community strings: You can set the community strings in either cleartext or encrypted form. To set them in cleartext: SGOS#(config) snmp SGOS#(config snmp) enable SGOS#(config snmp) read-community password SGOS#(config snmp) write-community password

21

Volume 9: Managing the Blue Coat SG Appliance

SGOS#(config snmp) trap-community password

To set them as encrypted: SGOS#(config) snmp SGOS#(config snmp) enable SGOS#(config snmp) encrypted-read-community encrypted-password SGOS#(config snmp) encrypted-write-community encrypted-password SGOS#(config snmp) encrypted-trap-community encrypted-password

Configuring SNMP Traps The SG appliance can send SNMP traps to a management station as they occur. By default, all system-level traps are sent to the address specified. You can also enable authorization traps to send notification of attempts to access the Management Console. Also, if the system crashes for whatever reason, a cold start SNMP trap is issued on power up. No configuration is required. Note: The SNMP trap for CPU utilization is sent only if the CPU continues to stay up for 32 or more seconds.

To enable SNMP traps: Note: You cannot configure SNMP traps to go out through a particular interface. The interface that is configured first is used until it fails and is used to identify the device.

1.

Select Maintenance > SNMP > Traps.

2.

In the Send traps to fields, enter the IP address(es) of the workstation(s) where traps are to be sent.

3.

To receive authorization traps, select Enable authorization traps.

4.

Select Apply to commit the changes to the SG appliance.

Related CLI Commands for Enabling SNMP Traps SGOS#(config snmp) trap-address {1 | 2 | 3} ip_address

Indicates which IP address(es) can receive traps and in which priority. SGOS#(config snmp) authorize-traps

22

Chapter 2: Monitoring the SG Appliance

Configuring Health Monitoring The health monitoring feature tracks key hardware and software metrics so that you can can quickly discover and diagnose potential problems. Director (and other third-party network management tools) also use these metrics to remotely display the current state of the SG appliance. By monitoring these key hardware and software metrics, Director can display a variety of health-related statistics—and trigger notification if action is required.

Figure 2-1. Health Monitoring Configuration and Notification Process

As shown in the preceding figure, health monitoring metrics can be remotely configured and queried from Director. The metrics are also configurable on the SG appliance itself. To facilitate prompt corrective action, notification can be configured for threshold “events.” For example, an administrator can configure a threshold so that an e-mail or SNMP trap is generated when the threshold state changes. Additionally, many of the threshold levels are configurable so that you can adjust the thresholds to meet your specific requirements.

Health Monitoring Requirements Before using the health monitoring feature you must ensure that the e-mail addresses of all persons that should be notified of health monitoring alerts are listed in the Event log properties. See “Setting Up Event Logging and Notification” on page 15 for more information.

23

Volume 9: Managing the Blue Coat SG Appliance

About the Health Monitoring Metric Types The SG appliance monitors the following types of health metrics: ❐

Hardware

❐

Environmental

❐

ADN

❐

System resource

❐

Licensing metrics

The system resource and licensing thresholds are user-configurable, meaning that you can specify the threshold level that will trigger an alert. The hardware, environmental, and ADN metrics are not configurable and are preset to optimal values. For example, on some platforms, a Warning is triggered when the CPU temperature reaches 55 degrees Celsius. These health monitoring metrics are logically grouped as General, Licensing, or Status metrics.

About Health Monitoring Health Monitoring allows you to set notification thresholds on various internal metrics that track the health of a monitored system or device. Each metric has a value and a state. The value is obtained by periodically measuring the monitored system or device. In some cases, the value is a percentage or a temperature measurement; in other cases, it is a status like "Disk Present" or "Awaiting Approval". The state indicates the severity of the metric as a health issue: ❐

OK—The monitored system or device is behaving normally.

❐

WARNING—The monitored system or device is outside typical operating parameters and may require attention.

❐

CRITICAL—The monitored system or device is either failing, or is far outside normal parameters, and requires immediate attention.

The current state of a metric is determined by the relationship between the value and its monitoring thresholds. The Warning and Critical states have thresholds, and each threshold has a corresponding interval. All metrics begin in the OK state. If the value crosses the Warning threshold and remains there for the threshold's specified interval, the metric transitions to the Warning state. Similarly, if the Critical threshold is exceeded for the specified interval, the metric transitions to the Critical state. Later (for example, if the problem is resolved), the value may drop back down below the Warning threshold. If the value stays below the Warning threshold longer than the specified interval, the state returns to OK. Every time the state changes, a notification occurs. If the value fluctuates above and below a threshold, no state change occurs until the value stays above or below the threshold for the specified interval. This behavior helps to ensure that unwarranted notifications are avoided when values vary widely without having any definite trend. You can experiment with the thresholds and intervals until you are comfortable with the sensitivity of the notification settings.

24

Chapter 2: Monitoring the SG Appliance

Health Monitoring Example The following picture shows an example. The lower horizontal line represents the Warning threshold; the upper horizontal line is the Critical threshold. Note how they divide the graph into bands associated with each of the three possible states. Assume both thresholds have intervals of 20 seconds, and that the metric is currently in the OK state. 1.

At time 0, the monitored value crosses the Warning threshold. No transition occurs yet. Later, at time 10, it crosses the critical threshold. Still, no state change occurs, because the threshold interval has not elapsed.

2.

At time 20, the value has been above the warning threshold for 20 seconds--the specified interval. The state of the metric now changes to Warning, and a notification is sent. Note that even though the metric is currently in the critical range, the State is still Warning, because the value has not exceeded the Critical threshold long enough to trigger a transition to Critical.

3.

At time 25, the value drops below the Critical threshold, having been above it for only 15 seconds. The state remains at Warning.

4.

At time 30, it drops below the Warning threshold. Again the state does not change. If the value remains below the warning threshold until time 50, then the state will change back to OK.

OK

Value

WARRNING

CRITICAL

20 seconds above the Warning threshold a Warning notification is sent

0

5

10

15

20

25

30

35

40

45

50

55

60

Time Figure 2-2. Relationship between the threshold value and threshold interval

About License Expiration Metrics The threshold values for license expiration metrics are set in days until expiration. In this context, a "critical" threshold indicates that license expiration is imminent. This is the only configurable metric in which the Critical threshold value should be smaller than the Warning threshold value. For example, if you set the Warning threshold to 45, an alert is sent when there are 45 days remaining in the license period. The Critical threshold would be less than 45 days, for example 5 days.

25

Volume 9: Managing the Blue Coat SG Appliance

For the license expiration metrics, the threshold interval is irrelevant and is set by default to 0. You should set the Warning Threshold to a value that will give you ample time to renew your license. By default, all license expiration metrics have a Warning Threshold of 30 days. By default, the Critical Threshold is configured to 0, which means that a trap is immediately sent upon license expiration.

About Health Monitoring Notification By default, the Director polls the SG appliances to determine their current state. If the state has changed, Director updates the device status. Other types of notification are also available. Any or all of the following types of notification can be set: ❐

SNMP trap: Sends an SNMP trap to all configured management stations.

❐

E-mail: Sends e-mail to all persons listed in the Event log properties.

❐

Log: Inserts an entry into the Event log. See “Setting Up Event Logging and Notification” on page 15 for more information.

About the General Metrics The following table lists the metrics displayed in the Maintenance > Health Monitoring > General page. The thresholds for these metrics are user-configurable. See “About Health Monitoring” on page 24 for information about thresholds and alert notification. All threshold intervals are in seconds. Table 2-2. General Health Monitoring Metrics Metric

Units

Default Thresholds/Intervals

Notes

CPU Utilization

Percentage

Critical: 95%/120 seconds

Measures the value of CPU 0 on multi-processor systems-not the average of all CPU activity.

Warning: 80%/120 seconds Memory Pressure

Percentage

Critical: 95%/120 seconds Warning: 90%/120 seconds

Interface Utilization

Percentage

Critical: 90%/120 seconds Warning: 60%/120 seconds

Memory pressure occurs when memory resources become limited, causing new connections to be delayed. Measures the traffic (in and out) on the interface to determine if it is approaching the bandwidth maximum.

About the Licensing Metrics The following table lists the metrics displayed in the Maintenance > Health Monitoring > Licensing page. You can monitor User License utilization metrics and the following license expiration metrics: ❐

SGOS Base License: Licenses not listed here are part of the SGOS base license.

❐

SSL Proxy

❐

SG Client

26

Chapter 2: Monitoring the SG Appliance

See “About License Expiration Metrics” on page 25 for information licensing thresholds. Metric

Units

Default Thresholds/Intervals

Notes

License Utilization

Percentage

Critical: 100%/0

For licenses that have user limits, monitors the number of users.

Warning: 90%/0 License Expiration

Days

Critical: 0 days/0 Warning: 30 days/0

Warns of impending license expiration. For license expiration metrics, intervals are ignored. See “About the Licensing Metrics” on page 26 for more information.

About the Status Metrics The following table lists the metrics displayed in the Maintenance > Health Monitoring > Status page. The thresholds for these metrics are not user-configurable. Table 2-3. Status Health Monitoring Metrics Metric

Threshold States and Corresponding Values

Disk status

Critical: Bad Warning: Removed Offline OK: Not Present Present

Temperature Bus temperature CPU temperature

Critical: High-critical Warning: High-warning

Fan

Critical:

(The fan metric differs by hardware model, for example, CPU fan, chassis fan)

Low-critical Warning: Low-warning

27

Volume 9: Managing the Blue Coat SG Appliance

Table 2-3. Status Health Monitoring Metrics (Continued) Voltage

Critical:

Bus Voltage CPU voltage Power Supply voltage

Critical High-critical Low-critical Warning: High-warning Low-warning

ADN Connection Status

OK: Connected Connecting Connection Approved Disabled Not Operational Warning: Approval Pending Mismatching Approval Status Partially Connected Critical: Not Connected Connection Rejected See Volume 5: Advanced Networking for more information about the ADN metrics.

ADN Manager Status

OK: No Approvals Pending Not Applicable Warning: Approvals Pending

Changing Threshold and Notification Properties The health monitoring threshold and notification properties are set by default. Use the following procedure to modify the current settings. To change the threshold and notification properties: 1.

Select Maintenance > Health Monitoring.

2.

Do one of the following: •

To change the system resource metrics, select General.

•

To change the hardware/environmental/ADN metrics, select Status. Note: You cannot change the threshold values for metrics in the Status tab.

• 3.

To change the licensing metrics, select Licensing.

Select the metric you want to modify.

28

Chapter 2: Monitoring the SG Appliance

4.

Click Edit to modify the threshold and notification settings. The Edit Health Monitor Setting dialog displays. (hardware, environmental, and ADN thresholds cannot be modified.)

5a 5b 5c 5d

6

5.

Modify the threshold values: a.

To change the critical threshold, enter a new value in the Critical Threshold field.

b.

To change the critical interval, enter a new value in the Critical Interval field.

c.

To change the warning threshold, enter a new value in the Warning Threshold field.

d. To change the warning interval, enter a new value in the Warning Interval field. 6.

Modify the notification settings. •

Log adds an entry to the Event log.

•

Trap sends an SNMP trap to all configured management stations.

•

Email sends an e-mail to the addresses listed in the Event log properties. See “Setting Up Event Logging and Notification” on page 15 for more information.

7.

Click OK to close the Edit Metric dialog.

8.

Click Apply.

Related CLI Syntax to Modify Threshold and Notification Properties #(config) alert threshold metric_name warning_threshold warning_interval critical_threshold critical_interval #(config) alert notification metric_name notification_method

where metric_name refers to cpu-utilization, license-utilization, licenseexpiration, memory-pressure, or network-utilization.

Getting A Quick View of the SG Appliance Health The Management Console uses the health monitoring metrics to display a visual representation of the overall health state of the SG appliance. The health icon is located in the upper right corner of the Management Console and is always visible.

29

Volume 9: Managing the Blue Coat SG Appliance

System health is determined by calculating the “aggregate” health status of the following metrics: ❐

CPU Utilization

❐

Memory Pressure

❐

Network interface utilization

❐

Disk status (for all disks)

❐

License expiration

❐

License “user count” utilization (when applicable)

❐

ADN status

The possible health states are OK, Warning, or Critical. Clicking the health icon displays the Statistics > Health page, which lists the current condition of the system’s health monitoring metrics, as described in the next section.

Viewing Health Monitoring Statistics While the health icon presents a quick view of the appliance health, the Statistics > Health Monitoring page enables you to get more details about the current state of the health monitoring metrics. To review the health monitoring statistics: 1.

From the Management Console, select Statistics > Health Monitoring. 2

3

2.

3.

Select a health monitoring statistics tab: •

General: Lists the current state of CPU utilization, interface utilization, memory pressure, and disk status metrics.

•

Licensing: Lists the current state of license utilization and expiration metrics.

•

Status: Lists the current state of all metrics.

To get more details about a metric, highlight the metric and click View. The View Metrics Detail dialog displays.

30

Chapter 2: Monitoring the SG Appliance

4

4.

Click Close to close the View Metrics Detail dialog.

5.

Optional—If you want to modify a metric, highlight the metric and click Set Thresholds. The Maintenance > Health Monitoring page displays. To modify the metric, follow the procedure describe in “Changing Threshold and Notification Properties” on page 28.

Related CLI Syntax to View Health Monitoring Statistics SGOS#(config) show system-resource-metrics

The show system-resource-metrics command lists the state of the current system resource metrics. Notification varies by platform. If you try to set notification for a metric that does not support notification, you will see the following error message: Sensor not supported on this platform

Depending on the platform, the metrics displayed by the show system-resourcemetrics command might differ from the metric names listed in the alert command output. For example, the bus-temperature metric can be shown as motherboard temperature in the show system-resources-metrics output. If you are setting notification from the Management Console, you can verify the category by clicking the Preview button to view the CLI output.

Troubleshooting If you continue to receive alerts, contact Blue Coat Technical Support. For licensing questions, contact Blue Coat Support Services. It is helpful to obtain a packet capture for CPU, memory pressure, and network interface issues, before calling Technical Support. Table 2-4. Technical Support and Support Services Contact Information Blue Coat Technical Support Blue Coat Support Services

http://www.bluecoat.com/support/contact.html http://www.bluecoat.com/support/services/index.html

31

Volume 9: Managing the Blue Coat SG Appliance

32

Chapter 3: Maintaining the SG Appliance

This chapter describes how to maintain the SG appliance; for example, restarting the appliance, restoring system defaults, upgrading the appliance, and reinitializing disks. This chapter contains the following sections: ❐

“Restarting the SG Appliance” on page 33

❐

“Restoring System Defaults” on page 34

❐

“Clearing the DNS Cache” on page 36

❐

“Clearing the Object Cache” on page 36

❐

“Clearing the Byte Cache” on page 37

❐

“Clearing Trend Statistics” on page 37

❐

“Upgrading the SG Appliance” on page 37

❐

“Managing SG Appliance Systems” on page 40

❐

“Disk Reinitialization” on page 43

❐

“Deleting Objects from the SG Appliance” on page 44

Restarting the SG Appliance The restart options control the restart attributes of the SG appliance if a restart is required because of a system fault. Important:

The default settings of the Restart option suits most systems. Changing them without assistance from Blue Coat Systems Technical Support is not recommended.

Hardware and Software Restart Options The Restart settings determine if the SG appliance does a faster software-only restart, or a more comprehensive hardware and software restart. The latter can take several minutes longer, depending upon the amount of memory and number of disk drives in the appliance. The default setting of Software only suits most situations. Restarting both the hardware and software is recommended in situations where a hardware fault is suspected. For information about the Core Image settings, see “Core Image Restart Options” on page 57. Note: If you change restart option settings and you want them to apply to the next SG appliance restart, click Apply.

To restart the SG appliance: 1.

Select Maintenance > System and disks > Tasks.

33

Volume 9: Managing the Blue Coat SG Appliance

2.

In the Restart field, select either Software only or Hardware and software.

3.

If you select the Hardware and software option, select a system from the System to run drop-down list. The default system is pre-selected.

4.

Click Apply.

5.

Click Restart now.

6.

Click OK to confirm and restart the SG appliance.

Related CLI Syntax to Configure the Hardware/Software Restart Settings SGOS#(config) restart mode {hardware | software} SGOS# restart abrupt SGOS# restart regular SGOS# restart upgrade

Restoring System Defaults SGOS allows you to restore some or all of the system defaults. Use these commands with caution. The restore-defaults command deletes most, but not all, system defaults: ❐

The restore-defaults command with the factory-defaults option reinitializes the SG appliance to the original settings it had when it was shipped from the factory.

❐

The restore-defaults command with the keep-console option allows you to restore default settings without losing all IP addresses on the system.

Restore-Defaults Settings that are deleted when you use the restore-defaults command include: ❐

All IP addresses (these must be restored before you can access the Management Console again).

❐

DNS server addresses (these must be restored through the CLI before you can access the Management Console again).

❐

Installable lists.

❐

All customized configurations.

34

Chapter 3: Maintaining the SG Appliance

❐

Third-party vendor licenses, such as SmartFilter or Websense. If you use the restore-defaults command after you have installed licenses, and the serial number of your system is configurable (older boxes only), the licenses fails to install and the SG appliance returns to the trial period (if any time is left). To correct the problem, you must configure your serial number and install your license-key again.

❐

Blue Coat trusted certificates.

❐

Original SSH (v1 and v2) host keys (new host keys are regenerated).

You can use the force option to restore defaults without confirmation.

Factory-Defaults All system settings are deleted when you use the restore-defaults command with the factory-defaults option. The only settings that are kept when you use the restore-defaults command with the factory-defaults option are: ❐

Trial period information.

❐

The last five installed appliance systems, from which you can pick one for rebooting.

The Setup Console password is also deleted if you use restore-defaults factorydefaults. For information on the Setup Console password, refer to Volume 4: Securing the Blue Coat SG Appliance. You can use the force option to restore defaults without confirmation.

Keep-Console Settings that are retained when you use the restore-defaults command with the keepconsole option include: ❐

IP interface settings, including VLAN configuration.

❐

Default gateway and static routing configuration.

❐

Virtual IP address configuration.

❐

TCP round trip time settings.

❐

Bridging settings.

❐

Failover group settings.

Using the keep-console option retains the settings for all consoles (Telnet, SSH, HTTP, and HTTPS), whether they are enabled, disabled, or deleted. Administrative access settings retained using the restore-defaults command with the keep-console option include: ❐

Console username and password.

❐

Front panel pin number.

❐

Console enable password.

❐

SSH (v1 and v2) host keys.

❐

Keyrings used by secure console services.

❐

RIP configurations.

You can also use the force option to restore defaults without confirmation.

35

Volume 9: Managing the Blue Coat SG Appliance To restore system defaults: Note: The keep-console and factory-defaults options are not available through

the Management Console. 1.

Select Maintenance > System and disks > Tasks.

2.

From the Tasks field, click Restore the configuration to defaults. If you restore the configuration from the Management Console, most settings are lost because you cannot use the keep-console option. The Restore Configuration dialog appears.

3.

Click OK.

Related CLI Syntax to Restore System Defaults SGOS# restore-defaults [keep-console] SGOS# restore-defaults [keep-console] force SGOS# restore-defaults factory-defaults

Clearing the DNS Cache You can clear the DNS cache at any time. You might need to do so if you have experienced a problem with your DNS server or if you have changed your DNS configuration. To clear the DNS cache: 1.

Select Maintenance > System and disks > Tasks.

2.

In the Tasks field, click Clear next to “the DNS cache.”

3.

Click OK to confirm in the Clear system DNS cache dialog that appears.

Related CLI Syntax to Clear the DNS Cache SGOS# clear-cache dns-cache

Clearing the Object Cache You can clear the object cache at any time. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the source before it is served.

36

Chapter 3: Maintaining the SG Appliance

To clear the object cache: 1.

Select Maintenance > System and disks > Tasks.

2.

In the Tasks field, click Clear next to “the object cache.”

3.

Click OK to confirm in the Clear cache dialog that appears.

Related CLI Syntax to Clear the Object Cache SGOS# clear-cache object-cache

Clearing the Byte Cache You can clear the byte cache at any time. You might want to do this for testing purposes. To clear the byte cache: 1.

Select Maintenance > System and disks > Tasks.

2.

In the Tasks field, click Clear next to “the byte cache.”

3.

Click OK to confirm in the Clear Byte Cache dialog that appears.

Related CLI Syntax to Clear the Byte Cache SGOS# clear-cache byte-cache

Troubleshooting Tip Occasionally, the Management Console might behave incorrectly because of browser caching, particularly if the browser was used to run different versions of the Management Console. This problem might be resolved by clearing the browser cache.

Clearing Trend Statistics You can clear all persistent trend statistics at any time. To clear all persistent statistics: 1.

Select Maintenance > System and disks > Tasks.

2.

In the Tasks field, click Clear next to “the trend statistics.”

3.

Click OK to confirm in the Clear Trend Statistics dialog that appears.

Related CLI Syntax to Clear Trend Statistics SGOS# clear-statistics persistent

Upgrading the SG Appliance When an upgrade to the SGOS software becomes available, you can download it through the Internet and install it. You can also download it to your PC and install it from there. Important: Enable the auto-detect encoding feature on your browser so that it uses the encoding specified in the console URLs. The browser does not use the auto- detect encoding feature by default. If auto-detect encoding is not enabled, the browser ignores the charset header and uses the native OS language encoding for its display.

37

Volume 9: Managing the Blue Coat SG Appliance

The SG Appliance 5.x Version Upgrade The appliance must be running version SGOS 4.2.1.6 or later in order to upgrade to SGOS 5.x. You cannot directly upgrade from any previous version. Note: At least one other system must be unlocked to do the upgrade. If all systems are locked, or all systems except the running system are locked, the Download button in the Management Console is disabled. Similarly, the load upgrade command in the CLI generates an error.

To upgrade the SG appliance: 1.

Select Maintenance > Upgrade > Upgrade.

2.

Click Show me to connect to the Blue Coat download page, follow the instructions, and note the URL of the SGOS upgrade for your system model. Then enter the URL in the Download new system software from this URL field and click Download. -or(Only if you previously downloaded a system image to your PC) Click Upload and Browse to the file location, then click Install. The upload might take several minutes.

38

Chapter 3: Maintaining the SG Appliance

3.

(Optional) Select the system to replace in the Replace drop-down list. If you uploaded an image from your PC, refresh the Systems pane to see the new system image.

4.

Click Restart. The Restart system dialog displays.

5.

Click OK to reboot the SG appliance to the default system.

Related CLI Syntax to Upgrade the SGOS Software SGOS#(config) upgrade-path url

where url is the location of the SGOS upgrade image. SGOS#(config) exit SGOS# load upgrade [ignore-warnings]

where ignore-warnings allows you to force an upgrade even if you receive policy deprecation warnings. Using the load upgrade ignore-warnings command to force an upgrade while the system emits deprecation warnings results in a policy load failure; all traffic is allowed or denied according to default policy. SGOS# restart upgrade

39

Volume 9: Managing the Blue Coat SG Appliance

Troubleshooting Tip If the SG appliance does not come up after rebooting and the serial port is connected to a terminal server (terminal concentrator), try the following: ❐

Have an active session open on the terminal server, noting any traffic (characters) being output.

❐

Unplug the terminal server from the appliance in case it is causing a problem (such as bad cabling).

Managing SG Appliance Systems The SG appliance Systems tab displays the five available systems. Empty systems are indicated by the word Empty. The system currently running is highlighted in blue and cannot be replaced or deleted. From this screen, you can: ❐

Select the SGOS system version to boot.

❐

Lock one or more of the available SGOS system versions.

❐

Select the SGOS system version to be replaced.

❐

Delete one or more of the available SGOS system versions (CLI only).

❐

View details of the available SGOS system versions.

To view SGOS system replacement options: Select Maintenance > Upgrade > Systems.

To view details for an SGOS system version: 1.

Select Maintenance > Upgrade > Systems.

2.

Click Details next to the system for which you want to view detailed information; click OK when you are finished.

40

Chapter 3: Maintaining the SG Appliance

To view details for an SGOS system version: At the command prompt: SGOS> show installed-systems

Example Session SGOS> show installed-systems SG Appliance Systems 1. Version: SGOS 4.2.1.1, Release ID: 25460 Thursday April 6 2006 08:49:55 UTC, Lock Status: Locked Boot Status: Last boot succeeded, Last Successful Boot: Thursday April 6 2006 17:33:19 UTC 2. Version: SGOS 4.2.1.1, Release ID: 25552 Debug Friday April 14 2006 08:56:55 UTC, Lock Status: Unlocked Boot Status: Last boot succeeded, Last Successful Boot: Friday April 14 2006 16:57:18 UTC 3. Version: N/A, Release ID: No Timestamp, Lock Status: Boot Status: Unknown, Last 4. Version: N/A, Release ID: No Timestamp, Lock Status: Boot Status: Unknown, Last 5. Version: N/A, Release ID:

N/A ( EMPTY ) Unlocked Successful Boot: Unknown N/A ( EMPTY ) Unlocked Successful Boot: Unknown N/A ( EMPTY )

No Timestamp, Lock Status: Unlocked Boot Status: Unknown, Last Successful Boot: Unknown Default system to run on next hardware restart: 2 Default replacement being used. (oldest unlocked system) Current running system: 2 When a new system is loaded, only the system number that was replaced is changed. The ordering of the rest of the systems remains unchanged.

Setting the Default Boot System This setting allows you to select the system to be booted on the next hardware restart. If a system starts successfully, it is set as the default boot system. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system. To set the SG appliance to run on the next hardware restart: 1.

Select Maintenance > Upgrade > Systems.

2.

Select the preferred System version in the Default column.

3.

Click Apply.

41

Volume 9: Managing the Blue Coat SG Appliance

Note: An empty system cannot be specified as default, and only one system can be specified as the default system.

Related CLI Syntax to Set the Default Boot System SGOS#(config) installed-systems SGOS#(config installed-systems) default system_number

Locking and Unlocking SG Appliance Systems Any system can be locked, except a system that has been selected for replacement. If all systems, or all systems except the current system, are locked, the SG appliance cannot load a new system. If a system is locked, it cannot be replaced or deleted. To lock a system: 1.

Select Maintenance > Upgrade > Systems.

2.

Select the system(s) to lock in the Lock column.

3.

Click Apply.

To unlock a system: 1.

Select Maintenance > Upgrade > Systems.

2.

Deselect the system(s) to unlock in the Lock column.

3.

Click Apply.

To unlock a system: Related CLI Syntax for Locking A System SGOS#(config) installed-systems SGOS#(config installed-systems) lock system_number

To unlock: SGOS#(config) installed-systems SGOS#(config installed-systems) no lock system_number

Replacing an SG Appliance System You can specify the system to be replaced when a new system is downloaded. If no system is specified, the oldest unlocked system is replaced by default. You cannot specify a locked system for replacement. To specify the system to replace: 1.

Select Maintenance > Upgrade > Systems.

2.

Select the system to replace in the Replace column.

3.

Click Apply.

Related CLI Syntax to Specify the System to Replace SGOS#(config) installed-systems SGOS#(config installed-systems) replace system_number

42

Chapter 3: Maintaining the SG Appliance

Deleting an SG Appliance System You can delete any of the system versions except the current running system. A locked system must be unlocked before it can be deleted. If the system you want to delete is the default boot system, you need to select a new default boot system before the system can be deleted. You cannot delete a system version through the Management Console; you must use the CLI. To delete a system: At the (config) command prompt: SGOS#(config) installed-systems SGOS#(config installed-systems) delete system_number

where system_number is the system you want to delete.

Disk Reinitialization You can reinitialize disks on a multi-disk SG appliance. You cannot reinitialize the disk on a single-disk SG appliance. If you suspect a disk fault in a single-disk system, contact Blue Coat Technical Support for assistance. Note: If a disk containing an unmirrored event or access log is reinitialized, the logs are lost. Similarly, if two disks containing mirrored copies of the logs are reinitialized, both copies of the logs are lost.

Multi-Disk SG Appliances On a multi-disk SG appliance, the master disk is the leftmost valid disk. Valid means that the disk is online, has been properly initialized, and is not marked as invalid or unusable. If the current master disk is taken offline, reinitialized, or declared invalid or unusable, the leftmost valid disk that has not been reinitialized since restart becomes the master disk. Thus, as disks are reinitialized in sequence, a point is reached where no disk can be chosen as the master. At this point, the current master disk is the last disk. If this disk is taken offline, reinitialized, or declared invalid or unusable, the SG appliance is restarted. On a multi-disk SG appliance, a disk is reinitialized by setting it to empty and copying pre-boot programs, boot programs, and starter programs, and system images from the master disk to the reinitialized disk. Reinitialization is done online without rebooting the system. (For more information, refer to the #disk command in the Volume 11: Command Line Interface Reference.) SGOS operations, in turn, are not affected, although during the time the disk is being reinitialized, that disk is not available for caching. Only the master disk reinitialization restarts the SG appliance. Only persistent objects are copied to a newly-reinitialized disk. This is usually not a problem because most of these objects are replicated or mirrored. If the reinitialized disk contained one copy of these objects (which is lost), another disk contains another copy. You cannot reinitialize all of the SG appliance disks over a very short period of time. Attempting to reinitialize the last disk in a system before critical components can be replicated to other disks in the system causes a warning message to appear. Immediately after reinitialization is complete, the SG appliance automatically starts using the reinitialized disk for caching.

43

Volume 9: Managing the Blue Coat SG Appliance

Single-Disk SG Appliance The disk on a single-disk SG appliance cannot be reinitialized by the customer. If you suspect a disk fault in a single-disk SG appliance, contact Blue Coat Technical Support for assistance.

Deleting Objects from the SG Appliance The ability to delete either individual or multiple objects from the SG appliance makes it easy to delete stale or unused data and make the best use of the storage in your system. Note: The maximum number of objects that can be stored in an SG appliance is affected by a number of factors, including the SGOS version it is running and the hardware platform series.

This feature is not available in the Management Console. Use the CLI instead. To delete a single object from the SG appliance: At the (config) prompt, enter the following command: SGOS#(config) content delete url url

To delete multiple objects from the SG appliance: At the (config) prompt, enter the following command: SGOS#(config) content delete regex regex

44

Chapter 4: Diagnostics

Blue Coat Systems has a number of resources to provide diagnostic information: ❐

Heartbeats: Enabled by default, Heartbeats (statistics) are a diagnostic tool used by Blue Coat, allowing them to proactively monitor the health of appliances.

❐

Core images: Created when there is an unexpected system restarted. This stores the system state at the time of the restart, enhancing the ability for Blue Coat to determine the root cause of the restart.

❐

SysInfo (System Information): SysInfo provides a snapshot of statistics and events on the SG appliance.

❐

PCAP: An onboard packet capture utility that captures packets of Ethernet frames going in or out of an SG appliance.

❐

Policy trace: A policy trace can provide debugging information on policy transactions. This is helpful, even when policy is not the issue. For information on using policy tracing, refer to Volume 10: Content Policy Language Guide.

❐

Event Logging: The event log files contain messages generated by software or hardware events encountered by the appliance. For information on configuring event logging, see “Setting Up Event Logging and Notification” on page 15.

❐

Access Logging: Access logs allow for analysis of Quality of Service, content retrieved, and other troubleshooting. For information on Access Logging, refer to Volume 8: Access Logging.

❐

CPU Monitoring: With CPU monitoring enabled, you can determine what types of functions are taking up the majority of the CPU.

To test connectivity, use the following commands from the enable prompt: ❐ ❐

ping: Verifies that a particular IP address exists and is responding to requests. traceroute: Traces the route from the current host to the specified destination

host. ❐

test http get path_to_URL: Makes a request through the same code paths as a

proxied client. ❐

display path_to_URL: Makes a direct request (bypassing the cache).

❐

show services: Verifies the port of the Management Console configuration.

❐

show policy: Verifies if policy is controlling the Management Console.

For information on using these commands, refer to Chapter 2: “Standard and Privileged Mode Commands” in the Blue Coat ProxySG Command Line Reference. Note: If you cannot access the Management Console at all, be sure that you are using HTTPS (https://SG_IP_address:8082). If you want to use HTTP, you must explicitly enable it before you can access the Management Console.

45

Volume 9: Managing the Blue Coat SG Appliance

This chapter discusses the following topics: ❐

“Diagnostic Reporting (Service Information)” on page 46 (This includes taking snapshots of the system.)

❐

“Packet Capturing (the Job Utility)” on page 52

❐

“Core Image Restart Options” on page 57

❐

“Diagnostic Reporting (Heartbeats)” on page 58

❐

“Diagnostic Reporting (CPU Monitoring)” on page 59

If the SG appliance does not appear to work correctly and you are unable to diagnose the problem, contact Blue Coat Technical Support.

Diagnostic Reporting (Service Information) The service information options allow you to send service information to Blue Coat using either the Management Console or the CLI. You can select the information to send, send the information, view the status of current transactions, and cancel current transactions. You can also send service information automatically in case of a crash.

Sending Service Information Automatically Enabling automatic service information allows you to enable the transfer of relevant service information automatically whenever a crash occurs. This saves you from initiating the transfer, and increases the amount of service information that Blue Coat can use to solve the problem. The core image, system configuration, and event log are system-use statistics that are sent for analysis. If a packet capture exists, it is also sent. The auto-send feature requires that a valid Service Request is entered. If you do not have a Service Request open you must first contact Blue Coat Technical Support. Important:

A core image and packet capture can contain sensitive information—for example, parts of an HTTP request or response. The transfer to Blue Coat is encrypted, and therefore secure; however, if you do not want potentially sensitive information to be sent to Blue Coat automatically, do not enable the automatic service information feature.

To send service information automatically: 1.

2.

Select Maintenance > Service Information > Send Information > General.

To send core image service information to Blue Coat automatically, select Enable autosend.

46

Chapter 4: Diagnostics

3.

Enter the service-request number that you received from a Technical Support representative into the Auto Send Service Request Number field (the service-request number is in the form xx-xxxxxxx or x-xxxxxxx).

4.

Click Apply to commit the changes to the SG appliance.

5.

(Optional) To clear the service-request number, clear the Auto Send Service Request Number field and click Apply.

Related CLI Syntax to Send Service Information To send service information automatically: 1.

To enable (or disable) the automatic service information feature, enter the following commands at the (config) command prompt: SGOS#(config) diagnostics SGOS#(config diagnostics) service-info SGOS#(diagnostics service-info) auto {enable | disable} SGOS#(diagnostics service-info) auto sr-number sr_number

2.

(Optional) To clear the service-request number, enter the following command: SGOS#(diagnostics service-info) auto no sr-number

Managing the Bandwidth for Service Information You can control the allocation of available bandwidth for sending service information. Some service information items are large, and you might want to limit the bandwidth used by the transfer. Changing to a new bandwidth management class does not affect service information transfers already in progress. However, changing the details of the bandwidth management class used for service information, such as changing the minimum or maximum bandwidth settings, affects transfers already in progress if that class was selected prior to initiating the transfer. Note: Before you can manage the bandwidth for the automatic service information

feature, you must first create an appropriate bandwidth-management class. Refer to Volume 5: Advanced Networking for information about creating and configuring bandwidth classes. To manage bandwidth for service information: 1.

Select Maintenance > Service Information > Send Information > General.

2.

To manage the bandwidth of automatic service information, select a bandwidth class from the Service Information Bandwidth Class drop-down menu.

3.

Click Apply to commit the changes to the SG appliance.

4.

(Optional) To disable the bandwidth-management of service information, select none from the Service Information Bandwidth Class drop-down menu; click Apply.

Related CLI Syntax to Manage Bandwidth for Service Information SGOS#(diagnostics service-info) bandwidth-class bw_class_name

47

Volume 9: Managing the Blue Coat SG Appliance

Configure Service Information Settings The service information options allow you to send service information to Blue Coat using either the Management Console or the CLI. You can select the information to send, send the information, view the status of current transactions, and cancel current transactions using either the Management Console or the CLI. For information about sending service information automatically, see “Sending Service Information Automatically” on page 46. Important:

You must specify a service-request number before you can send service information. See Blue Coat Technical Support at: http://www.bluecoat.com/support/ index.html for details on opening a service request ticket.

The following list details information that you can send: ❐

Packet Capture

❐

Event Log

❐

Memory Core

❐

SYSInfo

❐

Access Logs (can specify multiple)

❐

Snapshots (can specify multiple)

❐

Contexts (can specify multiple)

To send service information: 1.

Select Maintenance > Service Information > Send Information > Send Service Information.

2.

Enter the service-request number that you received from a Technical Support representative (the service-request number is in the form xx-xxxxxxx or x-xxxxxxx).

3.

Select the appropriate check boxes (as indicated by a Technical Support representative) in the Information to send field. Note: Options for items that you do not have on your system are grayed out and

cannot be selected.

48

Chapter 4: Diagnostics

4.

(Optional) If you select Access Logs, Snapshots, or Contexts, you must also click Select access logs to send, Select snapshots to send, or Select contexts to send and complete the following steps in the corresponding dialog that appears:

a.

To select information to send, highlight the appropriate selection in the Access Logs/Snapshots/Contexts Not Selected field and click Add to Selected.

b.

To remove information from the Access Logs/Snapshots/Contexts Selected field, highlight the appropriate selection and click Remove from Selected.

c.

Click Ok.

5.

Click Send.

6.

Click Ok in the Information upload started dialog that appears.

7.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Send Service Information SGOS#(diagnostics service-info) [subcommands]

49

Volume 9: Managing the Blue Coat SG Appliance

Creating and Editing Snapshot Jobs The snapshot subsystem periodically pulls a specified console URL and stores it in a repository, offering valuable resources for Blue Coat customer support in diagnosing problems. By default, two snapshots are defined. The first takes a snapshot of the system information URL once every 24 hours. The second snapshot takes an hourly snapshot of the system information statistics. Both of these snapshot jobs keep the last 30 snapshots. Determining which console URL to poll, the time period between snapshots, and how many snapshots to keep are all configurable options for each snapshot job. To create a new snapshot job: 1.

Select Maintenance > Service Information > Snapshots.

2.

Click New.

3.

Enter a snapshot job into the Add list item dialog that displays; click Ok.

4.

Click Apply to commit the changes to the SG appliance.

5.

(Optional) To view snapshot job information, click View All Snapshots. Close the window that opens when you are finished viewing.

Related CLI Syntax to Send Service Information SGOS#(config diagnostics) snapshot create snapshot_name

To edit an existing snapshot job: 1.

Select Maintenance > Service Information > Snapshots.

2.

Select the snapshot job you want to edit (highlight it).

3.

Click Edit. The Edit Snapshot dialog displays.

50

Chapter 4: Diagnostics

4.

Enter the following information into the Edit Snapshot fields: a.

Target: Enter the object to snapshot.

b.

Interval (minutes): Enter the interval between snapshot reports.

c.

Total Number To Take: Enter the total number of snapshots to take or select Infinite to take an infinite number of snapshots.

d. Maximum Number To Store: Enter the maximum number of snapshots to store. e.

Enabled: Select this to enable this snapshot job or deselect it to disable this

snapshot job. 5.

(Optional) Click View URL List to open a window displaying a list of URLs; close the window when you are finished viewing.

6.

(Optional) Click View Snapshots to open a window displaying snapshot information; close the window when you are finished viewing.

7.

(Optional) Click Clear Snapshots to clear all stored snapshot reports.

Related CLI Syntax to Edit an Existing Snapshot Job ❐

To enter configuration mode: SGOS#(config) diagnostics

❐

The following subcommands are available: SGOS#(config diagnostics) snapshot edit snapshot_name SGOS#(config snapshot snapshot_name) {disable | enable} SGOS#(config snapshot snapshot_name) interval minutes SGOS#(config snapshot snapshot_name) keep number_to_keep (from 1 100) SGOS#(config snapshot snapshot_name) take {infinite | number_to_take} SGOS#(config snapshot snapshot_name) target object_to_fetch

51

Volume 9: Managing the Blue Coat SG Appliance

Packet Capturing (the Job Utility) You can capture packets of Ethernet frames going into or leaving an SG appliance. Packet capturing allows filtering on various attributes of the frame to limit the amount of data collected. The maximum PCAP size allowed is 100MB. Any packet filters must be defined before a capture is initiated, and the current packet filter can only be modified if no capture is in progress. The pcap utility captures all received packets that are either directly addressed to the SG appliance through an interface’s MAC address or through an interface’s broadcast address. The utility also captures transmitted packets that are sent from the appliance. The collected data can then be transferred to the desktop or to Blue Coat for analysis. Note: Packet capturing increases the amount of processor usage performed in TCP/IP.

To analyze captured packet data, you must have a tool that reads Packet Sniffer Pro 1.1 files (for example, Ethereal or Packet Sniffer Pro 3.0).

PCAP File Name Format The name of a downloaded packet capture file has the format: bluecoat_date_filterexpression.cap, revealing the date and time (UTC) of the packet capture and any filter expressions used. Because the filter expression can contain characters that are not supported by a file system, a translation can occur. The following characters are not translated: ❐

Alphanumeric characters (a-z, A-Z, 0-9)

❐

Periods (.)

Characters that are translated are: ❐

Space (replaced by an underscore)

❐

All other characters (including the underscore and dash) are replaced by a dash followed by the ASCII equivalent; for example, a dash is translated to -2D and an ampersand (&) to -26.

Common PCAP Filter Expressions Packet capturing allows filtering on various attributes of the frame to limit the amount of data collected. PCAP filter expressions can be defined in the Management Console or the CLI. Below are examples of filter expressions; for PCAP configuration instructions, see “Configuring Packet Capturing” on page 53. Some common filter expressions for the Management Console and CLI are listed below. The filter uses the Berkeley Packet Filter format (BPF), which is also used by the tcpdump program. A few simple examples are provided below. If filters with greater complexity are required, you can find many resources on the Internet and in books that describe the BPF filter syntax.

52

Chapter 4: Diagnostics

Note: Some qualifiers must be escaped with a backslash because their identifiers are also

keywords within the filter expression parser. ❐

ip proto protocol where protocol is a number or name (icmp, udp, tcp).

❐

ether proto protocol where protocol can be a number or name (ip, arp, rarp).

Table 4-1. PCAP Filter Expressions Filter Expression

Packets Captured

ip host 10.25.36.47

Captures packets from a specific host with IP address 10.25.36.47.

not ip host 10.25.36.47

Captures packets from all IP addresses except 10.25.36.47.

ip host 10.25.36.47 and ip host 10.25.36.48

Captures packets sent between two IP addresses: 10.25.36.47 and 10.25.36.48. Packets sent from one of these addresses to other IP addresses are not filtered.

ether host 00:e0:81:01:f8:fc

Captures packets to or from MAC address 00:e0:81:01:f8:fc:.

port 80

Captures packets to or from port 80.

ip sr www.bluecoat.com and ether broadcast

Captures packets that have IP source of www.bluecoat.com and ethernet broadcast destination.

Using Filter Expressions in the CLI To add a filter to the CLI, use the command: SGOS# pcap filter expr parameters

To remove a filter, use the command: SGOS# pcap filter Important:

Define CLI filter expr parameters with double-quotes to avoid confusion with special characters. For example, a space is interpreted by the CLI as an additional parameter, but the CLI accepts only one parameter for the filter expression. Enclosing the entire filter expression in quotations allows multiple spaces in the filter expression.

Configuring Packet Capturing Use the following procedures to configure packet capturing. If a download of the captured packets is requested, packet capturing is implicitly stopped. In addition to starting and stopping packet capture, a filter expression can be configured to control which packets are captured. For information on configuring a PCAP filter, see "Common PCAP Filter Expressions" above.

53

Volume 9: Managing the Blue Coat SG Appliance

Note: Requesting a packet capture download stops packet capturing.

To analyze captured packet data, you must have a tool that reads Packet Sniffer Pro 1.1 files (for example, Ethereal or Packet Sniffer Pro 3.0). To enable, stop, and download packet captures: 1.

Select Maintenance > Service Information > Packet Captures.

5

2

3 4

2.

In the Direction drop-down list, select the capture direction: in, out, or both.

3.

In the Interface drop-down list, select the interface on which to capture.

4.

To define or change the PCAP filter expression, enter the filter information into the Capture filter field. (See “Common PCAP Filter Expressions” on page 52 for

information about PCAP filter expressions for this field.) To remove the filter, clear this field. 5.

Click Start Capture. The Start Capture dialog displays.

6

7 8

9

54

Chapter 4: Diagnostics

6.

Set the buffer size and method by choosing one of the following radio buttons: a.

Capture all matching packets.

b.

Capture first n matching packets. Enter the number of matching packets (n) to capture. If the number of packets reaches this limit, packet capturing stops automatically. The value must be between 1 and 1000000.

c.

Capture last n matching packets. Enter the number of matching packets (n) to capture. Any packet received after the memory limit is reached results in the discarding of the oldest saved packet prior to saving the new packet. The saved packets in memory are written to disk when the capture is stopped. The value must be between 1 and 1000000.

d. Capture first n matching Kilobytes. Enter the number of kilobytes (n) to capture. If the buffer reaches this limit, packet capturing stops automatically. The value must be between 1 and 102400. e.

7.

Capture last n matching Kilobytes. Enter the number of kilobytes (n) to capture. Any packet received after the memory limit is reached results in the discarding of the oldest saved packet prior to saving the new packet. The saved packets in memory are written to disk when the capture is stopped. The value must be between 1 and 102400.

Optional—To truncate the number of bytes saved in each frame, enter a number in the Save first n bytes of each packet field. When configured, pcap collects, at most, n bytes

of packets from each frame when writing to disk. The range is 1 to 65535. 8.

Optional—To specify the number of kilobytes of packets kept in a core image, enter a value in the Include n K Bytes in core image field. You can capture packets and include them along with a core image. This is extremely useful if a certain pattern of packets causes the unit to restart unexpectedly. The core image size must be between 0 and 102400. By default, no packets are kept in the core image.

9.

To start the capture, click the Start Capture button. The Start Capture dialog closes. Note that the Start captures button in the Packet Captures tab is now grayed out because packet capturing is already started. You do not have to click Apply because all changes are applied when you start the packet capture.

10 11

10. To stop the capture, click the Stop capture button. This button is grayed out if a packet capture is already stopped. 11. To download the capture, click the Download capture button. This button is grayed out if no file is available for downloading.

55

Volume 9: Managing the Blue Coat SG Appliance

Related CLI Syntax to Define Packet Capturing Settings SGOS# pcap filter parameters SGOS# pcap start [subcommands]

To start, stop, and download packet captures through a browser: 1.

Start your Web browser.

2.

Enter the URL: https://appliance_IP_address:8082/PCAP/Statistics and log on to the appliance as needed. The Packet Capture Web page opens.

3.

Select the desired action: Start packet capture, Stop packet capture, Download packet capture file.

You can also use the following URLs to configure these individually: ❐

To start packet capturing, use this URL: https://SG_IP_address:8082/PCAP/start

❐

To stop packet capturing, use this URL: https://SG_IP_address:8082/PCAP/stop

❐

To download packet capturing data, use this URL: https://SG_IP_address:8082/PCAP/bluecoat.cap

Viewing Current Packet Capture Data Use the following procedures to display current capture information from the SG appliance.

56

Chapter 4: Diagnostics

To view current packet capture statistics: 1.

Select Maintenance > Service Information > Packet Captures.

2.

To view the packet capture statistics, click the Show statistics button. A window opens displaying the statistics on the current packet capture settings. Close the window when you are finished viewing the statistics.

Related CLI Syntax to View Packet Capture Data SGOS# pcap info

Uploading Packet Capture Data Use the following command to transfer packet capture data from the SG appliance to an FTP site. You cannot use the Management Console. After uploading is complete, you can analyze the packet capture data. SGOS# pcap transfer ftp://url/path/filename.cap username password

Specify a username and password, if the FTP server requires these. The username and password must be recognized by the FTP server.

Core Image Restart Options This option specifies how much detail is logged to disk when a system is restarted. Although this information is not visible to the user, Blue Coat Technical Support uses it in resolving system problems. The more detail logged, the longer it takes the SG appliance to restart. There are three options: ❐

None—no system state information is logged. Not recommended.

❐

Context only—the state of active processes is logged to disk. This is the default.

❐

Full—A complete dump is logged to disk. Use only when asked to do so by Blue Coat

Technical Support. The default setting of Context only is the optimum balance between restart speed and the information needs of Blue Coat Technical Support in helping to resolve a system problem. You can also select the number of core images that are retained. The default value is 2; the range is between 1 and 10. To configure core image restart options: 1.

Select Maintenance > Core Images.

2.

Select a core image restart option.

3.

(Optional) Select the number of core images that are retained from the Number of stored images drop-down list.

4.

Click Apply to commit the changes to the SG appliance.

57

Volume 9: Managing the Blue Coat SG Appliance

Related CLI Syntax for Configuring Core Image Restart Options SGOS#(config) restart core-image {context | full | keep number | none}

Diagnostic Reporting (Heartbeats) The SG appliance diagnostic reporting configurations are located in the Management Console (under the Maintenance > Hearbeats tab), and in the CLI (under the configuration diagnostics submode). The daily heartbeat is a periodic message that is sent every 24 hours and contains SG appliance statistical data. Besides telling the recipient that the device is alive, heartbeats also are an indicator of the appliance's health. Heartbeats do not contain any private information; they contain only aggregate statistics that can be use to preemptively diagnose support issues. The daily heartbeat is encrypted and transferred to Blue Coat using HTTPS. Administrators can have the daily heartbeat messages e-mailed to them by configuring event log notification. The content that is e-mailed to the administrator is the same content sent to Blue Coat. If monitoring is enabled, Blue Coat receives encrypted information over HTTPS whenever the appliance is rebooted. The data sent does not contain any private information; it contains restart summaries and daily heartbeats. This allows the tracking of SG appliance unexpected restarts due to system issues, and allows Blue Coat to address system issues preemptively. If the daily heartbeats setting is disabled, you can still send a heartbeat message by using the send-heartbeat command through the CLI (this feature is not available through the Management Console). To set daily heartbeats and/or Blue Coat monitoring: 1.

Select Maintenance > Heartbeats.

2.

Select or deselect Enable daily heartbeats or Enable Blue Coat monitoring.

3.

Click Apply to commit the changes to the SG appliance.

Related CLI Syntax to Manage Heartbeats and Monitoring ❐

To enter configuration mode: SGOS#(config) diagnostics [Command_Modes]

❐

The following subcommands are available: SGOS#(config diagnostics) heartbeat enable SGOS#(config diagnostics) monitor enable SGOS#(config diagnostics) send-heartbeat Note: This option is not available through the Management Console.

58

Chapter 4: Diagnostics

Diagnostic Reporting (CPU Monitoring) You can enable CPU monitoring whenever you want to see the percentage of CPU being used by specific functional groups. For example, if you look at the CPU consumption and notice that compression/decompression is consuming most of the CPU, you can change your policy to compress/decompress more selectively. Note: CPU monitoring uses about 2-3% CPU when enabled, and so is disabled by default.

To configure and view CPU monitoring: 1.

Select Statistics > Advanced.

2.

Click the Diagnostics link. A list of links to Diagnostic URLs displays.

3.

To enable CPU monitoring, click the Start the CPU Monitor link; to disable it, click the Stop the CPU Monitor link.

4.

To view CPU monitoring statistics, click the CPU Monitor statistics link. You can also click this link from either of the windows described in Step 3.

Related CLI Syntax to Configure and View CPU Monitoring SGOS#(config) diagnostics SGOS#(config diagnostics) cpu-monitor disable | enable SGOS#(config diagnostics) cpu-monitor interval seconds Note: The total percentages do not always add up because the display only shows

those functional groups that are using 1% or more of the CPU processing cycles.

59

Volume 9: Managing the Blue Coat SG Appliance

Note: The commands SGOS#(config) show cpu and SGOS#(config diagnostics) view cpu-monitor can sometimes display CPU statistics that differ by about 2-3%.

This occurs because different measurement techniques are used for the two displays.

60

Chapter 5: Statistics

The Statistics tabs of the Management Console allow you to view the status of many system operations. Many statistics are available through the CLI, but only in text output. You can also view detailed system information through the CLI using the show command. Access this command through either the enable command prompt (SGOS#) or the config command prompt (SGOS#(config)). For convenience, the procedures in this chapter show only the enable command prompt. See “Using the CLI show Command to View Statistics” on page 88 for information about using the show command. This chapter includes the following topics: ❐

“Viewing Traffic Distribution Statistics” on page 62

❐

“Viewing Traffic History” on page 65

❐

“Viewing the ADN History” on page 68

❐

“Viewing Bandwidth Management Statistics” on page 68

❐

“Viewing Protocol Statistics” on page 68

❐

“Viewing System Statistics” on page 70

❐

“Viewing Traffic Distribution Statistics” on page 62

❐

“Active Sessions—Viewing Per-Connection Statistics” on page 76

❐

“Viewing the Access Log” on page 87

❐

“Viewing Advanced Statistics” on page 87

Selecting the Graph Scale is allowed to fall off the scale. For example, if you select clip 25% of peaks, the top 25% of the values are allowed to exceed the scale for the graph, showing greater detail for the remaining 75% of the values. To set the graph scale, select a value from the Graph scale should drop-down list. Some of the graphs offer the option of viewing statistics in bytes or objects. On these pages, you can switch among viewing modes by selecting the desired value from the drop-down list. You can also move your cursor over the bar graphs to dynamically display color-coded statistical information.

Figure 5-1. Graph Scale Drop-Down Example

61

Volume 9: Managing the Blue Coat SG Appliance

Viewing Traffic Distribution Statistics Use the Statistics > Traffic Mix page to display traffic distribution and bandwidth statistics for traffic running through the SG appliance. You can display statistics for proxy types, or for services, and for various time periods. h

g

e

f

b

a c

d

Key: a.

View aggregated bandwidth usage or gain graphs and statistics.

b.

View client or server byte-distribution charts and statistics.

c.

Review client bytes, server bytes, bypassed bytes, and bandwidth gain (per proxy or service).

d. Review totals for client bytes, server bytes, bandwidth gain, bypassed bytes, and total gain (for all proxies or all services). e.

Show default service bytes per port.

f.

Switch between proxy and service traffic mix statistics.

g. Modify the historical reporting period. h. Include or exclude bypassed bytes. Figure 5-2. Traffic Mix Page Note: Bypassed bytes are bytes that are not intercepted by a service or proxy. When you include or exclude bypassed bytes, only the graph data and totals are affected. The table data in the lower half of the page is not altered.

For a list of supported proxies, see “Supported Proxy Types and Services” on page 66.

62

Chapter 5: Statistics

Note: Endpoint Mapper proxy bytes are the result of Microsoft Remote Procedure Call

(MSRPC) communication for MAPI traffic.

Understanding Chart Data The chart data updates automatically every 60 seconds. The units for the X and Y axis change according to the selected duration. For example, if you select "Last Week,” the X-axis displays the days of the week (the most current day is to the far right). The word "Hit" can display at the top of the BW Gain graph if the gain was the result of a cache hit. The colors in the bandwidth usage and bandwidth gain charts represent the following information: ❐

Green—Client bytes

❐

Blue—Server bytes

❐

Brown—Bypassed bytes

❐

Dark Blue—Bandwidth Gain (which includes bypassed bytes, if selected) In the tool tips (as shown in figure 5-3), bandwidth gain is represented in black text.

Hover the mouse cursor over the graph data to view detailed values.

Figure 5-3. Traffic mix statistics displayed when cursor hovers over chart data

Refreshing the Data The data in the Traffic Mix page refreshes whenever you switch views or change the duration of the sample. If there is no activity, the data refreshes every 60 seconds.

About Bypassed Bytes Bypassed bytes are bytes that are not intercepted by a service or proxy. By default, bypassed bytes are included in the traffic mix views. When evaluating traffic statistics for potential optimization, it can be useful to include or exclude the bypassed byte statistics. Include or exclude bypassed bytes in the charts and graphs by selecting or clearing Include bypassed bytes in graphs. When you include or exclude bypassed bytes, only the graph data and totals are affected. The table data in the lower half of the page is not altered.

63

Volume 9: Managing the Blue Coat SG Appliance

About the Default Service Statistics The default service statistics represent bytes for traffic that has been bypassed because it did not match: ❐

An existing service listener

❐

Other rules, such as static or dynamic bypass

To view the default service bytes, click Default Ports... in the upper-right section of the Traffic Mix page.

Figure 5-4. Default Service Per Port Bytes Dialog

Refer to Volume 2: Proxies and Proxy Services for more information about the default service.

Viewing Bandwidth Usage or Gain Select the BW Usage or BW Gain tab in the Traffic Mix page to view bandwidth usage and bandwidth gain statistics for the SG appliance over the last hour, day, week, month, and year. To view per-service or per-proxy bandwidth usage statistics, go to the Traffic History (Statistics > Traffic History) page. In the BW Usage graph, the green display represents client data; the blue display represents server data; the brown represents bypassed bytes data. Hover your cursor over the graph to see the bandwidth usage and gain data. To view bandwidth usage or gain statistics: 1.

Select Statistics > Traffic Mix > BW Usage or BW Gain.

2.

Select a time period from the Duration drop-down list.

3.

(Optional) Select Include bypassed bytes in graphs to include statistics for bytes not intercepted by a proxy or service.

4.

Select the Service radio button to display the bandwidth usage statistics for all configured services.

64

Chapter 5: Statistics

5.

Select the Proxy radio button to display the bandwidth usage statistics for all supported proxies.

Viewing Client Byte and Server Byte Traffic Distribution Select the Client Bytes or Server Bytes tabs in the Traffic Mix page to view a pie chart of client byte or server byte statistics for the SG appliance over the last hour, day, week, month, or year. The pie charts display data for the top seven services or proxies; all other proxy and service statistics are categorized in the “Other” category. These items are arranged in a sorted order—the item that has highest percentage is displayed at the top of the list. To view client and server byte statistics: 1.

Select Statistics > Traffic Mix > Client Bytes or Server Bytes.

2.

Select a time period from the Duration drop-down list.

3.

(Optional) Select Include bypassed bytes in graphs to include statistics for bytes not intercepted by a proxy or service.

4.

Select the Service radio button to display the traffic distribution statistics for all services.

5.

Select the Proxy radio button to display the traffic distribution statistics for all supported proxies.

Viewing Traffic History Use the Statistics > Traffic History page to monitor the traffic statistics for all traffic running through the SG appliance. You can display statistics for all proxy types or all services.

65

Volume 9: Managing the Blue Coat SG Appliance

b

c

a

d

e

Key: a.

View traffic history statistics by service or by proxy.

b.

Modify the historical reporting period.

c.

Include or exclude bypassed bytes.

d. View totals for client bytes, server bytes, and bandwidth gain for the selected service or proxy type. e.

Display charts for bandwidth usage, bandwidth gain, client bytes, and server bytes.

Note: Bypassed bytes are bytes that are not intercepted by a service or proxy.

Supported Proxy Types and Services The Traffic History (and Traffic Mix) page displays data for the following proxy types (and services of these proxy types): • CIFS

• Endpoint Mapper

• FTP

• HTTP

• HTTPS Forward Proxy

• HTTPS Reverse Proxy

• MAPI

• MSRPC

• Quicktime

• Real Media

• RTSP

• SSL

• TCP Tunnel

• Windows Media

Note: Endpoint Mapper proxy bytes are the result of Remote Procedure Call (RPC) communication for MAPI traffic.

66

Chapter 5: Statistics

Unsupported Proxy Types The Traffic History does not display data for the following proxy types: • DNS

• IM

• SOCKS

• Telnet

• P2P

Understanding Chart Data The Traffic History chart data updates automatically every 60 seconds. The colors in the chart represent the following information: ❐

❐

Bandwidth Usage chart: •

Green—Client bytes

•

Blue—Server bytes

•

Brown—Bypassed bytes

•

Dark Blue—Bandwidth gain

Bandwidth Gain chart •

❐

Dark Blue—Bandwidth gain

Client and Server Byte charts: •

Green—Intercepted client bytes

•

Blue—Intercepted server bytes

•

Brown—Bypassed bytes

Hover the mouse cursor over the chart data to view detailed values.

Figure 5-5. Traffic history statistics displayed when cursor hovers over chart data

Refreshing the Data The data in the Traffic History page refreshes whenever you switch views or change the duration of the sample. If there is no activity, the data refreshes every minute.

67

Volume 9: Managing the Blue Coat SG Appliance

About Bypassed Bytes Bypassed bytes are bytes that are not intercepted by a service or proxy. By default, bypassed bytes are included in the traffic mix views. When evaluating traffic statistics for potential optimization, it can be useful to include or exclude the bypassed byte statistics. Include or exclude bypassed bytes in the charts and graphs by selecting or deselecting Include bypassed bytes.

Viewing Bandwidth Usage or Gain or Client Byte and Server Byte Traffic History To view client and server byte or bandwidth gain statistics: 1.

Select Statistics > Traffic History > BW Usage, BW Gain, Client Bytes, or Server Bytes.

2.

Generate history data for a service or proxy Service history: a.

Select the Service radio button.

b.

Select a service from the drop-down list.

Proxy history: a.

Select the Proxy radio button.

b.

Select a proxy from the drop-down list.

3.

Select a time period from the Duration drop-down list

4.

(Optional) Select Include bypassed bytes in graphs to include statistics for bytes not intercepted by a proxy or service.

Viewing the ADN History The Statistics > ADN History pages display WAN optimization statistics for inbound and outbound compression gain. Refer to the WAN optimization information in Volume 5: Advanced Networking for more information about these statistics.

Viewing Bandwidth Management Statistics The Statistics > Bandwidth Mgmt pages display the current class and total class statistics. Refer to the bandwidth management information in Volume 5: Advanced Networking for more information about these statistics.

Viewing Protocol Statistics The Statistics > Protocol Details pages provide statistics for the protocols serviced by the SG appliance. These statistics should be used to compliment the statistics in the Traffic History and Traffic Mix pages. The descriptions of these statistics are located in the proxy services to which they pertain. The following list provides a listing of these statistics and describes where to find additional information.

68

Chapter 5: Statistics

❐

CIFS History The Statistics > Protocol Details > CIFS History pages enable you view statistics for CIFS objects, CIFS bytes read, CIFS bytes written, and CIFS clients. Refer to the CIFS chapter in Volume 2: Proxies and Proxy Services for more information about these statistics.

❐

HTTP/FTP History The Statistics > Protocol Details > HTTP/FTP History pages enable you view statistics for HTTP/HTTPS/FTP objects, HTTP/HTTPS/FTP bytes, HTTP/HTTPS/FTP clients, client compression gain, and server compression gain. Refer to the HTTP and FTP chapters in Volume 2: Proxies and Proxy Services for more information about these statistics. For HTTP/FTP bandwidth usage statistics, see the Traffic Mix and Traffic History pages.

❐

IM History The Statistics > Protocol Details > IM History pages enable you view statistics for IM connection data, IM activity data, and IM clients. Refer to the IM chapter in Volume 3: Web Communication Proxies for more information about these statistics.

❐

MAPI History The Statistics > Protocol Details > MAPI History pages enable you view statistics for MAPI client bytes read, MAPI client bytes written, and MAPI clients. Refer to the MAPI chapter in Volume 2: Proxies and Proxy Services for more information about these statistics. For MAPI bandwidth usage statistics, see the Traffic Mix and Traffic History pages.

❐

P2P History The Statistics > Protocol Details > P2P History pages enable you view statistics for P2P data, P2P clients, and P2P bytes. Refer to the P2P information in Volume 6: The Visual Policy Manager and Advanced Policy Tasks for more information about these statistics.

❐

Shell History The Statistics > Protocol Details > Shell History pages enable you view statistics for shell clients. Refer to the shell proxy information in Volume 2: Proxies and Proxy Services for more information about these statistics.

❐

SOCKS History The Statistics > Protocol Details > SOCKS History pages enable you view statistics for SOCKS clients, SOCKS connections, client compression gain, and server compression gain. Refer to the SOCKS chapter in Volume 2: Proxies and Proxy Services for more information about these statistics.

❐

SSL History The Statistics > Protocol Details > SSL History pages enable you view statistics for unintercepted SSL data, unintercepted SSL clients, and unintercepted SSL bytes. Refer to the SSL chapter in Volume 2: Proxies and Proxy Services for more information about these statistics.

69

Volume 9: Managing the Blue Coat SG Appliance

❐

Streaming History The Statistics > Protocol Details > Streaming History pages enable you view statistics for Windows Media, Real Media, QuickTime, current streaming data, total streaming data, and bandwidth gain. Refer to the streaming chapter in Volume 3: Web Communication Proxies for more information about these statistics. For MMS bandwidth usage statistics, see the Traffic Mix and Traffic History pages.

Viewing System Statistics The System Statistics pages enable you to view: ❐

“Resources Statistics” on page 70

❐

“Contents Statistics” on page 74

❐

“Event Logging Statistics” on page 75

❐

“Failover Statistics” on page 76

Resources Statistics The Resources tabs (CPU, Disk Use, Memory Use, and Data) allow you to view information about how disk space and memory are being used, and how disk and memory space are allocated for cache data. You can view data allocation statistics through both the Management Console and the CLI, but disk and memory use statistics are available only through the Management Console.

Viewing CPU Utilization Through the Management Console, you can view the average CPU utilization percentages for the SG appliance over the last 60 minutes, 24 hours, and 30 days. You can see the current CPU utilization statistic in the CLI. To view CPU utilization: 1.

Select Statistics > System > Resources > CPU.

70

Chapter 5: Statistics

Viewing Concurrent Users The Concurrent Users tab shows users (IP addresses) going through the SG appliance for the last 60 minutes, day, week, month, and year. Only unique IP addresses of connections intercepted by proxy services are counted toward the user limit. To view concurrent users: Click Statistics > System > Resources > Concurrent Users.

71

Volume 9: Managing the Blue Coat SG Appliance

Viewing Disk Use Statistics The Disk Use tab shows the SG appliance disk usage. The fields on the tab are: ❐

System Objects—the percentage of storage resources currently used for non-access-log

system objects ❐

Access log—the percentage of storage resources currently used for the access log

❐

Cache in Use—the percentage of non-system, non-access-log resources currently in

use for cached objects ❐

Cache available—the percentage of non-system, non-access-log resources still

available for caching objects To view disk use statistics: Select Statistics > System > Resources > Disk Use.

Viewing Memory Use Statistics The Memory Use tab shows the amount of memory used for RAM, the SG appliance itself, and for network buffers. The fields on the Memory Use tab are: ❐

RAM Cache—the amount of RAM that is used for caching

❐

System allocation—the amount of RAM allocated for the device system

❐

Network buffers—the amount of RAM currently allocated for network buffers

To view memory use statistics: Select Statistics > System > Resources > Memory Use.

72

Chapter 5: Statistics

Viewing Data Allocation Statistics in RAM and on Disk The Data tab shows the total and available disk space and RAM, and how they are currently allocated. The fields on the Data tab are described below. You can also view this information in the CLI. ❐

Maximum objects supported—The maximum number of objects that can be supported

❐

Cached objects—The number of objects that are currently cached

❐

Disk used by system objects—The amount of disk space used by the system objects

❐

Disk used by access log—The amount of disk space used for access logs

❐

Total disk installed—The total amount of disk space installed on the device

❐

RAM used by cache—The amount of RAM allocated for caching

❐

RAM used by system—The amount of RAM allocated for system use

❐

RAM used by network—The amount of RAM allocated for network use

❐

Total RAM installed—The total amount of RAM installed

To view data allocation statistics: Select Statistics > System > Resources > Data.

73

Volume 9: Managing the Blue Coat SG Appliance

Contents Statistics The Contents tabs (Distribution and Data) allow you to see information about objects currently stored or served organized by size. The cache contents include all objects currently stored by the SG appliance. The cache contents are not cleared when the appliance is powered off.

Viewing Cached Objects by Size The Distribution tab shows the objects currently stored by the SG appliance, ordered by size. To view the distribution of cache contents: Select Statistics > System > Contents > Distribution.

Viewing the Number of Objects Served by Size The Data tab displays the number of objects served by the SG appliance, organized by size. This chart shows you how many objects of various sizes have been served. To view the number of objects served: Select Statistics > System > Contents > Data.

74

Chapter 5: Statistics

Event Logging Statistics The event log contains all events that have occurred on the SG appliance. Configure the level of detail available by selecting Maintenance > Event Logging > Level (For details, see “Configuring Which Events to Log” on page 15). To view the event log: 1.

Select Statistics > System > Event Logging.

2.

Click Log start or Log end or the forward and back arrow buttons to move through the event list.

3.

(Optional) Click the Poll for new events check box to poll for new events that occurred while the log was being displayed.

Note: The Event Log cannot be cleared.

75

Volume 9: Managing the Blue Coat SG Appliance

Failover Statistics At any time, you can view statistics for any failover group you have configured on your system. To view failover statistics: 1.

Select Statistics > System > Failover.

2.

From the Failover Group drop-down list, select the group to view.

The information displayed includes the multicast address, the local address, the state, and any flags, where V indicates that the group name is a virtual IP address, R indicates that the group name is a physical IP address, and M indicates that this machine can be configured to be the master if it is available.

Active Sessions—Viewing Per-Connection Statistics The Statistics > Active Sessions pages display per-connection statistics for all proxied sessions and bypassed connections running through the SG appliance. The following figure shows an example of the Active Sessions pages.

The Active Sessions feature has two pages: ❐

Proxied Sessions—Displays statistics for all connections intercepted by configured proxies or services

To learn more about proxied sessions, see “Analyzing Proxied Sessions” on page 77. ❐

Bypassed Connections—Displays statistics for all unintercepted traffic

To learn more about bypassed connections, see “Analyzing Bypassed Connections Statistics” on page 84.

76

Chapter 5: Statistics

Analyzing Proxied Sessions Use the Statistics > Active Sessions > Proxied Sessions page to get an immediate picture of the sessions, protocol types, services, bytes, and bandwidth gains (derived from WAN optimization and object caching) associated with client traffic. The first time you navigate to the Proxied Sessions page, no data is displayed. To display proxied sessions data, click Show. The statistics displayed in the window are not automatically updated. To update the statistics, click Show again. Important: Use the statistics on the Proxied Sessions pages as a diagnostic tool only. The Proxied Sessions pages do not display every connection running through the SG

appliance. Rather, this feature displays only the active sessions—one client connection (or several), together with the relevant information collected from other connections associated with that client connection. Because it displays only open connections, you cannot use the data for reporting purposes. The Proxied Sessions tab displays statistics for the following proxies: • HTTP

• HTTPS Reverse Proxy

• HTTPS Forward Proxy

• SSL

• CIFS

• TCP-Tunnel

• FTP

• Endpoint Mapper

• MMS

• MAPI

• MSRPC

Client connections are available for viewing as soon as the connection request is received. However, if delayed intercept is enabled, the connection is not shown until the three-way handshake completes. Server connections are registered and shown in the table after the connect call completes.

Viewing Proxied Sessions To view proxied sessions: 1.

Select Statistics > Active Sessions > Proxied Sessions.

2.

(Optional) Select a filter from the Filter drop-down list.

About the Proxied Sessions Statistics When reviewing the proxied session statistics, note that: ❐

Active client and server connections are displayed in black.

❐

Inactive connections are displayed in gray.

❐

Session and connection totals are displayed on the bottom left side of the page.

The following table describes the column headings and icons on the Proxied Sessions page.

77

Volume 9: Managing the Blue Coat SG Appliance

Table 5-1. Table Column Heading Descriptions on the Proxied Sessions Page Column Heading

Description

Client

IP address and port of the client PC (or other downstream host). When the client connection is inactive, the contents of this column are unavailable (gray). A client connection can become inactive if, for example, a client requests a large object and then aborts the download before the SG appliance has completed downloading it into its cache. When the session had multiple client connections, a tree view is provided. See “Viewing Sessions with Multiple Connections” on page 81 for more information.

Server

Final destination of the request. By default, the hostname is displayed. However, if a user entered an IP address in the URL, the IP address is displayed. The contents of this column are unavailable if the server connection is inactive. This can occur when a download has completed (and the server connection is closed or returned to the idle pool), but the object is still being served to the client. If a server connection was never made (a pure cache hit case), the Server column displays the hostname (or IP address) of the requested server. Active server connections are shown in black; inactive connections are unavailable.

A

ADN. Indicates that the server connection is flowing over an ADN tunnel. If the icon is not present, it indicates that an ADN tunnel is not in use.

Encrypted ADN tunnel.

S

SOCKS. Indicates that the next hop is a SOCKS proxy. If the icon is not present, it indicates that a SOCKS proxy is not in use.

FW

Forwarding. Indicates that the next hop is a proxy server. If the icon is not present, it indicates that forwarding is not in effect.

Duration

Displays the amount of time the session has been established.

Client Bytes

Represents the number of bytes (to and from the client) at the socket level on the client connection. All application-level bytes are counted, including application overhead such as HTTP headers, CIFS headers, and so on. TCP and IP headers, packet retransmissions, and duplicate packets are not counted. See “About the Byte Totals” on page 83 for more information.

78

Chapter 5: Statistics

Table 5-1. Table Column Heading Descriptions on the Proxied Sessions Page (Continued) Column Heading

Description

Server Bytes

Represents the number of bytes (to and from the server) at the socket level on the server connection. All application-level bytes are counted, including application overhead such as HTTP headers, CIFS headers, and so on. If the traffic is flowing through an ADN tunnel, the bytes are counted after ADN optimization, meaning that compressed byte counts are displayed. TCP and IP headers, packet retransmissions, and duplicate packets are not counted. See “About the Byte Totals” on page 83 for more information.

Gain

Displays the bandwidth gain for the session. The calculation is: (Client Bytes - Server Bytes)/ Server Bytes When the request results in a pure cache hit, this column displays Cache Hit.

C

Compression. When displayed in color, this icon indicates that an ADN Tunnel is in use and gzip compression is active in either direction on that tunnel. This icon has three states: • Active (color icon) • Inactive (gray icon) • Not possible (not displayed)

BC

Byte Caching. When displayed in color, this icon indicates that an ADN Tunnel is in use and byte-caching is active in either direction on that tunnel This icon has three states: • Active (color icon) • Inactive (gray icon) • Not possible (not displayed)

79

Volume 9: Managing the Blue Coat SG Appliance

Table 5-1. Table Column Heading Descriptions on the Proxied Sessions Page (Continued) Column Heading OC

Description Object Caching. When displayed in color, this icon indicates that an HTTP, HTTPS, CIFS, Streaming, or FTP proxy is in use and the content is cacheable. This icon has three states: • Active (color icon) • Inactive (gray icon) • Not possible (not displayed) The icon: ❐

Is unavailable if the content is non-cacheable (or for CIFS, when the entire connection is non-cacheable—not on an object-by-object basis).

❐

Is not displayed for MAPI and TCP-Tunnel traffic.

❐

Does not indicate a cache hit; it indicates only that the object is cacheable.

Live splitting. When displayed in color, this icon indicates that a live MMS stream is being split to the client. This icon has two states: • Active (color icon) • Inactive (gray icon) P

Protocol Optimization. When displayed in color, this icon indicates that a proxy is in use that is capable of performing latency optimizations. These proxies include HTTP, HTTPS, CIFS, and MAPI. This icon has three states: • Active (color icon) • Inactive (gray icon) • Not possible (not displayed)

BM

Bandwidth Management. When displayed in color, this icon indicates that either the client or server connection has been assigned to a bandwidth class. This icon has two states: • Active (color icon) • Inactive (gray icon)

Service Name

Displays the service used by the session. Even if a client connection is handed off to a different application proxy, this column shows the service name of the original service that intercepted the client connection.

Protocol

Displays the protocol used by the session.

Detail

Provides additional information. For example, it can indicate that a CIFS connection is "pass-through" due to SMB signing.

80

Chapter 5: Statistics

Using the Tool Tips Hover the cursor over the following components to get more information: ❐

Table column headers—Displays the full name of the column header.

❐

Row values.

❐

Acceleration icons (C, BC, OC, P, BM)—Displays the icon identity.

❐

ADN, SOCKS, and FW icons—Displays the next hop.

❐

Client and Server icons—Displays the full hostname or IP address.

About MMS Streaming Connections The Active Sessions feature displays connection statistics for MMS streams over HTTP, TCP, or UDP only. Multicast connections are not displayed. When an MMS stream is displayed, the service name is listed as “HTTP” or “MMS” (depending on the transport used) and the protocol indicates “Windows Media.”

Figure 5-6. MMS Streaming Connection Example

Viewing Sessions with Multiple Connections When multiple client or server connections are associated with a single session, the Client column provides a tree-view that allows you to expand the row to view more details about the associated connections. The tree view is represented by the icon. The following figure shows an HTTP example of this tree view.

Figure 5-7. Multiple Server Connections Example

HTTP The tree view displays (as shown above) for HTTP if multiple hosts are contacted during a session or if pipelining is used. FTP FTP uses multiple, concurrent connections. These are represented as separate rows in the tree view, as shown in the following figure.

Figure 5-8. FTP Connections Example

CIFS, MAPI, and Endpoint Mapper do not display multiple connections.

81

Volume 9: Managing the Blue Coat SG Appliance

MMS The active sessions feature displays MMS streams that have a client associated with them. MMS streams that do not have a client associated with them (multicast, content management requests, and so on) are not displayed. MMS streams are displayed as follows: ❐

MMS UDP streams have two connections, one for data and one for control.

❐

MMS TCP streams have a single connection.

❐

MMS HTTP streams have a single connection.

For additional information about streaming connections, see “About MMS Streaming Connections” on page 81.

Understanding the Tree View When collapsed, the cumulative totals for all connections are displayed, as shown in Figure 5-9.

Figure 5-9. Active Sessions Tree View

When expanded, the tree view displays per-connection statistics for the session, as shown in the following example. The top line is a a summary of that session’s statistics. The second line displays the statistics for the primary session.

Figure 5-10. Active Sessions Tree View (Expanded)

The Gain column result differs according to the server or client byte totals: ❐

Zero client bytes: displays no gain.

❐

Zero client and server bytes: displays no gain.

❐

Zero server bytes: displays Cache Hit (see the figure below).

❐

Client and server are non-zero: displays the calculated gain.

Figure 5-11. Gain Column Example

82

Chapter 5: Statistics

About the Byte Totals The client and server byte total is the sum of all bytes going to and from the client or server. All application-level bytes are counted, including application overhead such as HTTP headers, CIFS headers, and so on. TCP and IP headers, packet retransmissions, and duplicate packets are not counted. The following sections describe some of the factors that can affect the byte totals. ADN Tunnels If the traffic is flowing through an ADN tunnel, the bytes are counted after ADN optimization, meaning that compressed byte counts are displayed. Multiple Server Connections A single client connection can use many server connections. The server byte counts include the total bytes transferred over all server connections accessed over the lifetime of a client connection. Even though a server connection can serve many clients, the same server byte is never included in more than one client connection total. Aborted Downloads In some cases, you might see the server bytes increasing even after the client has closed the connection. This can occur when a client requests a large object and aborts the download before receiving the entire object. The server bytes continue to increase because the SG appliance is retrieving the object for caching. Explicit Proxying and Pipelining If clients are explicitly proxied and the session has multiple connections or is pipelined, no client bytes are displayed and the expanded server connections display no gain when the tree view is shown. This is because the SG appliance is downloading the content before serving it to the client.

What Is Not Displayed The Proxied Sessions page does not display statistics for: ❐

IM (Yahoo, AOL, MSN), DNS, SOCKS, and Telnet

❐

Inbound ADN connections

❐

Bridged connections

❐

Administrative connections (Management Console, SSH console, SNMP, DSAT, access-logging, Director, and so on)

❐

Off-box processing connections (ICAP, DRTR, etc.)

Note: In some cases, an administrative or off-box connection might correspond to a specific client connection, for example, an ICAP AV scanning connection associated with a specific HTTP client connection. However, the byte counts collected from administrative or off-box connections are not included in the Active Sessions display.

Filtering the Display Use the Filter drop-down list to filter the proxied session statistics.

83

Volume 9: Managing the Blue Coat SG Appliance

Figure 5-12. Filtering Proxied Sessions

When you select a filter, a text field or popup displays so that you can enter filtering criteria.

If you select a filter, you must enter a filtering criteria (or select None) before clicking Show. The following filters are available: ❐

Client Address Filter by IP address and IP address and subnet mask.

❐

Client Port

❐

Server Address Filter by IP address or hostname. Hostname filters automatically search for suffix matches. For example, if you filter for google.com, gmail.google.com is included in the results.

❐

Server Port

❐

Proxy

❐

Service (drop-down list) The drop-down list enables you to filter for enabled services. If you filter for a service that is not supported for active sessions (see “What Is Not Displayed” on page 83), the resulting filtering list will be empty.

Viewing HTML and XML Views of Proxied Sessions Data Access the following URLs to get HTML and XML views of active session statistics: HTML:

https://SGIP:8082/AS/Sessions/

XML:

https://SGIP:8082/AS/Sessions/xml

Analyzing Bypassed Connections Statistics The Statistics > Active Sessions > Bypassed Connections page displays data for all unintercepted TCP traffic. When the appliance is first installed in an inline deployment, all services are bypassed by default. By analyzing the connection data in the Bypassed Connections page, you can review the types of traffic flowing through the appliance to identify traffic flows that would benefit from optimization. The Bypassed Connections page is also useful for identifying new types of traffic flowing through the appliance.

84

Chapter 5: Statistics

The Bypassed Connections page displays data for connections that were not intercepted because: ❐

A service has not been configured to intercept the traffic.

❐

A static or dynamic bypass rule caused the traffic to be bypassed.

❐

The interface transparent interception setting is disabled.

Viewing Bypassed Connections To view bypassed connections: 1.

Select Statistics > Active Sessions > Bypassed Connections.

2.

(Optional) Select a filter from the Filter drop-down list. See “Filtering the Display” on page 86 for more information about display filters.

The following figure shows an example of the Bypassed Connections page.

Figure 5-13. Bypassed Connections Page

Note the following: ❐

Unavailable connections (gray) indicate connections that are now closed.

❐

Previously-established connections displayed with () text indicate that the direction of these connections is unknown.

❐

One-way connections are displayed in color.

About the Bypassed Connection Statistics The following table describes the column headings on the Bypassed Connections page. Table 5-2. Table Column Heading Descriptions on the Bypassed Connections Page Column Heading

Description

Client

IP address and port of the client PC (or other downstream host).

Server

Server IP address and port number.

85

Volume 9: Managing the Blue Coat SG Appliance

Table 5-2. Table Column Heading Descriptions on the Bypassed Connections Page (Continued) Column Heading

Description

Duration

Displays the amount of time the connection has been established.

Bypassed Bytes

Displays the total number of bypassed bytes for the connection.

Service Name

Displays the service used by the connection.

Details

Provides additional information. For example: • One-way traffic (forward) • One-way traffic (reverse) • Previously Established • Bypassed because of network interface setting

Filtering the Display Use the Filter drop-down list to filter the bypassed connection statistics.

Figure 5-14. Filter Drop-Down List

When you select a filter, a text field or drop-down displays so that you can enter filtering criteria.

Figure 5-15. Filter Drop-Down

If you select a filter, you must enter a filtering criteria (or select None) before clicking Show. The following filters are available: ❐

Client Address Filter by IP address and IP address and subnet mask.

❐

Client Port

❐

Server Address Filter by IP address or hostname. Hostname filters automatically search for suffix matches. For example, if you filter for google.com, gmail.google.com is included in the results.

❐

Server Port

❐

Service (drop-down list) The drop-down list enables you to filter for enabled services. If you filter for a service that is not supported for active sessions (see “What Is Not Displayed” on page 83), the resulting filtered list will be empty.

86

Chapter 5: Statistics

Viewing HTML and XML Views of Bypassed Connections Data Access the following URLs to get HTML and XML views of active session statistics HTML:

https://SGIP:8082/AS/BypassedConnections/

XML:

https://SGIP:8082/AS/BypassedConnections/xml

Viewing Health Monitoring Statistics The Statistics > Health page enables you to get more details about the current state of the health monitoring metrics. Health monitoring uses key hardware and software metrics to provide administrators with a remote view of the health of the system. See Chapter 2: "Monitoring the SG Appliance" for information about health monitoring.

Viewing Health Check Statistics Use the Statistics > Health Check page to view the state of various health checks: whether the health check is enabled or disabled, if it is reporting the device or service to be healthy or sick, or if errors are being reported. Refer to the health check information in Volume 5: Advanced Networking for more information.

Viewing the Access Log The Statistics > Access Logging pages enable you to view the log tail, log size, and upload status of the access log. Refer to Volume 8: Access Logging for more information.

Viewing Advanced Statistics A variety of system statistics are conveniently located in one place and accessible by clicking the links listed in the Advanced tab of the Management Console. To view system-wide advanced statistics: 1.

Select Statistics > Advanced.

87

Volume 9: Managing the Blue Coat SG Appliance

2.

Click the appropriate link for the service you want to view. A list of categories for that service displays. Note: If you upgraded from SGOS 2.x or CacheOS 4.x and have log files generated by those versions, you can view or retrieve them through the Statistics > Advanced > Access Log > Show Old Logs URL.

3.

To view the statistics for a particular category, click that category’s link. A window opens, detailing the relevant statistics.

4.

Close the window when you have finished viewing the statistics.

5.

To return to the list of links, either reselect Statistics > Advanced or click your browser’s Back button.

Using the CLI show Command to View Statistics You can use the show command to view a variety of different statistics. The following output lists the show options pertaining to topics in this chapter. SGOS# show ? cpu

CPU usage summary

disk

Disk status and information

health-checks

Health Checks statistics

http

HTTP settings

http-stats

HTTP statistics

im

IM information

ip-stats

TCP/IP statistics

p2p

Peer-to-peer information

88

Chapter 5: Statistics

resources

Allocation of system resources

snmp

SNMP statistics

streaming

Streaming information

system-resource-metrics

System Resource Metrics

89

Volume 9: Managing the Blue Coat SG Appliance

90

Appendix A: Glossary

A access control list

Allows or denies specific IP addresses access to a server.

access log

A list of all the requests sent to an appliance. You can read an access log using any of the popular log-reporting programs. When a client uses HTTP streaming, the streaming entry goes to the same access log.

account

A named entity that has purchased the appliance or the Entitlements from Blue Coat.

activation code

A string of approximately 10 characters that is generated and mailed to customers when they purchase the appliance.

active content stripping

Provides a way to identify potentially dangerous mobile or active content and scripts, and strip them out of a response.

active content types

Used in the Visual Policy Manager. Referring to Web Access policies, you can create and name lists of active content types to be stripped from Web pages. You have the additional option of specifying a customized message to be displayed to the user

administration access policy

A policy layer that determines who can access the SG appliance to perform administrative tasks.

administration authentication policy

A policy layer that determines how administrators accessing the SG appliance must authenticate.

Application Delivery Network (ADN)

A WAN that has been optimized for acceleration and compression by Blue Coat. This network can also be secured through the use of appliance certificates. An ADN network is composed of an ADN manager and backup ADN manager, ADN nodes, and a network configuration that matches the environment.

ADN backup manager

Takes over for the ADN manager in the event it becomes unavailable. See ADN manager.

ADN manager

Responsible for publishing the routing table to SG Clients (and to other SG appliances).

ADN optimize attribute

Controls whether to optimize bandwidth usage when connecting upstream using an ADN tunnel.

asx rewrite

Allows you to rewrite URLs and then direct a client's subsequent request to the new URL. One of the main applications of ASX file rewrites is to provide explicit proxylike support for Windows Media Player 6.4, which cannot set explicit proxy mode for protocols other than HTTP.

audit

A log that provides a record of who accessed what and how.

91

Volume 9: Managing the Blue Coat SG Appliance

authenticate-401 attribute

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

authenticated content

Cached content that requires authentication at the origin content server (OCS). Supported authentication types for cached data include basic authentication and IWA (or NTLM).

authentication

Allows you to verify the identity of a user. In its simplest form, this is done through usernames and passwords. Much more stringent authentication can be employed using digital certificates that have been issued and verified by a Certificate Authority. See also basic authentication, proxy authentication, and SSL authentication.

authentication realm

Authenticates and authorizes users to access SG services using either explicit proxy or transparent proxy mode. These realms integrate third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat operating system.

authorization

The permissions given to an authenticated user.

B bandwidth class

A defined unit of bandwidth allocation.

bandwidth class hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is a tree structure that specifies the relationship among different classes. You create a hierarchy by creating at least one parent class and assigning other classes to be its children.

bandwidth management

Classify, control, and, if needed, limit the amount of bandwidth used by network traffic flowing in or out of an SG appliance.

basic authentication

The standard authentication for communicating with the target as identified in the URL.

BCAAA

Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle COREid, Novell, and Windows realms. The agent is installed and configured separately from SGOS 5.x and is available from the Blue Coat Web site.

BCLP

Blue Coat Licensing Portal.

byte-range support

The ability of the SG appliance to respond to byte-range requests (requests with a Range: HTTP header).

C cache

An "object store," either hardware or software, that stores information (objects) for later retrieval. The first time the object is requested, it is stored, making subsequent requests for the same information much faster. A cache helps reduce the response time and network bandwidth consumption on future, equivalent requests. The SG appliance serves as a cache by storing content from many users to minimize response time and prevent extraneous network traffic.

cache control

Allows you to configure which content the SG appliance stores.

92

Appendix A: Glossary

cache efficiency

A tab found on the Statistics pages of the Management Console that shows the percent of objects served from cache, the percent loaded from the network, and the percent that were non-cacheable.

cache hit

Occurs when the SG appliance receives a request for an object and can serve the request from the cache without a trip to the origin server.

cache miss

Occurs when the appliance receives a request for an object that is not in the cache. The appliance must then fetch the requested object from the origin server. .

cache object

Cache contents includes all objects currently stored by the SG appliance. Cache objects are not cleared when the SG appliance is powered off.

Certificate Authority (CA)

A trusted, third-party organization or company that issues digital certificates used to create digital signatures and public key/private key pairs. The role of the CA is to guarantee that the individuals or company representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)

The child of a parent class is dependent upon that parent class for available bandwidth (they share the bandwidth in proportion to their minimum/maximum bandwidth values and priority levels). A child class with siblings (classes with the same parent class) shares bandwidth with those siblings in the same manner.

client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's HTTPS request.

client-side transparency

A way of replacing the appliance IP address with the Web server IP address for all port 80 traffic destined to go to the client. This effectively conceals the SG appliance address from the client and conceals the identity of the client from the Web server.

concentrator

An SG appliance, usually located in a data center, that provides access to data center resources, such as file servers.

content filtering

A way of controlling which content is delivered to certain users. SG appliances can filter content based on content categories (such as gambling, games, and so on), type (such as http, ftp, streaming, and mime type), identity (user, group, network), or network conditions. You can filter content using vendor-based filtering or by allowing or denying access to URLs.

D default boot system

The system that was successfully started last time. If a system fails to boot, the next most recent system that booted successfully becomes the default boot system.

default proxy listener

See proxy service (d efault).

denial of service (DoS)

A method that hackers use to prevent or deny legitimate users access to a computer, such as a Web server. DoS attacks typically send many request packets to a targeted Internet server, flooding the server's resources and making the system unusable. Any system connected to the Internet and equipped with TCP-based network services is vulnerable to a DoS attack. The SG appliance resists DoS attacks launched by many common DoS tools. With a hardened TCP/IP stack, SG appliance resists common network attacks, including traffic flooding.

93

Volume 9: Managing the Blue Coat SG Appliance

destination objects

Used in Visual Policy Manager. These are the objects that define the target location of an entry type.

detect protocol attribute

Detects the protocol being used. Protocols that can be detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

diagnostic reporting

Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or disabled.

directives

Commands used in installable lists to configure forwarding and SOCKS gateway.

DNS access

A policy layer that determines how the SG appliance processes DNS requests.

domain name system (DNS)

An Internet service that translates domain names into IP addresses. See also private DNS or public DNS.

dynamic bypass

Provides a maintenance-free method for improving performance of the SG appliance by automatically compiling a list of requested URLs that return various kinds of errors.

dynamic real-time rating (DRTR)

Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as dynamic categorization) provides real-time analysis and content categorization of requested Web pages to solve the problem of new and previously unknown uncategorized URLs—those not in the database. When a user requests a URL that has not already been categorized by the BCWF database (for example, a brand new Web site), the SG appliance dynamic categorization service analyzes elements of the requested content and assigns a category or categories. The dynamic service is consulted only when the installed BCWF database does not contain category information for an object.

E early intercept attribute

Controls whether the proxy responds to client TCP connection requests before connecting to the upstream server. When early intercept is disabled, the proxy delays responding to the client until after it has attempted to contact the server.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

emulated certificates

Certificates that are presented to the user by SG appliance when intercepting HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the subjectName and expiration. The original certificate is used between the SG appliance and the server.

encrypted log

A log is encrypted using an external certificate associated with a private key. Encrypted logs can only be decrypted by someone with access to the private key. The private key is not accessible to the SG appliance.

EULA

End user license agreement.

event logging

Allows you to specify the types of system events logged, the size of the event log, and to configure Syslog monitoring. The appliance can also notify you by email if an event is logged. See also access logging.

94

Appendix A: Glossary

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 SG appliance, and requires configuration for both browser and the interface card.

extended log file format (ELFF)

A variant of the common log file format, which has two additional fields at the end of the line—the referer and the user agent fields.

F fail open/closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. Fail open or closed applies when health checks are showing sick for each forwarding or SOCKS gateway target in the applicable fail-over sequence. If no systems are healthy, the SG appliance fails open or closed, depending on the configuration. If closed, the connection attempt simply fails. If open, an attempt is made to connect without using any forwarding target (or SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no setting is specified.

filtering

See content filtering.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A forward proxy can be explicit or transparent.

FTP

See Native FTP; Web FTP.

G gateway

A device that serves as entrance and exit into a communications network.

H hardware serial number

A string that uniquely identifies the appliance; it is assigned to each unit in manufacturing.

health check tests

The method of determining network connectivity, target responsiveness, and basic functionality. The following tests are supported: • ICMP • TCP • SSL • HTTP • HTTPS • Group • Composite and reference to a composite result • ICAP • Websense • DRTR rating service

95

Volume 9: Managing the Blue Coat SG Appliance

health check type

The kind of device or service the specific health check tests. The following types are supported: • Forwarding host and forwarding group • SOCKS gateway and SOCKS gateway group • CAP service and ICAP service group • Websense off-box service and Websense off-box service group • DRTR rating service • User-defined host and a user-defined composite

heartbeat

Messages sent once every 24 hours that contain the statistical and configuration data for the SG appliance, indicating its health. Heartbeats are commonly sent to system administrators and to Blue Coat. Heartbeats contain no private information, only aggregate statistics useful for pre-emptively diagnosing support issues. The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency heartbeats contain core dump and restart flags in addition to daily heartbeat information.

host affinity

The attempt to direct multiple connections by a single user to the same group member. Host affinity is closely tied to load balancing behavior; both should be configured if load balancing is important.

host affinity timeout

The host affinity timeout determines how long a user remains idle before the connection is closed. The timeout value checks the user's IP address, SSL ID, or cookie in the host affinity table.

I inbound traffic (bandwidth gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of the following: • Server inbound: Packets originating at the origin content server (OCS) and sent to the SG appliance to load a Web object. • Client inbound: Packets originating at the client and sent to the SG appliance for Web requests.

installable lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one of the following ways: • Creating the list using the SG text editor • Placing the list at an accessible URL • Downloading the directives file from the local system

integrated host timeout

An integrated host is an origin content server (OCS) that has been added to the health check list. The host, added through the integrate_new_hosts property, ages out of the integrated host table after being idle for the specified time. The default is 60 minutes.

intervals

Time period from the completion of one health check to the start of the next health check.

IP reflection

Determines how the client IP address is presented to the origin server for explicitly proxied requests. All proxy services contain a reflect-ip attribute, which enables or disables sending of client's IP address instead of the SG's IP address.

96

Appendix A: Glossary

issuer keyring

The keyring used by the SG appliance to sign emulated certificates. The keyring is configured on the appliance and managed through policy.

L licensable component (LC)

(Software) A subcomponent of a license; it is an option that enables or disables a specific feature.

license

Provides both the right and the ability to use certain software functions within an AV (or SG) appliance. The license key defines and controls the license, which is owned by an account.

listener

The service that is listening on a specific port. A listener can be identified by any destination IP/subnet and port range. Multiple listeners can be added to each service.

live content

Also called live broadcast. Used in streaming, it indicates that the content is being delivered fresh.

LKF

License key file.

load balancing

A way to share traffic requests among multiple upstream systems or multiple IP addresses on a single host.

local bypass list

A list you create and maintain on your network. You can use a local bypass list alone or in conjunction with a central bypass list. See bypass list.

local policy file

Written by enterprises (as opposed to the central policy file written by Blue Coat); used to create company- and department-specific advanced policies written in the Blue Coat Policy Language (CPL).

log facility

A separate log that contains a single logical file and supports a single log format. It also contains the file’s configuration and upload schedule information as well as other configurable information such as how often to rotate (switch to a new log) the logs at the destination, any passwords needed, and the point at which the facility can be uploaded.

log format

The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or Websense. The proprietary log types each have a corresponding pre-defined log format that has been set up to produce exactly that type of log (these logs cannot be edited). In addition, a number of other ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, but they start out with a useful set of log fields for logging particular protocols understood by the SG appliance. It is also possible to create new log formats of type ELFF or Custom which can contain any desired combination of log fields.

log tail

The access log tail shows the log entries as they get logged. With high traffic on the SG appliance, not all access log entries are necessarily displayed. However, you can view all access log information after uploading the log.

M MACH5

SGOS 5 MACH5 Edition.

97

Volume 9: Managing the Blue Coat SG Appliance

Management Console

A graphical Web interface that lets you to manage, configure, monitor, and upgrade the SG appliance from any location. The Management Console consists of a set of Web pages and Java applets stored on the SG appliance. The appliance acts as a Web server on the management port to serve these pages and applets.

management information base (MIB)

Defines the statistics that management systems can collect. A managed device (gateway) has one or more MIBs as well as one or more SNMP agents, which implements the information and management functionality defined by a specific MIB.

maximum object size

The maximum object size stored in the SG appliance. All objects retrieved that are greater than the maximum size are delivered to the client but are not stored in the SG appliance.

MIME/FILE type filtering

Allows organizations to implement Internet policies for both uploaded and downloaded content by MIME or FILE type.

multi-bit rate

The capability of a single stream to deliver multiple bit rates to clients requesting content from appliances from within varying levels of network conditions (such as different connecting bandwidths and traffic).

multicast

Used in streaming; the ability for hundreds or thousands of users to play a single stream.

multicast aliases

Used in streaming; a streaming command that specifies an alias for a multicast URL to receive an .nsc file. The .nsc files allows the multicast session to obtain the information in the control channel

multicast station

Used in streaming; a defined location on the proxy where the Windows Media player can retrieve streams. A multicast station enables multicast transmission of Windows Media content from the cache. The source of the multicast-delivered content can be a unicast-live source, a multicast (live) source, and simulated live (video-on-demand content converted to scheduled live content).

multimedia content services

Used in streaming; multimedia support includes Real Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N name inputing

Allows an SG appliance to resolve host names based on a partial name specification. When a host name is submitted to the DNS server, the DNS server resolves the name to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in the name-inputing list to the end of the host name and resubmits it to the DNS server

native FTP

Native FTP involves the client connecting (either explicitly or transparently) using the FTP protocol; the SG appliance then connects upstream through FTP (if necessary).

NCSA common log format

Blue Coat products are compatible with this log type, which contains only basic HTTP access information.

network address translation (NAT)

The process of translating private network (such as intranet) IP addresses to Internet IP addresses and vice versa. This methodology makes it possible to match private IP addresses to Internet IP addresses even when the number of private addresses outnumbers the pool of available Internet addresses.

98

Appendix A: Glossary

non-cacheable objects

A number of objects are not cached by the Blue Coat appliance because they are considered non-cacheable. You can add or delete the kinds of objects that the appliance considers non-cacheable. Some of the non-cacheable request types are: • Pragma no-cache, requests that specify non-cached objects, such as when you click refresh in the Web browser. • Password provided, requests that include a client password. • Data in request that include additional client data. • Not a GET request.

.nsc file

Created from the multicast station definition and saved through the browser as a text file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast station definition does not work.

NTP

To manage objects in an appliance, an SG appliance must know the current Universal Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 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.

O object (used in caching)

An object is the item that is stored in an appliance. These objects can be frequently accessed content, content that has been placed there by content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)

An object (sometimes referred to as a condition) is any collection or combination of entry types you can create individually (user, group, IP address/subnet, and attribute). To be included in an object, an item must already be created as an individual entry.

object pipelining

This patented algorithm opens as many simultaneous TCP connections as the origin server will allow and retrieves objects in parallel. The objects are then delivered from the appliance straight to the user's desktop as fast as the browser can request them.

origin content server (OCS)

Also called origin server. This is the original source of the content that is being requested. An appliance needs the OCS to acquire data the first time, to check that the content being served is still fresh, and to authenticate users.

outbound traffic (bandwidth gain)

Network packets flowing out of the SG appliance. Outbound traffic mainly consists of the following: • Client outbound: Packets sent to the client in response to a Web request. • Server outbound: Packets sent to an OCS or upstream proxy to request a service.

P PAC (Proxy AutoConfiguration) scripts

Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and port numbers to be entered for every protocol. You need only enter the URL. A PAC can be created with the needed information and the local browser can be directed to the PAC for information about proxy hosts and port numbers.

packet capture (PCAP)

Allows filtering on various attributes of the Ethernet frame to limit the amount of data collected. You can capture packets of Ethernet frames going into or leaving an SG appliance.

99

Volume 9: Managing the Blue Coat SG Appliance

parent class (bandwidth gain)

A class with at least one child. The parent class must share its bandwidth with its child classes in proportion to the minimum/maximum bandwidth values or priority levels.

passive mode data connections (PASV)

Data connections initiated by an FTP client to an FTP server.

pipelining

See object pipelining.

policies

Groups of rules that let you manage Web access specific to the needs of an enterprise. Policies enhance SG appliance feature areas such as authentication and virus scanning, and let you control end-user Web access in your existing infrastructure. See also refresh policies.

policy-based bypass list

Used in policy. Allows a bypass based on the properties of the client, unlike static and dynamic bypass lists, which allow traffic to bypass the appliance based on destination IP address. See also bypass lists and dynamic bypass.

policy layer

A collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)

A metatag in the header of a request that requires the appliance to forward a request to the origin server. This allows clients to always obtain a fresh copy (of the request?).

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 SG appliance, which can reference an existing security infrastructure—LDAP, RADIUS, IWA, and the like.

Proxy Edition

SGOS 5 Proxy Edition.

proxy service

The proxy service defines the ports, as well as other attributes. that are used by the proxies associated with the service.

proxy service (default)

The default proxy service is a service that intercepts all traffic not otherwise intercepted by other listeners. It only has one listener whose action can be set to bypass or intercept. No new listeners can be added to the default proxy service, and the default listener and service cannot be deleted. Service attributes can be changed.

public key certificate

An electronic document that encapsulates the public key of the certificate sender, identifies this sender, and aids the certificate receiver to verify the identity of the certificate sender. A certificate is often considered valid if it has been digitally signed by a well-known entity, which is called a Certificate Authority (such as VeriSign).

public virtual IP (VIP)

Maps multiple servers to one IP address and then propagates that information to the public DNS servers. Typically, there is a public VIP known to the public Internet that routes the packets internally to the private VIP. This enables you to “hide” your servers from the Internet.

100

Appendix A: Glossary

R real-time streaming protocol (RTSP)

A standard method of transferring audio and video and other time-based media over Internet-technology based networks. The protocol is used to stream clips to any RTPbased client.

reflect client IP attribute

Enables the sending of the client's IP address instead of the SG's IP address to the upstream server. If you are using an application delivery network (ADN), this setting is enforced on the concentrator proxy through the Configuration > App. Delivery Network > Tunneling tab.

registration

An event that binds the appliance to an account, that is, it creates the Serial#, Account association.

remote authentication dialin user service (RADIUS)

Authenticates user identity via passwords for network access.

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.

routing information protocol (RIP)

Designed to select the fastest route to a destination. RIP support is built into Blue Coat appliances.

router hops

The number of jumps a packet takes when traversing the Internet.

S secure shell (SSH)

Also known as Secure Socket Shell. SSH is an interface and protocol that provides strong authentication and enables you to securely access a remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via SSH is accomplished using a digital certificate and password encryption. Remember that the Blue Coat SG appliance requires SSH1. An SG appliance supports a combined maximum of 16 Telnet and SSH sessions.

serial console

A third-party device that can be connected to one or more Blue Coat appliances. Once connected, you can access and configure the appliance through the serial console, even when you cannot access the appliance directly.

server certificate categories

The hostname in a server certificate can be categorized by BCWF or another content filtering vendor to fit into categories such as banking, finance, sports.

server portals

Doorways that provide controlled access to a Web server or a collection of Web servers. You can configure Blue Coat SG appliances to be server portals by mapping a set of external URLs onto a set of internal URLs.

server-side transparency

The ability for the server to see client IP addresses, which enables accurate clientaccess records to be kept. When server-side transparency is enabled, the appliance retains client IP addresses for all port 80 traffic to and from the SG appliance. In this scheme, the client IP address is always revealed to the server.

service attributes

Define the parameters, such as explicit or transparent, cipher suite, and certificate verification, that the SG appliance uses for a particular service. .

101

Volume 9: Managing the Blue Coat SG Appliance

SG appliance

A Blue Coat security and cache box that can help manage security and content on a network.

sibling class (bandwidth gain)

A bandwidth class with the same parent class as another class.

simple network management protocol (SNMP)

The standard operations and maintenance protocol for the Internet. It uses MIBs, created or customized by Blue Coat, to handle (needs completion).

simulated live

Used in streaming. Defines playback of one or more video-on-demand files as a scheduled live event, which begins at a specified time. The content can be looped multiple times, or scheduled to start at multiple start times throughout the day.

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter tool.

SOCKS

A proxy protocol for TCP/IP-based networking applications that allows users transparent access across the firewall. If you are using a SOCKS server for the primary or alternate forwarding gateway, you must specify the appliance’s ID for the identification protocol used by the SOCKS gateway. The machine ID should be configured to be the same as the appliance’s name.

SOCKS proxy

A generic way to proxy TCP and UDP protocols. The SG appliance supports both SOCKSv4/4a and SOCKSv5; however, because of increased username and password authentication capabilities and compression support, Blue Coat recommends that you use SOCKS v5.

splash page

Custom message page that displays the first time you start the client browser.

split proxy

Employs co-operative processing at the branch and the core to implement functionality that is not possible in a standalone proxy. Examples of split proxies include: • Mapi Proxy • SSL Proxy

SQUID-compatible format

A log type that was designed for cache statistics and is compatible with Blue Coat products.

squid-native log format

The Squid-compatible format contains one line for each request.

SSL authentication

Ensures that communication is with “trusted” sites only. Requires a certificate issued by a trusted third party (Certificate Authority).

SSL interception

Decrypting SSL connections.

SSL proxy

A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or reverse proxy mode.

static route

A manually-configured route that specifies the transmission path a packet must follow, based on the packet’s destination address. A static route specifies a transmission path to another network.

102

Appendix A: Glossary

statistics

Every Blue Coat appliance keeps statistics of the appliance hardware and the objects it stores. You can review the general summary, the volume, resources allocated, cache efficiency, cached contents, and custom URLs generated by the appliance for various kinds of logs. You can also check the event viewer for every event that occurred since the appliance booted.

stream

A flow of a single type of data, measured in kilobits per second (Kbps). A stream could be the sound track to a music video, for example.

SurfControl log type

A proprietary log type that is compatible with the SurfControl reporter tool. The SurfControl log format includes fully-qualified usernames when an NTLM realm provides authentication. The simple name is used for all other realm types.

syslog

An event-monitoring scheme that is especially popular in Unix environments. Most clients using Syslog have multiple devices sending messages to a single Syslog daemon. This allows viewing a single chronological event log of all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time Hostname Event.”

system cache

The software cache on the appliance. When you clear the cache, all objects in the cache are set to expired. The objects are not immediately removed from memory or disk, but a subsequent request for any object requested is retrieved from the origin content server before it is served.

T time-to-live (TTL) value

Used in any situation where an expiration time is needed. For example, you do not want authentication to last beyond the current session and also want a failed command to time out instead of hanging the box forever.

traffic flow (bandwidth gain)

Also referred to as flow. A set of packets belonging to the same TCP/UDP connection that terminate at, originate at, or flow through the SG appliance. A single request from a client involves two separate connections. One of them is from the client to the SG appliance, and the other is from the SG appliance to the OCS. Within each of these connections, traffic flows in two directions—in one direction, packets flow out of the SG appliance (outbound traffic), and in the other direction, packets flow into the SG (inbound traffic). Connections can come from the client or the server. Thus, traffic can be classified into one of four types: • Server inbound • Server outbound • Client inbound • Client outbound These four traffic flows represent each of the four combinations described above. Each flow represents a single direction from a single connection.

transmission control protocol (TCP)

TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, in the form of message units called packets, between computers over the Internet. TCP is responsible for tracking and handling, and reassembly of the packets; IP is responsible for packet delivery.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

103

Volume 9: Managing the Blue Coat SG Appliance

trial period

Starting with the first boot, the trial period provides 60 days of free operation. All features are enabled during this time.

U unicast alias

Defines an name on the appliance for a streaming URL. When a client requests the alias content on the appliance, the appliance uses the URL specified in the unicastalias command to request the content from the origin streaming server.

universal time coordinates (UTC)

An SG appliance must know the current UTC time. By default, the appliance attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC time. If the SG appliance cannot access any NTP servers, you must manually set the UTC time.

URL filtering

See content filtering.

URL rewrite rules

Rewrite the URLs of client requests to acquire the streaming content using the new URL. For example, when a client tries to access content on www.mycompany.com, the appliance is actually receiving the content from the server on 10.253.123.123. The client is unaware that mycompany.com is not serving the content; however, the appliance access logs indicate the actual server that provides the content.

W WCCP

Web Cache Communication Protocol. Allows you to establish redirection of the traffic that flows through routers.

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and accesses an ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the OCS (if the content is not already cached), and then translates the FTP response with the file contents into an HTTP response for the client.

Websense log type

A Blue Coat proprietary log type that is compatible with the Websense reporter tool.

X

XML responder

HTTP XML service that runs on an external server.

XML requestor

XML realm.

104

Index

A access logging 87 active sessions 76 bypassed connections 84 proxied sessions 77 ADN history 68 appliance certificate 9 automatic service information, enabling 46

B bandwidth gain 64 bandwidth management 68 bandwidth usage 64 Blue Coat monitoring, enabling 58 Blue Coat SG deleting image 43 deleting objects from 44 locking and unlocking a system 42 managing 40 replacing a system 40, 42 restarting 33 setting the default system to boot 41 single-disk 44 system defaults 34 upgrading 37, 38 viewing details 40 bypassed bytes 63 bypassed connections 84 byte distribution 65

C cache contents 74 CacheOS 4.x, logs, retrieving 88 caching clearing the system cache 36 objects by size 74 purging the DNS cache 36 restarting the Blue Coat SG 33 capturing packets, see packet capturing community strings 21 concurrent users, viewing 71 core image restart options 57

CPU utilization 70 CPU monitoring configuring 59 CPU utilization 70 cpu utilization 70

D data allocation 73 default service 64 defaults, restoring system defaults 34 deleting objects from the Blue Coat SG 44 diagnostics Blue Coat monitoring 58 core image restart options 57 CPU monitoring 59 heartbeats 58 packet capturing 52 sending service information 48 sending service information automatically 46 snapshot jobs 50 Director communicating with 11 SG appliance registration and setup 9 disk multi-disk Blue Coat SG 43 reinitialization 43 single-disk Blue Coat SG 44 disk use 70, 72 disks 70 DNS cache, purging 36 document conventions 7

E empty system 40 event logging configuration, viewing 18 contents, viewing 19 event notification 16 log levels 15 log size 16 overview 15

105

Volume 9: Managing the Blue Coat SG Appliance

event logging statistics 75

O

F

objects deleting from Blue Coat SG 44 served by size 74

failover statistics 76 filter expressions for packet capturing 52

G graph scale 61

H health monitoring configuring 23 Director 23 general metrics 26 license expiration 25 licensing metrics 26 notification 26 properties, modifying 28 requirements 23 status metrics 27 thresholds 24 viewing statistics 30 health statistics 87 heartbeats, configuring 58

I image, deleting 43

L licensing restore-default deletions 35 locking and unlocking Blue Coat SG systems 42 logging see access logging and event logging SNMP 20 syslog event monitoring 17 logs CacheOS 4.x, retrieving 88 SGOS 2.x, retrieving 88

M Management Console, troubleshooting,browser troubleshooting 37 memory use 70, 72 MIBs 20

P packet capturing about 52 capturing 53 common filter expressions 52 file name format 52 uploading data 57 viewing current data 56 protocol details 68 proxied sessions MMS connections 81 multiple connections 81 tree view 82 purging the DNS cache 36

R rebooting, see restarting 33 replacing a Blue Coat SG system 42 reporting event logging 15 syslog event monitoring 17 resources concurrent users, viewing 71 restart core image 57 restarting the Blue Coat SG restart options 33 setting the default system to boot 41 restoring system defaults 34

S service information enabling automatic 46 sending 48 SG appliance active sessions 76 bypassed bytes 63 bypassed connections 84 byte distribution 65 controlling access 9 registering with Director 9 traffic history 65 traffic mix 62 SGOS 2.x, logs, retrieving 88

106

Index

Simple Network Management Protocol, see SNMP snapshot jobs creating and editing 50 SNMP community strings 21 enabling 20 MIB variables 20 MIBs 20 traps 22 SSH-Console service 10 SSHv2 host key 10 SSL accelerator cards, statistics, viewing 15 statistics cached objects by size 74 CPU utilization 70 data allocation 73 graph scale 61 objects served by size 74 system summary 12 syslog event monitoring 17 system cache clearing 36

system cache, troubleshooting 37 system defaults, restoring 34 system summary 12

T traffic history 65 supported proxies and services 66 traffic mix 62 supported proxies and services 66 traps 22 troubleshooting browsers 37 licenses disappear after restore-defaults command 35

U upgrading overview 37 system image from PC 38 through Management Console 38

107

Volume 9: Managing the Blue Coat SG Appliance

108

Blue Coat® Systems SG™ Appliance

Configuration and Management Guide: Volume 10: Content Policy Language Guide

Version SGOS 5.2.2

Volume 10: Content Policy Language Guide

Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contact.html [email protected] http://www.bluecoat.com For concerns or feedback about the documentation: [email protected] Copyright© 1999-2007 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. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, RA Connector™, RA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos 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-02847 Document Revision: SGOS 5.2.2—09/2007

ii

Contents Contact Information Preface: Introducing the Content Policy Language About the Document Organization .............................................................................................................. xiii Supported Browsers........................................................................................................................................ xiv Related Blue Coat Documentation................................................................................................................ xiv Document Conventions.................................................................................................................................. xiv Chapter 1: Overview of Content Policy Language Concepts .............................................................................................................................................................17 Transactions...............................................................................................................................................17 Policy Model..............................................................................................................................................18 Role of CPL ................................................................................................................................................19 CPL Language Basics........................................................................................................................................19 Comments ..................................................................................................................................................19 Rules ...........................................................................................................................................................19 Notes...........................................................................................................................................................20 Quoting ......................................................................................................................................................21 Layers .........................................................................................................................................................22 Sections.......................................................................................................................................................23 Definitions..................................................................................................................................................24 Referential Integrity..................................................................................................................................25 Substitutions ..............................................................................................................................................25 Writing Policy Using CPL ................................................................................................................................25 Authentication and Denial ......................................................................................................................26 Installing Policy.........................................................................................................................................27 CPL General Use Characters and Formatting ......................................................................................27 Troubleshooting Policy.....................................................................................................................................28 Upgrade/Downgrade Issues ...........................................................................................................................28 CPL Syntax Deprecations ........................................................................................................................29 Conditional Compilation.........................................................................................................................29 Chapter 2: Managing Content Policy Language Understanding Transactions and Timing......................................................................................................31 Transactions ............................................................................................................................31 Transactions ..............................................................................................................................32 Transactions.....................................................................................................................33 Transactions ..............................................................................................................................33 Transaction .........................................................................................................................34 Transactions....................................................................................................................34

iii

Blue Coat ProxySG Content Policy Language Guide

Transactions .................................................................................................................................. 34 Timing ........................................................................................................................................................ 35 Understanding Layers...................................................................................................................................... 35 Layers....................................................................................................................................... 36 Layers ........................................................................................................................................ 37 Layers.................................................................................................................................. 38 Layers.................................................................................................................................... 38 Layers......................................................................................................................................... 39 Layers ............................................................................................................................... 40 Layers ........................................................................................................................... 40 Layers............................................................................................................................................. 41 Layer Guards............................................................................................................................................. 41 Timing ........................................................................................................................................................ 42 Understanding Sections ................................................................................................................................... 42 [Rule] .......................................................................................................................................................... 43 [url] ............................................................................................................................................................. 44 [url.domain] .............................................................................................................................................. 44 [url.regex] .................................................................................................................................................. 44 [server_url.domain].................................................................................................................................. 44 Section Guards .......................................................................................................................................... 45 Defining Policies................................................................................................................................................ 45 Blacklists and Whitelists.......................................................................................................................... 46 General Rules and Exceptions to a General Rule ................................................................................ 46 Best Practices...................................................................................................................................................... 49 Chapter 3: Condition Reference Condition Syntax............................................................................................................................................... 51 Pattern Types ..................................................................................................................................................... 52 Unavailable Conditions.................................................................................................................................... 53 Layer Type Restrictions ........................................................................................................................... 53 Global Restrictions ................................................................................................................................... 53 Condition Reference ......................................................................................................................................... 53 admin.access=................................................................................................................................................... 54 attribute.name= ................................................................................................................................................ 55 authenticated= .................................................................................................................................................. 57 bitrate=............................................................................................................................................................... 58 category= ........................................................................................................................................................... 60 client.address=.................................................................................................................................................. 61 client.address.login.count=............................................................................................................................. 62 client.connection.dscp= ................................................................................................................................... 63 client.connection.negotiated_cipher= ........................................................................................................... 64 client.connection.negotiated_cipher.strength=............................................................................................ 65 client.connection.negotiated_ssl_version=................................................................................................... 66 client.host= ........................................................................................................................................................ 67 client.host.has_name= ..................................................................................................................................... 68

iv

Contents

client.protocol=................................................................................................................................................. 69 condition= ......................................................................................................................................................... 70 console_access= ................................................................................................................................................ 72 content_admin=................................................................................................................................................ 73 content_management ...................................................................................................................................... 74 date[.utc]= ......................................................................................................................................................... 75 day= ................................................................................................................................................................... 76 dns.client_transport=....................................................................................................................................... 77 dns.request.address=....................................................................................................................................... 78 dns.request.category= ..................................................................................................................................... 79 dns.request.class= ............................................................................................................................................ 80 dns.request.name=........................................................................................................................................... 81 dns.request.opcode=........................................................................................................................................ 82 dns.request.type=............................................................................................................................................. 83 dns.response.a= ................................................................................................................................................ 84 dns.response.cname= ...................................................................................................................................... 85 dns.response.code=.......................................................................................................................................... 86 dns.response.nodata=...................................................................................................................................... 87 dns.response.ptr=............................................................................................................................................. 88 exception.id= .................................................................................................................................................... 89 ftp.method= ...................................................................................................................................................... 91 group= ............................................................................................................................................................... 92 has_attribute.name= ........................................................................................................................................ 94 has_client= ........................................................................................................................................................ 95 health_check= ................................................................................................................................................... 96 hour=.................................................................................................................................................................. 97 http.connect= .................................................................................................................................................... 99 http.method= .................................................................................................................................................. 100 http.method.custom= .................................................................................................................................... 101 http.method.regex= ....................................................................................................................................... 102 http.request_line.regex= ............................................................................................................................... 103 http.request.version=..................................................................................................................................... 104 http.response.apparent_data_type=............................................................................................................ 105 http.response.code=....................................................................................................................................... 106 http.response.data= ....................................................................................................................................... 107 http.response.version= .................................................................................................................................. 108 http.transparent_authentication=................................................................................................................ 109 http.x_method= .............................................................................................................................................. 110 icap_error_code=............................................................................................................................................ 111 is_healthy.health_check_name= .................................................................................................................. 112 im.buddy_id= ................................................................................................................................................. 113 im.chat_room.conference=............................................................................................................................ 114 im.chat_room.id= ........................................................................................................................................... 115 im.chat_room.invite_only=........................................................................................................................... 116 im.chat_room.type=....................................................................................................................................... 117 im.chat_room.member=................................................................................................................................ 118 im.chat_room.voice_enabled= ..................................................................................................................... 119 im.client=......................................................................................................................................................... 120 im.file.extension= ........................................................................................................................................... 121

v

Blue Coat ProxySG Content Policy Language Guide

im.file.name= .................................................................................................................................................. im.file.path=.................................................................................................................................................... im.file.size= ..................................................................................................................................................... im.message.opcode=...................................................................................................................................... im.message.reflected= ................................................................................................................................... im.message.route= ......................................................................................................................................... im.message.size=............................................................................................................................................ im.message.text= ............................................................................................................................................ im.message.type=........................................................................................................................................... im.method=..................................................................................................................................................... im.user_agent= ............................................................................................................................................... im.user_id= ..................................................................................................................................................... live=.................................................................................................................................................................. minute= ........................................................................................................................................................... month= ............................................................................................................................................................ proxy.address= ............................................................................................................................................... proxy.card= ..................................................................................................................................................... proxy.port= ..................................................................................................................................................... p2p.client=....................................................................................................................................................... raw_url.regex= ............................................................................................................................................... raw_url.host.regex=....................................................................................................................................... raw_url.path.regex= ...................................................................................................................................... raw_url.pathquery.regex= ............................................................................................................................ raw_url.port.regex= ....................................................................................................................................... raw_url.query.regex= .................................................................................................................................... realm= .............................................................................................................................................................. release.id= ....................................................................................................................................................... release.version=.............................................................................................................................................. request.header.header_name= ..................................................................................................................... request.header.header_name.address= ...................................................................................................... request.header.header_name.count=............................................................................................................. request.header.header_name.length=............................................................................................................ request.header.Referer.url=.......................................................................................................................... request.header.Referer.url.category=.......................................................................................................... request.raw_headers.count= ........................................................................................................................ request.raw_headers.length= ....................................................................................................................... request.raw_headers.regex=......................................................................................................................... request.x_header.header_name=................................................................................................................. request.x_header.header_name.address= .................................................................................................. request.x_header.header_name.count=......................................................................................................... request.x_header.header_name.length= ....................................................................................................... response.header.header_name= .................................................................................................................. response.raw_headers.count=...................................................................................................................... response.raw_headers.length= .................................................................................................................... response.raw_headers.regex= ...................................................................................................................... response.x_header.header_name= .............................................................................................................. server.certificate.hostname.category= ........................................................................................................ server.connection.dscp=................................................................................................................................ server_url= ......................................................................................................................................................

vi

122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 149 150 151 152 153 154 155 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173

Contents

socks=............................................................................................................................................................... socks.accelerated= ......................................................................................................................................... socks.method=................................................................................................................................................ socks.version= ................................................................................................................................................ ssl.proxy_mode= ............................................................................................................................................ streaming.client=............................................................................................................................................ streaming.content= ........................................................................................................................................ time= ................................................................................................................................................................ tunneled= ........................................................................................................................................................ url= ................................................................................................................................................................... url.category=................................................................................................................................................... user=................................................................................................................................................................. user.authentication_error= ........................................................................................................................... user.authorization_error=............................................................................................................................. user.domain= .................................................................................................................................................. user.is_guest= ................................................................................................................................................. user.login.address=........................................................................................................................................ user.login.count= ........................................................................................................................................... user.login.time=.............................................................................................................................................. user.x509.issuer= ............................................................................................................................................ user.x509.serialNumber= .............................................................................................................................. user.x509.subject= .......................................................................................................................................... virus_detected= .............................................................................................................................................. weekday= ........................................................................................................................................................ year= ................................................................................................................................................................

176 177 178 179 180 181 182 183 185 186 193 194 196 197 198 199 200 201 202 203 204 205 206 207 208

Chapter 4: Property Reference Property Reference.......................................................................................................................................... 209 access_log( ) .................................................................................................................................................... 210 access_server( ) ............................................................................................................................................... 211 action( ) ........................................................................................................................................................... 212 adn.server( ) .................................................................................................................................................... 213 adn.server.optimize( ).................................................................................................................................... 214 adn.server.optimize.inbound( ) ................................................................................................................... 215 adn.server.optimize.outbound( ) ................................................................................................................. 216 advertisement( ) ............................................................................................................................................. 217 allow................................................................................................................................................................. 218 always_verify( ) ............................................................................................................................................. 219 authenticate() .................................................................................................................................................. 220 authenticate.authorization_refresh_time( ) ................................................................................................ 221 authenticate.charset( ).................................................................................................................................... 222 authenticate.credential_refresh_time() ....................................................................................................... 223 authenticate.credentials.address( ) .............................................................................................................. 224 authenticate.guest( )....................................................................................................................................... 225 authenticate.force( ) ...................................................................................................................................... 226 authenticate.form( )........................................................................................................................................ 227 authenticate.mode( ) ...................................................................................................................................... 228 authenticate.new_pin_form() ....................................................................................................................... 230 authenticate.query_form() ............................................................................................................................ 231

vii

Blue Coat ProxySG Content Policy Language Guide

authenticate.redirect_stored_requests()...................................................................................................... authenticate.surrogate_refresh_time() ........................................................................................................ authenticate.tolerate_error() ......................................................................................................................... authenticate.use_url_cookie( )...................................................................................................................... authorize.add_group() .................................................................................................................................. authorize.tolerate_error().............................................................................................................................. bypass_cache( ) .............................................................................................................................................. cache( ) ............................................................................................................................................................ category.dynamic.mode( ) ............................................................................................................................ check_authorization( ) ................................................................................................................................... client.address.login.log_out_other()............................................................................................................ client.certificate.require( ) ............................................................................................................................. client.certificate.validate( )............................................................................................................................ client.certificate.validate.check_revocation() ............................................................................................. client.connection.dscp()................................................................................................................................. cookie_sensitive( ) ......................................................................................................................................... delete_on_abandonment( ) ........................................................................................................................... deny( ) .............................................................................................................................................................. deny.unauthorized( ) ..................................................................................................................................... detect_protocol( ) ........................................................................................................................................... direct( ) ............................................................................................................................................................ dns.respond( ) ................................................................................................................................................. dns.respond.a( ) .............................................................................................................................................. dns.respond.ptr( )........................................................................................................................................... dynamic_bypass( ) ......................................................................................................................................... exception( )...................................................................................................................................................... exception.autopad( ) ...................................................................................................................................... force_cache( ) ................................................................................................................................................. force_deny( ) ................................................................................................................................................... force_exception( ) ........................................................................................................................................... force_patience_page( )................................................................................................................................... force_protocol( ) ............................................................................................................................................. forward( ) ........................................................................................................................................................ forward.fail_open( ) ....................................................................................................................................... ftp.match_client_data_ip( ) ........................................................................................................................... ftp.match_server_data_ip( ).......................................................................................................................... ftp.server_connection( )................................................................................................................................. ftp.server_data( ) ............................................................................................................................................ ftp.transport( ) ................................................................................................................................................ ftp.welcome_banner( )................................................................................................................................... http.allow_compression( ) ............................................................................................................................ http.allow_decompression( ) ........................................................................................................................ http.client.allow_encoding( )........................................................................................................................ http.client.persistence( ) ................................................................................................................................ http.client.recv.timeout( ).............................................................................................................................. http.compression_level( ).............................................................................................................................. http.force_ntlm_for_server_auth( ) ............................................................................................................. http.refresh.recv.timeout( ) ........................................................................................................................... http.request.version( ) ...................................................................................................................................

viii

232 233 234 235 236 237 238 239 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 281 282

Contents

http.response.parse_meta_tag.Cache-Control( ) ....................................................................................... http.response.parse_meta_tag.Expires( ).................................................................................................... http.response.parse_meta_tag.pragma-no-cache( ) .................................................................................. http.response.version( ) ................................................................................................................................ http.server.accept_encoding( ) ..................................................................................................................... http.server.accept_encoding.allow_unknown() ........................................................................................ http.server.connect_attempts( ).................................................................................................................... http.server.persistence( ) ............................................................................................................................... http.server.recv.timeout( ) ............................................................................................................................ icp( ).................................................................................................................................................................. im.block_encryption( ) .................................................................................................................................. im.reflect( ) ...................................................................................................................................................... im.strip_attachments( ) ................................................................................................................................. im.transport( )................................................................................................................................................. integrate_new_hosts( ) .................................................................................................................................. limit_bandwidth( ) ......................................................................................................................................... log.rewrite.field-id( )...................................................................................................................................... log.suppress.field-id( ) .................................................................................................................................. max_bitrate( ).................................................................................................................................................. never_refresh_before_expiry( ) .................................................................................................................... never_serve_after_expiry( ) .......................................................................................................................... patience_page( ).............................................................................................................................................. pipeline( ) ....................................................................................................................................................... reflect_ip( ) ..................................................................................................................................................... refresh( ) .......................................................................................................................................................... remove_IMS_from_GET( )............................................................................................................................ remove_PNC_from_GET( ) .......................................................................................................................... remove_reload_from_IE_GET( ).................................................................................................................. request.filter_service( ) .................................................................................................................................. request.icap_service( ) .................................................................................................................................. response.icap_feedback( ) ............................................................................................................................. response.icap_feedback.force_interactive( )............................................................................................... response.icap_feedback.interactive( ) ......................................................................................................... response.icap_feedback.non_interactive( ) ................................................................................................ response.icap_service( ) ................................................................................................................................ response.raw_headers.max_count()............................................................................................................ response.raw_headers.max_length()........................................................................................................... response.raw_headers.tolerate() .................................................................................................................. server.certificate.validate() ........................................................................................................................... server.certificate.validate.check_revocation()............................................................................................ server.certificate.validate.ignore() ............................................................................................................... server.connection.dscp() ............................................................................................................................... shell.prompt( ) ................................................................................................................................................ shell.realm_banner( ) ..................................................................................................................................... shell.welcome_banner( ) ............................................................................................................................... socks.accelerate( ) ........................................................................................................................................... socks.allow_compression( ) .......................................................................................................................... socks.authenticate( )....................................................................................................................................... socks.authenticate.force( ).............................................................................................................................

283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 313 315 317 319 321 323 325 326 327 328 329 330 331 332 333 334 335 336 337 338

ix

Blue Coat ProxySG Content Policy Language Guide

socks_gateway( ) ............................................................................................................................................ socks_gateway.fail_open( )........................................................................................................................... socks_gateway.request_compression( )...................................................................................................... ssl.forward_proxy( ) ...................................................................................................................................... ssl.forward_proxy.hostname( ) .................................................................................................................... ssl.forward_proxy.issuer_keyring( ) ........................................................................................................... ssl.forward_proxy.server_keyring( )........................................................................................................... ssl.forward_proxy.splash_text( ).................................................................................................................. ssl.forward_proxy.splash_url( ) ................................................................................................................... streaming.transport( ).................................................................................................................................... terminate_connection( )................................................................................................................................. trace.destination( ) ......................................................................................................................................... trace.request( ) ............................................................................................................................................... trace.rules( ) .................................................................................................................................................... trust_destination_ip() .................................................................................................................................... ttl( ) ................................................................................................................................................................... ua_sensitive( ) ................................................................................................................................................ user.login.log_out( )....................................................................................................................................... user.login.log_out_other( ) ...........................................................................................................................

339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357

Chapter 5: Action Reference Argument Syntax ............................................................................................................................................ 359 Action Reference ............................................................................................................................................. 359 append( ) ........................................................................................................................................................ 360 delete( ) ........................................................................................................................................................... 361 delete_matching( ) ......................................................................................................................................... 362 im.alert( ) ......................................................................................................................................................... 363 log_message( ) ............................................................................................................................................... 364 notify_email( ) ................................................................................................................................................ 365 notify_snmp( ) ............................................................................................................................................... 366 redirect( ) ........................................................................................................................................................ 367 rewrite( ) .......................................................................................................................................................... 369 set( ) .................................................................................................................................................................. 372 transform ......................................................................................................................................................... 374 Chapter 6: Definition Reference Definition Names ............................................................................................................................................ 377 define action.................................................................................................................................................... 378 define active_content ..................................................................................................................................... 380 define category ............................................................................................................................................... 382 define condition.............................................................................................................................................. 384 define javascript ............................................................................................................................................. 386 define policy.................................................................................................................................................... 388 define server_url.domain condition............................................................................................................ 389 define string .................................................................................................................................................... 391 define subnet................................................................................................................................................... 392 define url condition ....................................................................................................................................... 393 define url.domain condition ......................................................................................................................... 395 define url_rewrite........................................................................................................................................... 397

x

Contents

restrict dns....................................................................................................................................................... restrict rdns ..................................................................................................................................................... transform active_content .............................................................................................................................. transform url_rewrite ....................................................................................................................................

399 400 401 402

Appendix A: Glossary 403 Appendix B: Testing and Troubleshooting Enabling Rule Tracing ........................................................................................................................... 407 Enabling Request Tracing ..................................................................................................................... 408 Using Trace Information to Improve Policies .................................................................................... 409 Appendix C: Recognized HTTP Headers Appendix D: CPL Substitutions Available Substitutions .................................................................................................................................. 417 Access Log Fields ............................................................................................................................................ 418 Timestamp Modifiers............................................................................................................................. 448 String Modifiers ...................................................................................................................................... 450 Host Modifiers ........................................................................................................................................ 450 Appendix E: Using Regular Expressions Regular Expression Syntax ............................................................................................................................ 454 Regular Expression Details............................................................................................................................ 455 Backslash.................................................................................................................................................. 456 Circumflex and Dollar ........................................................................................................................... 457 Period (Dot) ............................................................................................................................................ 458 Square Brackets....................................................................................................................................... 458 Vertical Bar .............................................................................................................................................. 459 Lowercase-Sensitivity ............................................................................................................................ 459 Subpatterns.............................................................................................................................................. 460 Repetition................................................................................................................................................. 461 Back References ...................................................................................................................................... 463 Assertions ................................................................................................................................................ 463 Once-Only Subpatterns ......................................................................................................................... 465 Conditional Subpatterns........................................................................................................................ 465 Comments................................................................................................................................................ 466 Performance ............................................................................................................................................ 466 Regular Expression Engine Differences From Perl .................................................................................... 466

xi

Blue Coat ProxySG Content Policy Language Guide

xii

Preface:

Introducing the Content Policy Language

The Blue Coat® Content Policy Language (CPL) is a powerful, flexible language that enables you to specify a variety of authentication, Web-access, and networking policies. SG appliance policy is written in CPL, and every Web request is evaluated based on the installed policy. The language is designed so that policies can be customized to an organization’s specific set of users and unique enforcement needs. CPL uses the settings created when you configured the SG appliance to your specifications. CPL has the following capabilities: •

Fine-grained control over various aspects of SG appliance behavior.

•

Layered policy, allowing for multiple policy decisions for each request.

•

Multiple actions triggered by a particular condition.

•

Flexibility of user-defined conditions and actions.

•

Convenience of predefined common actions and transformations.

•

Authentication-aware policy, including user and group configuration.

•

Support for multiple authentication realms.

•

Configurable policy event logging.

•

Built-in debugging.

About the Document Organization This document is organized for easy reference, and is divided into the following sections and chapters: Table 3.1: Manual Organization Chapter 1 – Overview of Content Policy

Language

This chapter provides an overview of CPL, including concepts, CPL basics, writing and troubleshooting policy and upgrade/downgrade issues.

Chapter 2 – Managing CPL

Building upon Chapter 1, this chapter discusses understanding transactions, timing, layers, and sections, defining policies, and best practices.

Chapter 3 – Conditions

This reference guide contains the list of conditions that are supported by CPL and provides an explanation for the usage.

Chapter 4 – Properties

This reference guide contains the list of properties that are supported by CPL and provides an explanation for the usage.

Chapter 5 – Actions

This reference guide contains the list of actions that are supported by CPL and provides an explanation for the usage.

Chapter 6 – Definitions

This reference guide contains the list of definitions that are supported by CPL and provides an explanation for the usage.

Appendix A – Glossary

Terms used in this manual are defined in this appendix.

xiii

Volume 10: Content Policy Language Guide

Table 3.1: Manual Organization (Continued) Appendix B – Troubleshooting

Using policy trace properties is explained in this appendix.

Appendix C – Recognized HTTP Headers This appendix lists all recognized HTTP 1.1 headers and indicates how the SG appliance interacts with them. Appendix D – CPL Substitutions

This appendix lists all substitution variables available in CPL.

Appendix E—Using Regular Expressions This appendix discusses regular expressions and how to use them.

Supported Browsers The SG appliance Management Console supports Microsoft® Internet Explorer Internet Explorer 7.0, Internet Explorer 6.0 (SP1 or later), Firefox 1.0, Netscape 7.2. Later versions might work, but they have not been tested. The Management Console uses the Java Runtime Environment. JRE 1.5.0 and 1.4.1_07 are both supported.

Related Blue Coat Documentation Blue Coat 200 Series Installation Guide Blue Coat 400 Series Installation Guide Blue Coat 5100 Series Installation Guide Blue Coat 800 Series Installation Guide Blue Coat 810 Series Installation Guide Blue Coat 8000 Series Installation Guide Blue Coat 8100 Series Installation Guide Blue Coat Systems Command Line Interface Reference

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

xiv

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 SG appliance literal to be entered as shown.

{ }

One of the parameters enclosed within the braces must be supplied

[ ]

An optional parameter or parameters.

Chapter :

Table 3.2: Typographic Conventions (Continued) Conventions

Definition

|

Either the parameter before or after the pipe character can or must be selected, but not both. To more clearly indicate that only one can be chosen, no spaces are put between the pipe and the options.

xv

Volume 10: Content Policy Language Guide

xvi

Chapter 1:

Overview of Content Policy Language

The Blue Coat® Content Policy Language (CPL) is a programming language with its own concepts and rules that you must follow. This chapter provides an overview of CPL, including the following topics: •

"Concepts"

•

"CPL Language Basics"

•

"Writing Policy Using CPL"

•

"Troubleshooting Policy"

•

"Upgrade/Downgrade Issues"

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

User Authentication requirements

•

Access to Web-related resources

•

Cache content

•

Various aspects of request and response processing

•

Access logging

You can create policy rules using either the Visual Policy Manager (VPM), which is accessible through the Management Console, or by composing CPL. Before reading sample CPL or trying to express your own policies in CPL, Blue Coat recommends that you understand the fundamental concepts underlying policy enforcement in the SG appliances. This section provides an overview of important concepts.

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

17

Volume 10: Content Policy Language Guide

The transaction serves the following purposes: •

Exposes request and response state for testing during policy evaluation. This provides the ability to test various aspects of a request, such as the IP address of the client and the URL used, or the response, such as the contents of any HTTP headers.

•

Ensures policy integrity during processing. The lifetime of a transaction may be relatively long, especially if a large object is being fetched over slow networks and subjected to off-box processing services such as content filtering and virus scanning. During this time, changes to configuration or policy rules may occur, which would result in altering the policy decisions that affect a transaction. If a request was evaluated against one version of policy, and some time later the associated response were evaluated against a different version of policy, the outcome would be unpredictable and possibly inconsistent. The transaction ensures that both the request and the response are evaluated against the version of policy that was current when the transaction was created. To ensure that new policy is respected, long lived transactions such as those involved in streaming, or large file downloads, are re-evaluated under new policy. Re-evaluation applies to both the request and response, and any resulting new decisions that cannot be honoured (such as new authentication requirements) result in transaction termination.

•

Maintains policy decisions relevant to request and response processing.

•

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

•

In a few special cases, two or more transactions can be created for a single request. For example, if an HTTP request is made via the SOCKS proxy (on port 1080 of the SG appliance), then it is possible for two transactions to be created: a SOCKS proxy transaction, and an HTTP proxy transaction. You can see these transactions for yourself if you turn on policy tracing. A new entry is added to the policy trace file for each transaction.

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

Administrator Transaction— the default is to deny requests. By default, administration is only available through one of the methods that bypasses policy evaluation. These are: ❐

accessing the CLI through the serial console

❐

accessing the CLI through RSA authenticated SSH

❐

logging into the Management Console or CLI using the console credentials

Specific rights must be granted through policy to enable other administration methods. •

18

Cache Transactions—the default is to allow requests.

Chapter 1: Overview of Content Policy Language

These requests originate from the SG appliance itself, and are used primarily to maintain the state of content. Additional policy can be added to specifically deny requests for specific content, and to distinguish content management requests from other cache transactions. •

Proxy Transactions—the default is taken from system configuration. For new SG appliances, the default is to deny all requests. For SG appliances being upgraded from 4.x, the default is to allow all requests. In either case, the SG appliance can be configured for either default. The default setting is displayed in policy listings.

The proper approach to writing layer policy depends on whether or not the default is to allow or deny requests. The default proxy policy is configurable and represents the starting point for writing policy to control proxy transactions. The default proxy policy is reported at the top of every policy listing generated by the SG appliance. ; Default proxy policy is DENY

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

Role of CPL CPL is the language used to express policy that depends on the runtime evaluation of each transaction. Policy is written in CPL, installed on the SG appliance, and is evaluated during request processing to override any default decisions taken from configuration.

CPL Language Basics The following sections provide an overview of the CPL language. In order to concentrate on higher level themes, CPL elements are informally introduced and discussed. Detailed specifications for each of these elements is left to the reference portion of this manual.

Comments Any line starting with ‘;’ is a comment. A semicolon (;) following a space or tab introduces a comment that extends to the end of the line (except where the semicolon appears inside quotes as part of a trigger pattern expression or property setting). For example: ; This is a comment.

Comments can appear anywhere in policy.

Rules A policy rule consists of a condition and some number of property settings, written in any order. Rules are generally written on a single line, but can be split across lines using a special line continuation character. When a rule is evaluated, the condition is tested for that particular transaction. If the condition evaluates to True, then all of the listed property settings are executed and evaluation of the current layer ends. The rule is said to match. If the condition evaluates to False for that transaction, it is said to miss.

19

Volume 10: Content Policy Language Guide

In turn, a condition is a boolean combination of trigger expressions. Triggers are individual tests that can be made against components of the request (url=), response (response.header.Content-Type=), related user (user=, group=), or system state (time=). With a few notable exceptions, triggers test one aspect of request, response, or associated state against a boolean expression of values. For the conditions in a rule, each of the triggers is logically anded together. In other words, the condition is only true if each one of the trigger expressions is true. Properties are settings that control transaction processing, such as deny, or the handling of the object, such as cache(no), indicating that the object is not to be cached locally. At the beginning of a transaction, all properties are set to their default values. As the policy is evaluated in sequence, rules that match might set a property to a particular value. A property retains the final value setting when evaluation ends, and the transaction is processed accordingly. Properties that are not set within the policy maintain their default values. The logical form of a policy rule could be expressed as: if condition is true then set all listed properties as specified

The following is an example of a simple policy rule: url.domain=example.com time=0900..1700 exception(policy_denied)

It states that the exception( ) property is set to policy_denied if both of the following triggers test true: •

The request is made for a page from the domain example.com

•

The request is made between 9 a.m. and 5 p.m.

Notes •

CPL triggers have the form trigger_name=pattern_expression

•

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

•

The text in policy rules is case-insensitive, with a few exceptions identified in the following chapters.

•

Non-ascii characters cannot occur within a CPL source file.

•

Policy listings are normalized in several ways. First, condition and action definitions which may appear anywhere in the source, will be grouped following the policy rules. Second, the order of the conditions and properties on a rule may change, since the CPL compiler always puts a deny or allow at the beginning of the rule, and orders conditions to optimize evaluation. Finally, several phrases are synonyms for phrases that are preferred. In the output of show policy, the preferred form is listed instead of the synonym. Four such synonyms are: • exception(authorization_failed), which is a synonym for the preferred deny.unauthorized

•

20

force_exception(authorization_failed), which is a synonym for the preferred force_deny.unauthorized

Chapter 1: Overview of Content Policy Language

•

•

exception(policy_denied), which is a synonym for the preferred deny

•

exception(no), which is a synonym for the preferred allow.

More complex boolean expressions are allowed for the pattern_expression in the triggers. For example, the second part of the condition in the simple rule shown above could be “the request is made between 9 a.m. and noon or between 1 p.m. and 5 p.m”, expressed as: ... time=(0900..1200 || 1300..1700) ...

Boolean expression are built from the specific values allowed with the trigger, and the boolean operators ! (not), && (and), || (or) and () for grouping. More details are found in the Trigger Reference chapter. Alternative values may also be separated by a comma—this is often more readable than using the ‘||’ operator. For example, the following rule will deny service to requests for pages in either one of the two domains listed. url.domain=(example.com, another.com) deny

•

Long lines can be split using ‘\’ as a line continuation character. The ‘\’ must be the last character on the line and be preceded by space or Tab. For example: url.domain=example.com time=0900..1700 \ deny

Do not use a semicolon to add comments within such a continued line: everything following the semicolon, including text on the continued lines, will be treated as part of the comment. For example: url.domain=example.com \ ; misplaced comment deny

becomes url.domain=example.com ; misplaced comment deny

In other words, the effect was to continue the comment.

Quoting Certain characters are considered special by CPL and have meaning as punctuation elements of the language. For example = (equal) separates a trigger name from its associated value, and blank space separates expressions in a rule. To use a value that contains one of these characters, the value must be quoted with either single (') or double (") quotation marks, so that the special characters are not interpreted as punctuation. Text within single quotation marks can include any character other than a single quotation mark. Text within double quotation marks can include any character other than a double quotation mark. Here are some examples of where quoting is necessary: user="John Doe" ; value contains a space url="www.example.com/script.cgi?param=value"

; value contains ‘=’

deny( "You don’t have access to that page!" ) ; several special chars

21

Volume 10: Content Policy Language Guide

The full list of characters that should be quoted when they appear can be found in the reference manual. Note that you can quote any string in CPL without affecting interpretation, even if the quotes are not strictly needed. For convenience, you can quote any value that consists of more than letters and/or numbers. user="john.doe" ; quotes not required, but can be used

Important: Within a define action or define url_rewrite statement, you must use double quotes ("), not single quotes (') to delimit a string.

Layers A policy layer is a CPL construct used to evaluate a set of rules and reach one decision. Separating decisions helps control policy complexity, and is done through writing each decision in a separate layer. Each layer has the form: [layer_condition][layer_properties] ... layer_content

where: •

The layer_type defines the transactions evaluated against this policy, and restricts the triggers and properties allowed in the rules used in the layer. For more information, see "Understanding Layers" on page 35.

•

The optional action, separated from the layer type by space, is a CPL User-defined Identifier (see "Understanding Sections" on page 42), basically an alphabetic character followed by alphanumeric or underscore characters.

•

The optional layer_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated.

•

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

•

The layer_content is a list of rules, possibly organized in sections. (see following). A layer must contain at least one rule.

Collectively, the layer_condition and layer_properties are often referred to as a layer guard expression. If a rule has the logical form “if (condition is true) then set properties”, a layer has the form: if (layer_condition is true) then { if (rule1_condition is true) then set layer_properties then set rule1 properties else if (rule2_condition is true) then set layer_properties then set rule2 properties else if (rule3_condition is true) then set layer_properties then set rule3 properties ... }

22

Chapter 1: Overview of Content Policy Language

Within a layer, the first rule that matches terminates evaluation of that layer. Layers within a policy are evaluated from top to bottom, with rules in later layers taking precedence over rules in earlier layers. In CPL, all policy rules are written in a layer. A rule cannot appear in policy preceding any layer header.

Sections The rules in layers can optionally be organized in one or more sections, which is a way of grouping rules together. A section consists of a section header followed by a list of rules. A section has the form: [section_type

[action]] [section_condition][section_properties]

section_content

where: •

The section_type defines the syntax of the rules used in the section, and the evaluation strategy used to evaluate those rules. The square brackets [ ] surrounding the section name (and optional action) are required.

•

The optional action, separated from the section type by space, is a CPL User-defined Identifier similar to a layer action.

•

The optional section_condition is a list of triggers, all of which must evaluate to true before the section content is evaluated.

•

The optional section_properties is a list of properties that will become the default settings for those properties for any rule matched in the section. These override any layer property defaults and can in turn be overridden by explicitly setting a different value for that property in a rule within the section.

•

The section_content is a list of rules. A section must contain at least one rule.

Collectively, the section_condition and section_properties are often referred to as a section guard expression. A layer with sections has the logical form: if (layer_condition is true) then { if (section1_condition is true then { if (rule1A_condition is true) then set layer_properties then section_properties then rule1A properties else if (rule1B_condition is true) then set layer_properties then section_properties then set rule1B properties .... } else if (section2_condition is true then { if (rule2A_condition is true) then

23

Volume 10: Content Policy Language Guide

set layer_properties then section_properties then rule2A properties else ... } ... }

Definitions Two types of definitions are used in CPL: •

Named definitions that are explicitly referenced by policy

•

Anonymous definitions that apply to all policy evaluation and are not referenced directly in rules.

Named Definitions There are various types of named definitions. Each definition is given a user defined name that is then used in rules to refer to the definition. This section highlights a few of the definition types, as an overview of the topic. See Chapter 6: “Definition Reference” on page 377 for more details. Subnet Definitions Subnet definitions are used to define a list of IP addresses or IP subnet masks that can be used to test any of the IP addresses associated with the transaction, for example, the client’s address or the request’s destination address. Condition Definitions Condition definitions can include any triggers that are legal in the layer referencing the condition. The condition= trigger is the exception to the rule that triggers can test only one aspect of a transaction. Since conditions definitions can include other triggers, condition= triggers can test multiple parts of

the transaction state. Also, condition definitions allow for arbitrary boolean combinations of trigger expressions. Category Definitions Category definitions are used to extend vendor content categories or to create your own. These categories are tested (along with any vendor defined categories) using the category= trigger. Action Definitions An action takes arguments and is wrapped in a named action definition block. Actions are turned on or off for a transaction through setting the action( ) property. The action property has syntax that allows for individual actions to be turned on and off independently. When the action definition is turned on, any actions it contains operate on their respective arguments. Transformer Definitions A transformer definition is a kind of named definition that specifies a transformation that is to be applied to an HTTP response. There are three types: url_rewrite definitions, active_content definitions, and javascript definitions.

24

Chapter 1: Overview of Content Policy Language

Anonymous Definitions Two types of anonymous definitions modify policy evaluation, but are not referenced by any rules. These definitions serve to restrict DNS and Reverse-DNS lookups and are useful in installations where access to DNS or Reverse-DNS resolution is limited or problematic.

Referential Integrity Policy references many objects defined in system configuration, such as authentication realms, forward hosts, SOCKS gateways, and the like. CPL enforces the integrity of those references by ensuring that the entities named in policy exist and have appropriate characteristics at the time the policy is compiled. During runtime, any attempts to remove a configured object that is referenced by currently active policy will fail. To remove a configured entity, such as a realm, that is referenced by policy, new policy must be installed with all references to that realm removed. New transactions will open against a version of policy that does not require the realm. Once all outstanding transactions that required reference to the realm have completed, the realm can be removed from configuration.

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

For example, the substitution $(user) expands to the authenticated user name associated with the transaction. If policy did not require that user to authenticate, the substitution expands to an empty string. Substitutions can also be used directly in the values specified to some CPL properties, such as when setting text in a message that will be displayed to users. Substitutions are available for a variety of purposes. For a categorized list of the substitutions available, see Appendix D: “CPL Substitutions” on page 417.

Writing Policy Using CPL A policy file is the unit of integration used to assemble policy. Policy written in CPL is stored in one of four files on the SG appliance. These files are the following: •

VPM: This file is reserved for use by the Visual Policy Manager.

•

Local: When the VPM is not being used, the Local file will typically contain the majority of the policy rules for a system. When the VPM is being used, this file might be empty, it might include rules for advanced policy features that are not available in the VPM, or it might otherwise supplement VPM policy.

•

Central: This file is typically managed by Blue Coat Systems, although you can have the SG appliance point to a custom Central policy file instead.

25

Volume 10: Content Policy Language Guide

•

Forward: The Forward policy file is normally used for all Forward policy, although you can use it to supplement any policy created in the other three policy files. The Forward policy file will contain Advanced Forwarding rules when the system is upgraded from a previous version of SGOS (2.x) or CacheOS (4.x).

Each of the files may contain rules and definitions, but an empty file is also legal. (An empty file specifies no policy and has no effect on the SG appliance.) Cross file references are allowed but the definitions must be installed before the references, and references must be removed before definitions are removed. The final installed policy is assembled from the policy stored in the four files by concatenating their contents. The order of assembly of the VPM, Central and Local policy files is configurable. The recommended evaluation order is VPM, Local, Central. The Forward policy file is always last.

Authentication and Denial One of the most important timing relationships to be aware of is the relation between authentication and denial. Denial can be done either before or after authentication, and different organizations have different requirements. For example, suppose an organization requires the following: •

Protection from denial of service attacks by refusing traffic from any source other than the corporate subnet.

•

The user name of corporate users is to be displayed in access logs, even when the user request has been denied.

The following example demonstrates how to choose the correct CPL properties. First, the following is a sample policy that is not quite correct: define subnet corporate_subnet 10.10.12.0/24 end client.address=!corporate_subnet deny ; filter out strangers authenticate(MyRealm) ; this has lower precedence than deny ; user names will NOT be displayed in the access log for the denied requests category=Gambling exception(content_filter_denied)

In this policy, requests coming from outside the corporate subnet are denied, while users inside the corporate subnet are asked to authenticate. Content categories are determined from the request URL and can be determined before authentication. Deny has precedence over authentication, so this policy denies the user request before the user is challenged to authenticate. Therefore, the user name is not available for access logging. Note that the precedence relation between deny and authenticate does not depend on the order of the layers, so changing the layer order will not affect the outcome. The CPL property force_authenticate(), however, has higher precedence than deny, so the following amended policy ensures that the user name is displayed in the access logs: define subnet corporate_subnet 10.10.12.0/24 end

26

Chapter 1: Overview of Content Policy Language

client.address=!corporate_subnet deny ; filter out strangers force_authenticate(MyRealm) ; this has higher precedence than deny ; user names will be displayed in the access log for the denied requests category=Gambling exception(content_filter_denied)

The timing for authentication over the SOCKS protocol is different. If you are using the SOCKS authentication mechanism, the challenge is issued when the connection is established, so user identities are available before the request is received, and the following policy would be correct. define subnet corporate_subnet 10.10.12.0/24 end client.address=!corporate_subnet deny ; filter out strangers socks.authenticate(MyRealm) ; this happens earlier than the category test ; user names be displayed in the access log for the denied requests category=Gambling exception(content_filter_denied)

Note that this only works for SOCKS authenticated users.

Installing Policy Policy is installed by installing one of the four policy files (VPM, Local, Central or Forward). Installing one new file causes the most recent versions of the other three files to be loaded, the contents concatenated in the order specified by the current configuration, and the resulting complete policy compiled. If any compilation errors are detected, the new policy file is not installed and the policy in effect is unchanged. Refer to Volume 7: The Visual Policy Manager and Advanced Policy Tasks for specific instructions on installing a policy file.

CPL General Use Characters and Formatting The following characters and formatting have significance within policy files in general, outside of the arguments used in condition expressions, the values used in property statements, and the arguments used in actions. Character

Example

Significance

Semicolon (;)

; Comment

Used either inline or at the beginning of a line to introduce text to be ignored during policy evaluation. Commonly used to provide comments.

; Comment

27

Volume 10: Content Policy Language Guide

Character

Example

Newline

deny server_url.scheme=mms deny CPL expects most constructs (layers, server_url.domain=xyz.com sections, rules, definitions) to begin on a new line. When not preceded by a line continuation character, a newline terminates a layer header, section header, the current rule, clause within a defined condition, or action within an action definition.

Significance

Line Continuation

\

A line continuation character indicates that the current line is part of the previous line.

Whitespace

< proxy > weekday = ( 3 || 7 ) deny

Used to enhance readability. Whitespace can be inserted between tokens, as shown in this example, without affecting processing. In addition, quoted strings can include whitespace. However, numeric ranges, such as weekday = 1..7, cannot contain whitespace.

Angle brackets (< >)

Used to mark layer headings.

Square brackets ([ ])

[Rule]

Used to mark section names.

Equal sign (=)

server_url.scheme=mms

Used to indicate the value a condition is to test.

Parentheses ( )

max_bitrate(no)

Used to enclose the value that a property is to be set to, or group components of a test.

Troubleshooting Policy When installed policy does not behave as expected, use policy tracing to understand the behavior of the installed policy. Tracing records additional information about a transaction and re-evaluates the transaction when it is terminated; however, it does not show the timing of evaluations through transaction processing. The extra processing required significantly impacts performance, so do not enable tracing in production environments unless you need to reproduce and diagnose a problem. If tracing is used on a system in production, attempt to restrict which transactions are traced. For example, you can trace only requests from a test workstation by defining the tracing rules as conditional on a client.address= trigger that tests for that workstation's IP address. For more information on generating and retrieving policy trace, see Appendix B: "Testing and Troubleshooting". While policy traces can show the rule evaluation behavior, they do not show the final effect of policy actions like HTTP header or URL modifications. To see the result of these policy actions it is often useful to actually view the packets sent and received. The PCAP facility can be used in conjunction with tracing to see the effect of the actions set by the matching rules.

Upgrade/Downgrade Issues Specific upgrade downgrade issues will be mentioned in the release notes accompanying your version of SGOS. This section highlights general upgrade downgrade issues related to policy written in CPL.

28

Chapter 1: Overview of Content Policy Language

CPL Syntax Deprecations As the power of CPL has increased, the CPL language has evolved. To allow continuous evolution, the CPL language constructs are now more regular and flexible. Older language constructs have been replaced with new constructs of equal or greater power. However, this also implies that support for old language constructs will eventually be dropped to help maintain the runtime efficiency of evaluation. As part of the migration strategy, the CPL compilation warnings might include warnings regarding the use of deprecated constructs. This class of warning is special, and indicates use of a CPL language element that will not be supported in the next major release of SGOS. Eliminate deprecation warnings by migrating the policy identified by the warning to more modern syntax, which is usually indicated in the warning message. Attempts to upgrade to the next major release might fail, or result in a failure to load policy, unless all deprecation warnings are eliminated.

Conditional Compilation Occasionally, you might be required to maintain policy that can be applied to appliances running different versions of SGOS and requiring different CPL. CPL provides the following conditional compilation directive that tests the SGOS version (such as 2.1.06): release.version=

The range is a standard CPL range test: min..max, where both minimum and maximum are optional. The min and max can be MAJOR.MINOR.DOT.PATCH, with MINOR, DOT and PATCH optional. Therefore, rules containing grammar introduced in 2.1.07 can be protected with #if release.version=2.1.07.. ; guarded rules ... #endif

while grammar introduced in 2.2 can be protected with: #if release.version=2.2.. ; guarded rules ... #endif

29

Volume 10: Content Policy Language Guide

30

Chapter 2:

Managing Content Policy Language

As discussed in Chapter 1, Content Policy Language policies are composed of transactions that are placed into rules and tested against various conditions. This chapter discusses the following: •

"Understanding Transactions and Timing"

•

"Understanding Layers"

•

"Understanding Sections"

•

"Defining Policies"

•

"Best Practices"

Understanding Transactions and Timing Transactions are classified as in several different types: •

•

•

•

•

•

•

•

Only a subset of layer types, conditions, properties, and actions is appropriate for each of these four transaction types.

Transactions An administrator transaction evaluates policy in layers. The policy is evaluated in two stages: •

Before the authentication challenge.

•

After the authentication challenge.

If an administrative user logs in to the SG appliance Management Console, and the administrator’s Web browser is proxied through that same SG appliance, then a proxy transaction is created and policy is evaluated before the administrator transaction is created and policy is evaluated. In this case, it is possible for an administrator to be denied access to the Management Console by proxy policy.

31

Volume 10: Content Policy Language Guide

Important: Policy is not evaluated for serial console access, RSA authenticated SSH access, managers logged in using the console account credentials, or SNMP traffic.

Transactions When a client connects to one of the proxy service ports configured on the secure proxy appliance (refer to Volume 3: Proxies and Proxy Services), a proxy transaction is created to cover both the request and its associated response. Note that requests for DNS proxy services are handled separately from requests for higher level services; see the following transactions section. A proxy transaction evaluates policy in , , , and layers. The layers are only evaluated if the transaction reaches the stage of contacting an origin server to satisfy the request (this is not the case if the request is satisfied by data served from cache, or if the transaction is terminated by an exception). The layers are only evaluated if the transaction is terminated by an exception. Each of the protocol-specific proxy transactions has specific information that can be tested—information that may not be available from or relevant to other protocols. HTTP Headers and Instant Messaging buddy names are two examples of protocol-specific information. Other key differentiators among the proxy transaction subtypes are the order in which information becomes available and when specific actions must be taken, as dictated by the individual protocols. Variation inherent in the individual protocols determines timing, or the sequence of evaluations that occurs as the transaction is processed. The following table summarizes the policy evaluation order for each of the protocol-specific proxy transactions. Table 2.1: When Policy is Evaluated Transaction Type

Policy is Evaluated....

Tunneled TCP transactions

before the connection is established to the origin server.

HTTP proxy transactions

Before the authentication challenge. After the authentication challenge, but before the requested object is fetched. Before making an upstream connection, if necessary. After the object is fetched

FTP over HTTP transactions:

Before the authentication challenge. After the authentication challenge, but before the required FTP commands are executed. Before making an upstream connection, if necessary. After the object is fetched.

Transparent FTP transactions

Policy is examined before the requested object is fetched.

Real Media streaming transactions

Before the authentication challenge. After the authentication challenge, but before getting object information. Before making an upstream connection, if necessary. After the object information is available, but before streaming begins. After streaming begins (this evaluation can be done multiple times, for example after playback is paused and restarted).

32

Chapter 2: Managing Content Policy Language

Table 2.1: When Policy is Evaluated (Continued) Transaction Type

Policy is Evaluated....

Windows Media MMS streaming transactions

Before the authentication challenge. Before making an upstream connection, if necessary. After the authentication challenge but before getting object information. After the object information is available, but before streaming begins. After streaming begins (this evaluation can be done multiple times, for example after playback is paused and restarted).

Windows Media HTTP streaming transactions

Before the authentication challenge. After the authentication challenge, but before the requested object is fetched. Before making an upstream connection, if necessary. (Up to this point it is similar to an HTTP transaction.) What happens at this stage depends on negotiations with the origin server: • After the origin server is contacted, if the User Agent header denotes the Windows Media player and the server supports Microsoft streaming HTTP extensions, it finishes like an MMS transaction: Object information is available at this stage but streaming has not begun. • If the User-Agent header is not a Windows Media player or the server does not support Microsoft streaming extensions, it finishes like an HTTP transaction: The requested object is fetched, and policy is evaluated

Some conditions cannot be evaluated during the first stage; for example, the user and group information will not be known until stage two. Likewise, the response headers and MIME type are unavailable for testing until stage three. For conditions, this is known as the earliest available time. Policy decisions can have similar timing considerations, but this is known as the latest commit time. In this example, the requirement to authenticate must be known at stage one, and a forwarding host or gateway must be determined by stage three.

Transactions When a client connects to one of the DNS-Proxy service ports configured on the SG appliance (for information refer to Volume 2: Proxies and Proxy Services), a transaction is created to cover both the request and its associated response. A transaction evaluates policy in layers only. Policy in other layers does not affect transactions. Policy for transactions is evaluated in two stages: •

After the DNS request is received

•

After the DNS response is available.

Transactions Cache transactions are initiated by the SG appliance in order to load or maintain content in the local object store during adaptive refresh or pipelining, or as a result of a content distribute CLI command. These may be HTTP, FTP, or streaming media transactions. Since no specific user is

33

Volume 10: Content Policy Language Guide

associated with these transactions, content related policy is evaluated for cache transactions, but user related policy is not evaluated. A cache transaction evaluates policy in and layers. The layers are only evaluated if an origin server must be contacted to complete the transaction. The following is a list of cache transactions: •

A content distribute transaction that is initiated by the content distribute CLI command. A content distribute transaction may use one of the following protocols: HTTP, HTTPS, Real Media, or Windows Media. This type of transaction may be preceded by a separate Administrator transaction, since the administrator must be authenticated and authorized to use the command.

•

Pipeline transactions (HTTP only).

•

Advertisement transactions (HTTP only).

•

If-modified-since transactions (HTTP only).

•

Refresh transactions (HTTP only).

•

ICP transactions.

Cache transactions have no client identity since they are generated internally by the SG appliance, and they do not support authentication or authorization. Therefore, they do not support conditions such as client.address= and group=, or the authenticate() property. An HTTP cache transaction is examined in two stages: •

Before the object is retrieved from the origin server.

•

After the object is retrieved.

Transaction Exception transactions include transactions that have been terminated by an exception.

Transactions A transaction is created when the SG appliance needs to evaluate forwarding policy before accessing a remote host and no proxy or cache transaction is associated with this activity. Examples include sending a heart-beat message, and downloading an installable list from an HTTP server. A transaction only evaluates policy in layers.

Transactions Two kinds of transactions exist:

34

•

: This includes cache and proxy transactions, except for transactions. Note that in VPM, transactions are referred to as SSL access transactions.

•

: A kind of proxy transaction whose purpose is to decide whether or not to intercept and decrypt an SSL connection, or leave it unencrypted and simple tunnel it.

Chapter 2: Managing Content Policy Language

Timing As stated in the discussion of proxy transactions, various portions of the transaction information become available at different points in the evaluation, and each protocol has specific requirements for when each decision must be made. The CPL triggers and properties are designed so that wherever possible, the policy writer is shielded from the variations among protocols by making the timing requirements imposed by the CPL accommodate all the protocols. Where this is not possible (because using the most restrictive timing causes significant loss of functionality for the other protocols), protocol specific triggers have been introduced. When evaluated against other protocols, these triggers return the not applicable value or N/A. This results in the rule being skipped (the expression evaluates to false, no matter what it is). It is possible to explicitly guard such rules so that they are only evaluated against appropriate transactions. The variation in trigger and property timings implies that within a policy rule a conflict is possible between a condition that can only be tested relatively late in the evaluation sequence and a property that must be set relatively early in the evaluation sequence. Such a rule results in a compile-time error. For example, here is a rule that would be incorrect for evaluating any transaction: If the user is in group xyz, require authentication. The rule is incorrect because group membership can only be determined after authentication and the rule tests group membership and specifies the authentication realm, a property that must be set before the authentication challenge can be issued. The following code illustrates this incorrect rule and the resulting message at compile time: group=xyz authenticate(MyRealm) Error: Late condition guards early action: 'authenticate(MyRealm)'

It is, however, correct for the authentication requirement to be conditional on the client address (client.address=) or proxy port (proxy.port=), as these can be determined at the time the client connection is established and therefore are available from the beginning of a proxy transaction. For the HTTP protocol, authenticate() can be conditional on the URL (url=), but for MMS streaming, only the Host portion of the URL can be tested (url.host=). Recall the outline of the evaluation model for Windows Media transactions presented in "Understanding Transactions and Timing" on page 31. As another example, consider the following: response.header.Content-type=”text/html” forward( somehost )

But policy cannot determine the value of the Content-type response header until the response is returned. The SG appliance cannot contact the server to get the response until policy determines what hosts or gateways to route through to get there. In other words, policy must set the forward() property. But policy cannot commit the action until the Content-type response header has been determined. Again, since the condition is not testable until later in the request (after the time at which the property must be set), an error is received.

Understanding Layers Eight types of layers are allowed in any policy file. The layer type determines the kinds of transaction its rules will act upon. The token used in the header identifies the layer type.

35

Volume 10: Content Policy Language Guide

•

—Used to define policy that controls access to the management console and the

command line. Policy is not evaluated for serial console access or SNMP traffic, however. • •

—Used to list policy rules that are evaluated during both cache and proxy transactions. —Exception layers are evaluated when a proxy transaction is terminated by an

exception. •

—Forward layers are only evaluated when the current transaction requires an

upstream connection. Forwarding policy is generally distinct and independent of other policies, and is often used as part of maintaining network topologies. •

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

•

—Used to define policy controlling transactions. Only transactions are evaluated against layers.

•

—Used to list policy triggers and properties that define the conditions under which SSL connections are intercepted and decrypted or tunneled. This layer is evaluated by the SSL-Intercept transaction. Only the conditions, actions, and properties essential to make the tunnel or intercept decision are allowed in the SSL-Intercept layer. For a list of CPL gestures allowed in the SSL-Intercept layer, refer to Volume 3: Proxies and Proxy Services.

•

—Used to store additional SSL triggers and properties that are unrelated to SSL interception. This layer, called the SSL Access layer in VPM, is evaluated by all cache and proxy transactions except the SSL-Intercept and transactions. For a list of CPL gestures allowed in the SSL layer, refer to Volume 3: Proxies and Proxy Services.

Important: Only a subset of the conditions, properties, and actions available in the policy language is permitted within each layer type; the remainder generate compile-time errors. Check the specific chapters in this manual to learn where the conditions, properties, and actions can be used.

Layers layers hold policy that is executed by Administrator transactions. This policy is used to

specify an authentication realm; to allow or deny administrative access based on the client’s IP address, credentials, and type of administrator access requested (read or write); and to perform any additional logging for administrative access. Important: When traffic is explicitly proxied, it arrives at the layer with the client IP address set to the SG appliance’s IP address; therefore, the client.address= condition is not useful for explicitly proxied traffic.

36

Chapter 2: Managing Content Policy Language

The syntax is: [admin_condition][admin_properties] ... admin_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional admin_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional admin_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

admin_rules is a list of rules representing the decision to be made by this policy layer.

Layers layers hold policy that is executed by both cache and proxy transactions. Since cache transactions have no concept of a client, all layer policy is clientless, so you cannot test client identity using client.address=, user=, group=, and the like.

Certain types of policy must be applied consistently to both proxy and cache transactions to preserve cache consistency. Such policy must not be conditional on client identity or time of day, and belongs in a layer. Examples include the following: •

Response virus scanning.

•

Cache control policy (other than bypass_cache).

•

Modifications to request headers, if the modification affects the content returned by the Web server, and the content is cached.

•

Rewrites of the request URL that modify the server URL but not the cache URL. (Place rewrites of the request URL that change the cache and server URL to the same value in a layer.)

Only the following properties are safe to make conditional on time or client identity in a layer: •

Pipelining

•

Tracing, logging

•

Freshness checks

•

Redirection

•

Content transforms

37

Volume 10: Content Policy Language Guide

The syntax is: [cache_condition][cache_properties] ... cache_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional cache_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional cache_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

cache_rules is a list of rules representing the decision to be made by this policy layer.

Layers layers are evaluated when a proxy transaction is terminated by an exception. This could be caused by a bad request (for example, the request URL names a non-existent server) or by setting the deny or exception() properties in policy. Policy in an exception layer can be used to control how access logging is performed for exceptions, such as authentication_failed. It can also be used to modify the HTTP response headers in the exception page that is sent to the client.

The syntax is: [exception_condition][exception_properties] ... exception_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional exception_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional exception_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

exception_rules is a list of rules representing the decision to be made by this policy layer.

Layers layers are evaluated when the current transaction requires an upstream connection (and only then: forward policy will not be evaluated for a cache hit). layers use the

38

Chapter 2: Managing Content Policy Language

server_url= tests rather than the url= tests so that they are guaranteed to honor any policy that

rewrites the URL. The syntax is: [forward_condition][forward_properties] ... forward_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional forward_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional forward_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

forward_rules is a list of rules representing the decision to be made by this policy layer.

Layers layers define policy for authenticating and authorizing users’ requests for service over one of

the configured proxy service ports (refer to Chapter 6:”Managing Port Services” in the Blue Coat Systems Configuration and Management Guide). Proxy layer policy involves both client identity and content. Only proxy transactions are evaluated against layers. Note:

Policy for transactions is distinct from policy for other proxy services. See the following Layers section.

The syntax is: [proxy_condition][proxy_properties] ... proxy_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional proxy_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional proxy_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

proxy_rules is a list of rules representing the decision to be made by this policy layer.

39

Volume 10: Content Policy Language Guide

Layers layers define policy controlling transactions. Only transactions are evaluated against layers.

The syntax is: [dns_proxy_condition][dns_proxy_properties] ... dns_proxy_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional dns_proxy_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional dns_proxy_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

dns_proxy_rules is a list of rules representing the decision to be made by this policy

layer.

Layers The layer lists the triggers and properties that define the interception conditions for SSL connections. This layer is evaluated by the SSL-Intercept transaction only. The syntax is [SSL-Intercept_condition][SSL-Intercept_properties] ... SSL-Intercept_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional SSL-Intercept_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional SSL-Intercept_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

SSL-Intercept_rules is a list of rules representing the decision to be made by this policy

layer.

40

Chapter 2: Managing Content Policy Language

Layers The layer lists the triggers and properties that define the interception conditions for SSL connections. This layer is evaluated by all transactions except the SSL-Intercept transaction. The syntax is [SSL_condition][SSL_properties] ... SSL_rules

where: •

The optional “comment”, separated from the layer type by space, is an identifier or quoted string that is displayed in policy traces to identify the purpose of the layer.

•

The optional SSL_condition is a list of triggers, all of which must evaluate to true before the layer content is evaluated. For more information on using conditions, see Chapter 3: "Condition Reference". See also the following Layer Guards section.

•

The optional SSL_properties is a list of properties set if any of the rules in the layer match. These act as defaults, and can be overridden by property settings in specific rules in the layer. For more information on using properties, see Chapter 4: "Property Reference". See also the following Layer Guards section.

•

SSL_rules is a list of rules representing the decision to be made by this policy layer.

Layer Guards Often, the same set of conditions or properties appears in every rule in a layer. For example, a specific user group for which a number of individual cases exist where some things are denied: group=general_staff url.domain=competitor.com/jobs deny group=general_staff url.host=bad_host deny group=general_staff condition=whatever deny ; etc. group=general_staff allow

You can factor out the common elements into guard expressions. Notice that the common elements are group=general_staff and deny. The following is the same policy, expressed as a layer employing a guard expression: group=general_staff deny url.domain=competitor.com/jobs url.host=bad_host condition=whatever ; etc. allow

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

41

Volume 10: Content Policy Language Guide

Timing The “late guards early” timing errors that can occur within a rule can arise across rules in a layer. When a trigger cannot yet be evaluated, policy also has to postpone evaluating all following rules in that layer (since if the trigger turns out to be true and the rule matches, then evaluation stops for that layer. If the trigger turns out to be false and the rule misses, then evaluation continues for the rest of the rules in that layer, looking for the first match). Thus a rule inherits the earliest evaluation point timing of the latest rule above it in the layer. For example, as noted earlier, the following rule would result in a timing conflict error: group=xyz authenticate(MyRealm) Error: Late condition guards early action: 'authenticate(MyRealm)'

The following layer would result in a similar error: group=xyz deny authenticate(MyRealm) Error: Late condition 'group=xyz' guards early action: 'authenticate(MyRealm)'

This also extends to guard expressions, as the guard condition must be evaluated before any rules in the layer. For example: group=xyz deny authenticate(MyRealm) Error: Late condition 'group=xyz' guards early action: 'authenticate(MyRealm)'

Understanding Sections The rules in layers can optionally be organized in one or more sections, which is a way of grouping rules together. A section consists of a section header followed by a list of rules. Four sections types are supported in a standard CPL file: •

[Rule]

•

[url]

•

[url.domain]

•

[server_url.domain]

Three of the section types, [url], [url.domain] and [server_url.domain], provide optimization for URL tests. The names for these sections correspond to the CPL URL triggers used as the first test for each rule in the section, that is url=, url.domain= and server_url.domain=. The [url.regex] section provides factoring and organization benefits, but does not provide any performance advantage over using a [Rule] section and explicit url.regex= tests. To give an example, the following policy layer is created: url.domain=abc.com/sports deny url.domain=nbc.com/athletics deny ; etc, suppose it's a substantial list url.regex="sports|athletics" access_server(no)

42

Chapter 2: Managing Content Policy Language

url.regex="\.mail\." deny ; etc url=www.bluecoat.com/internal group=!bluecoat_employees deny url=www.bluecoat.com/proteus group=!bluecoat_development deny ; etc

This can be recast into three sections: [url.domain] abc.com/sports deny nbc.com/athletics deny ; etc. [Rule] url.regex="sports|athletics" access_server(no) url.regex="\.mail\." deny [url] www.bluecoat.com/internal group=!bluecoat_employees deny www.bluecoat.com/proteus group=!bluecoat_development deny

Notice that the first thing on each line is not a labelled CPL trigger, but is the argument for the trigger assumed by the section type. Also, after the first thing on the line, the rest of the line is the familiar format. The performance advantage of using the [url], [url.domain], or [server_url.domain] sections is measurable when the number of URLs being tested reaches roughly 100. Certainly for lists of several hundred or thousands of URLs, the performance advantage is significant. When no explicit section is specified, all rules in a layer are assumed to be in a [Rule] section. That is, the first example is equivalent to: [Rule] url.domain=abc.com/sports deny url.domain=nbc.com/athletics deny ; etc, suppose it's a substantial list url.regex="sports|athletics" access_server(no) url.regex="\.mail\." deny ; etc url=www.bluecoat.com/internal group=!bluecoat_employees deny url=www.bluecoat.com/proteus group=!bluecoat_development deny ; etc

[Rule] The [Rule] section type is used to logically organize policy rules into a section, optionally applying a guard to the contained rules. The [Rule] section was so named because it can accept all rules in a policy. If no section is specified, all rules in a layer are assumed to be in a [Rule] section. •

Use [Rule] sections to clarify the structure of large layers. When a layer contains many rules, and many of the rules have one or more conditions in common, you may find it useful to define [Rule] sections.

•

Rules in [Rule] sections are evaluated sequentially, top to bottom. The time taken is proportional to the number of rules in the section.

43

Volume 10: Content Policy Language Guide

•

[Rule] sections can be used in any layer.

[url] The [url] section type is used to group a number of rules that test the URL. The [url] section

restricts the syntax of rules in the section. The first token on the rule line is expected to be a pattern appropriate to a url= trigger. The trigger name is not included. Rules in [url] sections are evaluated through hash table techniques, with the result that the time taken is not dependent on the number of rules in the section. •

[url] sections are not allowed in or layers.

[url.domain] The [url.domain] section is used to group a number of rules that test the URL domain. The [url.domain] section restricts the syntax of rules in the section. The first token on the rule line is expected to be a pattern appropriate to a url.domain= trigger. The trigger name is not included. (The [url.domain] section replaces the [domain-suffix] section used in previous versions of CPL.) •

Rules in [url.domain] sections are evaluated through hash table techniques, with the result that the time taken is not dependent on the number of rules in the section.

•

[url.domain] sections are not allowed in or layers.

[url.regex] The [url.regex] section is used to test the URL. The [url.regex] section restricts the syntax of rules in the section. The first token on the rule line is expected to be a pattern appropriate to a url.regex= trigger. The trigger name is not included. The [url.regex] section replaces the [Regex] section used in previous versions of CPL. •

Rules in [url.regex] sections are evaluated sequentially, top to bottom. The time taken is proportional to the number of rules in the section.

•

[url.regex] sections are not allowed in , or layers.

[server_url.domain] The [server_url.domain] section is used to test the domain of the URL used to fetch content from the origin server. The [server_url.domain] section restricts the syntax and rules in the section. The first token on the rule line is expected to be a pattern appropriate to a server_url.domain= trigger. The trigger name is not included. [server_url.domain] sections contain policy rules very similar to [url.domain] sections except that these policy rules test the server_url, which reflects any rewrites to the request URL.

44

•

Rules in [server_url.domain] sections are evaluated through hash table techniques, with the result that the time taken is not dependent on the number of rules in the section.

•

[server_url.domain] sections are allowed in , , , and layers.

Chapter 2: Managing Content Policy Language

Section Guards Just as you can with layers, you can improve policy clarity and maintainability by grouping rules into sections and converting the common conditions and properties into guard expressions that follow the section header. A guard expression allows you to take a condition that applies to all the rules and put the common condition next to the section header, as in [Rule] group=sales. Guards are essentially a way of factoring out common sets of triggers and properties, to avoid having to repeat them each time.

Defining Policies This section includes some guidelines for defining policies using CPL. •

Write an explicit layer header (, , , , or ) before writing any rules or sections. The only constructs that should occur before the first layer header are the condition-related definitions and comments.

•

Do not begin a policy file with a section, such as [Rule]. Ensure all sections occur within layers.

•

Do not use [Rule] sections unnecessarily.

•

Avoid empty or badly formed policy. While some CPL may look well-formed, make sure it actually does something.

While the following example appears like proper CPL, it actually has no effect. It has a layer header and a [Rule] section header, but no rule lines. As no rules exist, no policy exists either: group=Administrators [Rule] allow

Correct policy that allows access for the group “administrators” would be: group=Administrators allow

In the following example, the layer is deceptive because only the first rule can ever be executed: authenticate(MyRealm) ; this rule is unconditional ;all following rules are unreachable allow group=administrator allow group=clerk time=0900..1700 deny

At most, one rule is executed in any given layer. The first one that meets the conditions is acted upon; all other rules in the layer are ignored. To execute more than one rule, use more than one layer. To correctly define the above policy, two layers are required: authenticate(MyRealm) allow group=administrator allow group=clerk time=0900..1700 deny

•

Do not mix the CacheOS 4.x filter-file syntax with CPL syntax.

45

Volume 10: Content Policy Language Guide

Although the Content Policy Language is backward-compatible with the filter-file syntax, avoid using the older syntax with the new. For example, as the filter-file syntax uses a different order of evaluation, mixing the old and new syntax can cause problems. Blue Coat strongly recommends not mixing the two syntaxes.

Blacklists and Whitelists For administrative policy, the intention is to be cautious and conservative, emphasizing security over ease of use. The assumption is that everything not specifically mentioned is denied. This approach, referred to as the whitelist approach, is common in corporations concerned with security or legal issues above access. Organizations that want to extend this concept to general Internet access select a default proxy policy of deny as well. In the second approach, the idea is that by default everything is allowed. Some requests might be denied, but really that is the exception. This is known as blacklist policy because it requires specific mention of anything that should be denied (blacklisted). Blacklist policy is used by organizations where access is more important than security or legal responsibilities. This second approach is used for cache transactions, but can also be common default proxy policy for organizations such as Internet service providers. Blacklists and whitelists are tactical approaches and are not mutually exclusive. The best overall policy strategy is often to combine the two approaches. For example, starting from a default policy of deny, one can use a whitelist approach to explicitly filter-in requests that ought to be served in general (such as all requests originating from internal subnets, while leaving external requests subject to the default DENY). Further policy layers can then apply more specific restrictions in a blacklist mode to filter-out unwanted requests (such as those that fail to conform to content filtering policies). Whitelisting and blacklisting can also be used not simply to allow or deny service, but also to subject certain requests to further processing. For example, not every file type presents an equal risk of virus infection or rogue executable content. One might choose to submit only certain file types (presumably those known to harbor executable content) to a virus scanner (blacklist), or virus-scan all files except for a whitelist of types (such as image files) that may be considered safe.

General Rules and Exceptions to a General Rule When writing policy many organizations use general rules, and then define several exceptions to the rule. Sometimes, you might find exceptions to the exceptions. Exceptions to the general rule can be expressed either: •

Through rule order within a layer

•

Through layer order within the policy.

Using Rule Order to Define Exceptions When the policy rules within a layer are evaluated, remember that evaluation is from the top down, but the first rule that matches will end further evaluation of that layer. Therefore, the most specific conditions, or exceptions, should be defined first. Within a layer, use the sequence of most-specific to most-general policy.

46

Chapter 2: Managing Content Policy Language

The following example is an exception defined within a layer. A company wants access to payroll information limited to Human Resources staff only. The administrator uses membership in the HR_staff group to define the exception for HR staff, followed by the general policy: ; Blue Coat uses groups to identify HR staff, so authentication is required authenticate(MyRealm) define condition payroll_location url=hr.my_company.com/payroll/ end condition=payroll_location allow group=HR_staff ; exception deny ; general rule

This approach requires that the policy be in one layer, and because layer definitions cannot be split across policy files, the rule and the exceptions must appear in the same file. That may not work in cases where the rules and the exceptions are maintained by different groups. However, this is the preferred technique, as it maintains all policy related to the payroll files in one place. This approach can be used in either blacklist or whitelist models (see "Blacklists and Whitelists" on page 46) and can be written so that no security holes are opened in error. The example above is a whitelist model, with everything not explicitly mentioned left to the default rule of deny.

Using Layer Ordering to Define Exceptions Since later layers override earlier layers, general rules can be written in one layer, with exceptions written in following layers, put specific exceptions later in the file. The Human Resources example could be rewritten as: ; Blue Coat uses groups to identify HR staff, so authentication is required authenticate(MyRealm) define condition payroll_location url=hr.my_company.com/payroll/ end condition=payroll_location deny ; general rule condition=payroll_location allow group=HR_staff ; exception

Notice that in this approach, some repetition is required for the common condition between the layers. In this example, the condition=payroll_location must be repeated. It is very important to keep the exception from inadvertently allowing other restrictions to be undone by the use of allow. As the layer definitions are independent, they can be installed in separate files, possibly with different authors. Definitions, such as the payroll location condition, can be located in one file and referenced in another. When linking rules to definitions in other files, file order is not important, but the order of installation is. Definitions must be installed before policy that references them will compile. Keeping definitions used across files in only one of the files, rather than spreading them out, will eliminate the possibility of having changes rejected because of interlocking reference problems. Note that when using this approach, exceptions must follow the general rule, and you must be aware of the policy file

47

Volume 10: Content Policy Language Guide

evaluation order as currently configured. Changes to the policy file evaluation order must be managed with great care. Remember that properties maintain any setting unless overridden later in the file, so you could implement general policy in early layers by setting a wide number of properties, and then use a later layer to override selected properties.

Avoid Conflicting Actions Although policy rules within a policy file can set the action property repeatedly, turning individual actions on and off for the transaction being processed, the specific actions can conflict. •

If an action-definition block contains two conflicting actions, a compile-time error results. This conflict would happen if, for example, the action definition consisted of two response.icap_service( ) actions.

•

If two different action definitions are executed and they contain conflicting actions, it is a run-time error; a policy error is logged to the event log, and one action is arbitrarily chosen to execute.

The following describes the potential for conflict between various actions: •

Two header modification actions will conflict if they modify the same header. Header modification actions include the append( ), delete( ), delete_matching( ), rewrite(header,...), and set(header,...) actions.

•

Two instant message text modification actions will conflict. Instant message text modification actions include the append(im.message.text,...) and set(im.message.text,...) actions.

•

Two transform actions of the same type conflict.

•

Two rewrite( ) actions conflict.

•

Two response.icap_service( ) actions conflict.

Making Policy Definitive You can make policy definitive two ways. The first is to put that policy into the file; that is, last in the evaluation order. (Remember that the forward file is always the last policy file.) For example, suppose that service was limited to the corporate users identifiable by subnet. Placing a rule such as: client.address=!my_subnet deny

at the end of the Forward file ensures that no other policy overrides this restriction through accidental use of allow. Although not usually used for this purpose, the fact that the forward file is always last, and the order of the other three files is configurable, makes this the appropriate location for definitive policy in some organizations. An alternate method has been provided for definitive denial. While a deny or an exception() property can be overridden by a subsequent allow in later rules, CPL provides force_deny and force_exception(). CPL does not offer force_allow, so while the error returned to the user may be reset by subsequent force_deny or force_exception() gestures, the ultimate effect is that the request is denied. Thus these properties provide definitive denial regardless of where they appear in policy.

48

Chapter 2: Managing Content Policy Language

Best Practices •

Express separate decisions in separate layers. As policy grows and becomes more complex, maintenance becomes a significant issue. Maintenance will be easier if the logic for each aspect of policy is separate and distinct. Try to make policy decisions as independent as possible, and express each policy in one layer or two adjacent layers.

•

Be consistent with the model. Set the default proxy policy according to your policy model and then use blacklist or whitelist approaches as appropriate. The recommended approach is to begin with a default proxy policy of deny in configuration. Allow requests in early layers and deny requests in later layers. Ensure that all layers that allow requests precede any layers that deny requests. The following is a simple illustration of this model: define subnet corporate_subnet 10.10.12.0/24 end ; First, explicitly allow access to our users ALLOW client.address=corporate_subnet ; Next, impose any authentication requirements authenticate(corp_realm) ; all access must be authenticated ; And now begin to filter-out unwanted requests DENY url.domain=forbidden.com DENY category=(Gambling, Hacking, Chat) ; more layers…

•

Expose only what is necessary. Often, it may be useful to keep the rule logic and the condition definitions separate so that the rules can be maintained by one group, but the definitions by another. The rules may contain exception details or other logic that should not be modified; however, the conditions, such as affected groups or content, may change frequently. With careful separation of the rules and the conditions, the rules can be expressed in the local policy file, and users unfamiliar with CPL can update the condition definitions through the VPM. When using this technique, installation order is important. Condition definitions must be available before policy referencing those conditions will compile, so the conditions you want to expose for general use must be defined in the VPM before they are referenced in the Local policy file.

49

Volume 10: Content Policy Language Guide

50

Chapter 3:

Condition Reference

A condition is an expression that yields true or false when evaluated. Conditions can appear in: •

Policy rules.

•

Section and layer headers, as guards; for example, [Rule] group=(“bankabc\hr” || “cn=humanresources,ou=groups,o=westernnational”)

•

define condition, define domain condition, and define url condition definition blocks.

Condition Syntax A condition has the following form: condition=pattern-expression

A condition is the name of a condition variable. It can be simple, such as url, or it can contain sub-object specifiers and modifiers, as in url.path.case_sensitive or request.header.Cookie.A condition cannot contain white space. A pattern expression can be either: •

A simple pattern, which is matched against the condition value.

•

A Boolean combination of simple patterns, or a parenthesized, comma-separated list of simple patterns.

A pattern expression can be any of the following: •

String: A string argument must be quoted if it contains whitespace or other special characters. An example condition expression is category=”self help”.

•

Single argument: Conditions such as live= take only a single argument, in this case, yes or no.

•

Boolean expressions: Conditions such as server_url.scheme= can list one or more arguments together with Boolean operators; for example, server_url.scheme=!http.

•

Integer or range of integers: Numeric conditions can use Boolean expressions and double periods (..), meaning an inclusive numeric range. Numeric ranges cannot use whitespace. The minute= condition is used to show examples of ranges: • minute=10..40—From 10 minutes to 40 minutes after the hour.

•

•

minute=10..—From 10 minutes after the hour to the end of the hour.

•

minute=..40—From the beginning of the hour to 40 minutes after the hour.

•

minute=40..10—From 40 minutes after the hour, to 10 minutes after the next hour.

Regular expressions: Some header-related conditions and two URL-related conditions take regular expressions. For more information about writing regular expressions, see Appendix E: "Using Regular Expressions".

51

Volume 10: Content Policy Language Guide

The following is Backus-Naur Form (BNF) grammar: •

condition ::= condition "=" expression

•

condition ::= identifier | identifier "." word

•

expression ::= term | list

•

list ::= "(" ((pattern ",")* pattern)? ")"

•

disjunction ::= conjunction | disjunction "||" conjunction

•

conjunction ::= term | conjunction "&&" term

•

term ::= pattern | "(" disjunction ")" | "!" term

•

pattern ::= word | 'string' | "string"

•

word ::= sequence of characters not including whitespace, & | ( ) < > [ ] ; ! = " '

•

string ::= sequence of characters that may including whitespace, & | ( ) < > [ ] ; ! =. The characters " and ' may be enclosed within a string delimited by the alternate delimiter.

Pattern Types Different conditions support different pattern syntaxes. A pattern for a boolean condition has one of the following forms: boolean ::= yes | no | true | false | on | off

The pattern for a numeric condition can be either an integer or a range of integers. Numeric patterns cannot contain white space. condition=I

Test if condition == I. condition=I..J

Test if condition >= I and condition = I.

For example,

bitrate=56k..

tests if the bitrate is greater than or

condition=..J

Test if condition "www.somedomain.com".

•

Trailing dot is stripped from domain name. For example, "www.example.com." -> "www.example.com".

•

IP addresses in non-standard form are converted to a decimal dotted quad. For example, "0xA.012.2570" -> "10.10.10.10".

Syntax raw_url.host.regex=regular_expression

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy transactions.

Example •

Reject request as invalid if host is an IP address in non-standard form. exception(invalid_request) \ url.host.is_numeric=yes \ raw_url.host.regex=("(^|\.)0[^.]" || !"\..*\..*\.")

142

Chapter 3: Condition Reference

raw_url.path.regex= Test the value of the path component of the raw request URL. The raw_url.path.regex= condition tests the original character string used to specify the path in the HTTP request. It is different from the url.path.regex= condition because the following normalizations are not applied: •

If path and query are both missing, the path is set to "/". For example, "http://abc.com" -> "http://abc.com/".

•

Double slashes in the path are normalized to single slashes. For example, "http://abc.com/a//b.gif" -> "http://abc.com/a/b.gif".

•

The path components "." and ".." are removed. For example, "http://abc.com/a/./b.gif" -> "http://abc.com/a/b.gif" and "http://abc.com/a/../b.gif" -> "http://abc.com/b.gif".

•

Unnecessary % escape sequences are replaced by the characters they encode. For example, "http://abc.com/%64%65%66.gif" -> "http://abc.com/def.gif".

Syntax raw_url.path.regex=regular_expression

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy transactions.

Example •

Reject request as invalid if path encodes letters and digits using hex escape sequences. Rationale: this might be an attempt to evade content filtering policy. exception(invalid_request) \ raw_url.path.regex="\%(3[0-9]|[46][1-9a-fA-F]|[57][0-9aA])"

143

Volume 10: Content Policy Language Guide

raw_url.pathquery.regex= Test the value of the path and query component of the raw request URL. The raw_url.pathquery.regex= condition tests the original character string used to specify the path and query in the HTTP request. It is different from the path and query tested by the url.regex= condition because the following normalizations are not applied: •

If path and query are both missing, the path is set to "/". For example, "http://abc.com" -> "http://abc.com/".

•

Double slashes in the path are normalized to single slashes. For example, "http://abc.com/a//b.gif" -> "http://abc.com/a/b.gif".

•

The path components "." and ".." are removed. For example, "http://abc.com/a/./b.gif" -> "http://abc.com/a/b.gif" and "http://abc.com/a/../b.gif" -> "http://abc.com/b.gif".

•

Unnecessary % escape sequences are replaced by the characters they encode. For example, "http://abc.com/%64%65%66.gif" -> "http://abc.com/def.gif".

Syntax raw_url.pathquery.regex=regular_expression

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy transactions.

Example •

Reject request as invalid if pathquery encodes letters and digits using hex escape sequences. Rationale: this might be an attempt to evade content filtering policy. exception(invalid_request) \ raw_url.pathquery.regex="\%(3[0-9]|[46][1-9a-fA-F]|[57][0-9aA])"

144

Chapter 3: Condition Reference

raw_url.port.regex= Test the value of the port' component of the raw request URL. The raw_url.port= condition is the original character string used to specify the port in the HTTP request. It is different from the url.port= condition because it is a string, not an integer, and because of the following: •

Leading zeroes are not removed. Thus, raw_url.port.regex="^0" is true if there are leading zeroes.

•

If the port is specified as a naked colon, with no following port number, then the string is the empty string, and raw_url.port.regex="^$" will be true.

If no port is specified, then no regex will match, and raw_url.port.regex=!"" will be true. Syntax raw_url.port.regex=regular_expression

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy transactions.

Example •

Reject request as invalid if port specifier is a naked colon or has leading zeroes. exception(invalid_request) raw_url.port.regex=("^$" || "^0")

145

Volume 10: Content Policy Language Guide

raw_url.query.regex= raw_url.query.regex tests the original character string used to specify the query in the HTTP request. It is different from url.query.regex because the following normalization is not applied:

Unnecessary % escape sequences are replaced by the characters they encode. For example, "http://abc.com/search?q=%64%65%66" -> "http://abc.com/search?q=def". Syntax raw_url.query.regex=regular_expression

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy transactions.

Example •

Reject request as invalid if query encodes letters and digits using hex escape sequences. Rationale: this might be an attempt to evade content filtering policy. exception(invalid_request) \ raw_url.query.regex="\%(3[0-9]|[46][1-9a-fA-F]|[57][0-9aA])"

146

Chapter 3: Condition Reference

realm= Tests if the client is authenticated and if the client has logged into the specified realm. If both of these conditions are met, the response is true. In addition, the group= condition can be used to test whether the user belongs to the specified group. This condition is unavailable if the current transaction is not authenticated (for example, the authenticate property is set to no). If you reference more than one realm in your policy, consider disambiguating user, group and attribute tests by combining them with a realm=test. This reduces the number of extraneous queries to authentication services for group, user or attribute information that does not pertain to that realm. Note:

When used in the layer, authentication conditions can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Syntax realm=realm_name

where realm_name is the name of an NTLM, Local Password, RADIUS, LDAP, Certificate, or Sequence realm. Realm names are case-insensitive for all realm types. Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy and administrator transactions.

Example ; This example tests if the user has logged into realm corp and ; is authenticated in the specified group. realm=corp group=all_staff ; This example uses the realm property to distinguish the policy applied ; to two groups of users--corp’s employees, and their corporate partners and ; clients. These two groups will authenticate in different realms. client.address=10.10.10/24 authenticate(corp) ; The corporate realm authenticate(client) ; Company partners & clients realm=corp ; Rules for corp employees allow url.domain=corp.com ; Unrestricted internal access category=(violence, gambling) exception(content_filter_denied) realm=client ; Rules for business partners & clients allow group=partners url=corp.com/partners ; Restricted to partners allow group=(partners, clients) url=corp.com/clients ; Both groups allowed deny ; Additional layers would continue to be guarded with the realm, so that only ; the ‘client’ realm would be queried about the ‘partners’ and ‘clients’ groups.

147

Volume 10: Content Policy Language Guide

See Also

148

•

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, user=, user.domain=, user.x509.issuer=, user.x509.serialNumber=, user.x509.subject=

•

Properties: authenticate( ), authenticate.force( ), check_authorization( )

Chapter 3: Condition Reference

release.id= Tests the release ID of the SG appliance software. The release ID of the SG appliance software currently running is displayed on the main page of the Management Console and in the Maintenance > Upgrade > Systems tab of the Management Console. It also can be displayed through the CLI using the show version command. Syntax release.id=number

where number is a five-digit number that increases with each new release of the SG appliance. Layer and Transaction Notes •

May be used in any type of layer.

Example ; the condition below is only true if you are running a version of SG appliance ; whose release id is 18000 or later release.id=18000..

See Also •

Conditions: release.version=

149

Volume 10: Content Policy Language Guide

release.version= Tests the release version of the SG appliance software. The release version of the SG appliance software currently running is displayed on the main page of the Management Console and in the Management>Maintenance>Upgrade>Systems tab of the Management Console. It also can be displayed through the CLI using the show version command. Syntax release.version={[minimum_version]..[maximum_version]|version}

where each of the versions is of the format:. major_#.minor_#.dot_#.patch_#

Each number must be in the range 0 to 255. The major_# is required; less significant portions of the version may be omitted and will default to 0. Layer and Transaction Notes •

May be used in any layer.

Example ; the condition below is only true if you are running a version of SG appliance ; whose release version is 3.1. release.version=3.1.. ; the condition below is only true if you are running a version of SG appliance ; whose release version is less or equal to than 3.1.2 release.version=..3.1.2

150

Chapter 3: Condition Reference

request.header.header_name= Tests the specified request header (header_name) against a regular expression. Any recognized HTTP request header can be tested. For custom headers, use request.x_header.header_name= instead. For streaming requests, only the User-Agent header is available. Syntax request.header.header_name=regular_expression

where: •

header_name—A recognized HTTP header. For a complete list of recognized headers, see Appendix C: "Recognized HTTP Headers".

•

regular_expression—A regular expression. For more information, see Appendix E: "Using Regular Expressions".

Layer and Transaction Notes •

Use in , , and layers.

Example ;deny access when request is sent with Pragma-no-cache header deny url=http://www.bluecoat.com request.header.Pragma=”no-cache”

See Also •

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.header.header_name.address=, request.x_header.header_name=, response.header.header_name=

151

Volume 10: Content Policy Language Guide

request.header.header_name.address= Tests if the specified request header can be parsed as an IP address; otherwise, false. If parsing succeeds, then the IP address extracted from the header is tested against the specified IP address. The expression can include an IP address or subnet, or the label of a subnet definition block. This condition can only be used with the client-ip and X-Forwarded-For headers. Syntax request.header.header_name.address=ip_address|subnet|subnet_label

where: •

header_name—client-ip and X-Forwarded-For.

•

ip_address—IP address; for example, 10.1.198.46.

•

subnet—A subnet mask; for example, 10.1.198.0/24.

•

subnet_label—Label of a subnet definition block that binds a number of IP addresses or

subnets. Layer and Transaction Notes •

Use in and layers.

Example ; In this example, we assume that there is a downstream SG appliance that ; identifies client traffic by putting the client’s IP address in a request ; header. ; Here we’ll deny access to some clients, based on the header value. ; Netscape’s convention is to use the Client-IP header deny request.header.Client-IP.address=10.1.198.0/24 ; the subnet ; Blue Coat’s convention is to use the extended header: deny request.header.X-Forwarded-For.address=10.1.198.12

See Also •

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.header.header_name=, response.header.header_name=, response.x_header.header_name=

•

152

Definitions: define subnet

Chapter 3: Condition Reference

request.header.header_name.count= Test the number of header values in the request for the given header_name. Syntax request.header.header_name.count=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to HTTP proxy transactions.

Example •

Deny abnormal HTTP requests with 2 or more host headers. DENY("Too many Host headers") request.header.Host.count = 2..

153

Volume 10: Content Policy Language Guide

request.header.header_name.length= Test the total length of the header values for the given header_name. Syntax request.header.header_name.length=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to HTTP proxy transactions.

Example •

Deny HTTP requests with more than 2K of cookie data. DENY("Too much Cookie data") request.header.Cookie.length = 2048..

154

Chapter 3: Condition Reference

request.header.Referer.url= Test if the URL specified by the Referer header matches the specified criteria. The basic request.header.Referer.url= test attempts to match the complete Referer URL against a specified pattern. The pattern may include the scheme, host, port, path and query components of the URL. If any of these is not included in the pattern, then the corresponding component of the URL is not tested and can have any value. Specific portions of the Referer URL can be tested by applying URL component modifiers to the condition. In addition to component modifiers, optional test type modifiers can be used to change the way the pattern is matched. This condition is unavailable if the Referer header is missing, or if its value cannot be parsed as a URL. If the Referer header contains a relative URL, the requested URL is used as a base to form an absolute URL prior to testing. Syntax request.header.Referer.url[.case_sensitive][.no_lookup]=prefix_pattern request.header.Referer.url.domain[.case_sensitive][.no_lookup]= domain_suffix_pattern request.header.Referer.url.exact=string request.header.Referer.url.prefix=string request.header.Referer.url.substring=string request.header.Referer.url.suffix=string request.header.Referer.url.regex=regular_expression request.header.Referer.url.address=ip_address|subnet|subnet_label request.header.Referer.url.extension[.case_sensitive]=[.]filename_extension request.header.Referer.url.host[.exact]=host request.header.Referer.url.host.[prefix|substring|suffix]=string request.header.Referer.url.host.is_numeric=yes|no request.header.Referer.url.host.no_name=yes|no request.header.Referer.url.path[.case_sensitive]=/string request.header.Referer.url.path[.substring|.suffix][.case_sensitive]=string request.header.Referer.url.path.regex[.case_sensitive]=regular_expression request.header.Referer.url.port={[low_port_number]..[high_port_number] |exact_port_number} request.header.Referer.url.query.regex[.case_sensitive]=regular_expression request.header.Referer.url.scheme=url_scheme request.header.Referer.url.host.has_name=yes|no|restricted|refused|nxdomain \ |error request.header.Referer.url.is_absolute=yes|no

where all options are identical to url=, except for the URL being tested. For more information, see "url=" on page 186. Discussion The request.header.Referer.url= condition is identical to url=, except for the lack of a define url condition and [url] or [url.domain] sections.

155

Volume 10: Content Policy Language Guide

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example ; Test if the Referer URL includes this pattern, and block access. ; Relative URLs, such as docs subdirectories and pages, will match. deny request.header.Referer.url=http://www.example.com/docs ; Test if the Referer URL host’s IP address is a match. request.header.Referer.url.address=10.1.198.0 ; Test whether the Referer URL includes company.com as domain. request.header.Referer.url.domain=company.com ; Test whether the Referer URL includes .com. request.header.Referer.url.domain=.com ; Test if the Referer URL includes this domain-suffix pattern, ; and block service. Relative URLs, such as docs ; subdirectories and pages, will match. deny request.header.Referer.url.domain=company.com/docs ; examples of the use of request.header.Referer.url.extension= request.header.Referer.url.extension=.txt request.header.Referer.url.extension=(.htm, .html) request.header.Referer.url.extension=(img, jpg, jpeg) ; ; ; ;

This example matches the first Referer header value and doesn’t match the second from the following two requests: 1) Referer: http://1.2.3.4/test 2) Referer: http://www.example.com

request.header.Referer.url.host.is_numeric=yes ; In the example below we assume that 1.2.3.4 is the IP of the host mycompany ; The condition will match the following two requests if the reverse DNS was ; successful: ; 1) Referer: http://1.2.3.4/ ; 2) Referer: http://mycompany.com/ ; If the reverse DNS fails then the first request is not matched request.header.Referer.url.host.regex=mycompany ; request.header.Referer.url.path tests ; The following request.header.Referer.url.path strings would all match the example Referer URL: ; Referer: http://www.example.com/cgi-bin/query.pl?q=test#fragment request.header.Referer.url.path=”/cgi-bin/query.pl?q=test” request.header.Referer.url.path=”/cgi-bin/query.pl” request.header.Referer.url.path=”/cgi-bin/” request.header.Referer.url.path=”/cgi” ; partial components match too

156

Chapter 3: Condition Reference

request.header.Referer.url.path=”/” ; Always matches regardless of URL. ; Testing the Referer URL port request.header.Referer.url.port=80

See Also •

Conditions: url=, server_url=

•

Definitions: define subnet

157

Volume 10: Content Policy Language Guide

request.header.Referer.url.category= Test the content filter categories of the Referer URL. Syntax request.header.Referer.url.category=none|unlicensed|unavailable|pending| category_name1, category_name2, ...

Layer and Transaction Notes •

Use in and layers.

•

Applies to proxy transactions with a request URL.

Example request.header.Referer.url.category=Sports

See Also •

158

Conditions: category=, url.category=, server.certificate.hostname.category=

Chapter 3: Condition Reference

request.raw_headers.count= Test the total number of HTTP request headers. This condition tests the total number of raw HTTP request headers, as defined by the request.raw_headers.regex condition. Syntax request.raw_headers.count=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example •

Reject the request if it contains more than 40 request headers. exception(invalid_request) request.raw_headers.count=40..

159

Volume 10: Content Policy Language Guide

request.raw_headers.length= Test the total length of all HTTP request headers. This condition tests the total number of bytes of HTTP request header data, including the header names, values, delimiters, and newlines. The tally does not include the HTTP request line (which contains the request method) and it does not include the terminating blank line. Syntax request.raw_headers.length=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in and layers

•

Applies to HTTP proxy transactions

Example •

Reject the request if it contains more than 4K of request header data. exception(invalid_request) request.raw_headers.length=4096..

160

Chapter 3: Condition Reference

request.raw_headers.regex= Test the value of all HTTP request headers with a regular expression. This condition allows you to test the complete, unaltered HTTP request header text, which includes the header names, delimiters and header values. It iterates over all of the raw HTTP request headers. If the specified regular expression matches one of these strings, then the condition is true. Each "raw header" is a string consisting of a header line concatenated with zero or more continuation lines. The initial header line consists of a header name, followed by colon, followed by the header value, if any, followed by newline. The header value may have leading and trailing whitespace. Each continuation line begins with a space or tab, followed by additional text which is part of the header value, followed by a newline. Therefore, each "raw header" string contains a minimum of one newline, plus an additional newline for each continuation line. Here is how certain regex patterns work in the context of request.raw_headers.regex: •

"." matches any character, including newline.

•

"^" only matches at the beginning of the header name.

•

"$" only matches at the end of the string. The last character of the string is newline, so "$" will only match after the final newline. You probably want to use "\s*$" instead.

•

"\s" matches any white space character, including newline.

•

"\n" matches newline.

Syntax request.raw_headers.regex=regular_expression

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example •

Reject the request if it contains a header continuation line. Although this syntax is part of the HTTP standard, it isn't normally used, and might not be interpreted correctly by some upstream devices. exception(invalid_request) request.raw_headers.regex="\n[ \t]"

161

Volume 10: Content Policy Language Guide

request.x_header.header_name= Tests the specified request header (header_name) against a regular expression. Any HTTP request header can be tested, including custom headers. To test recognized headers, use request.header.header_name= instead, so that typing errors can be caught at compile time. For streaming requests, only the User-Agent header is available. Syntax request.x_header.header_name=regular_expression

where: •

header_name—Any HTTP header, including custom headers.

•

regular_expression—A regular expression. For more information, see Appendix E: "Using Regular Expressions".

Layer and Transaction Notes •

Use in and layers.

Example ; deny access to the URL below if the request contains the custom ; header “Test” and the header has a value of “test1” deny url=http://www.bluecoat.com request.x_header.Test=”test1”

See Also •

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.header.header_name=, request.header.header_name.address=, response.x_header.header_name=

162

Chapter 3: Condition Reference

request.x_header.header_name.address= Tests if the specified request header can be parsed as an IP address; otherwise, false. If parsing succeeds, then the IP address extracted from the header is tested against the specified IP address. The expression can include an IP address or subnet, or the label of a subnet definition block. This condition is intended for use with custom headers other than X-Forwarded-For and Client-IP headers; for these, use request.header.header_name.address= so that typing any errors can be caught at compile time. Syntax request.x_header.header_name.address= ip_address|subnet|subnet_label

where: •

header_name—Any HTTP header, including custom headers.

•

ip_address—IP address; for example, 10.1.198.0.

•

subnet—A subnet mask; for example, 10.1.198.0/24.

•

subnet_label—Label of a subnet definition block that binds a number of IP addresses or

subnets. Layer and Transaction Notes •

Use in and layers.

Example ; deny access if the request’s custom header “Local” has the value 10.1.198.0 deny request.x_header.Local.address=10.1.198.0

See Also •

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.header.header_name=, request.header.header_name.address=, response.x_header.header_name=

•

Definitions: define subnet

163

Volume 10: Content Policy Language Guide

request.x_header.header_name.count= Test the number of header values in the request for the given header_name. Syntax request.x_header.header_name.count=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example •

Deny abnormal HTTP requests with 2 or more host headers. DENY("Too many Host headers") request.header.Host.count =

164

Chapter 3: Condition Reference

request.x_header.header_name.length= Test the total length of the header values for the given header_name. Syntax request.x_header.header_name.length=numeric range from 0 to 8192

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example •

Deny HTTP requests with more than 2K of cookie data. DENY("Too much Cookie data") request.header.Cookie.length = 2048..

165

Volume 10: Content Policy Language Guide

response.header.header_name= Tests the specified response header (header_name) against a regular expression. Any recognized HTTP response header can be tested. For custom headers, use response.x_header.header_name= instead. Syntax response.header.header_name=regular_expression

where: •

header_name—A recognized HTTP header. For a list of recognized headers, see Appendix C: "Recognized HTTP Headers". For custom headers not listed, use condition response.x_header.header_name instead.

•

regular_expression—A regular expression. For more information, see Appendix E: "Using Regular Expressions".

Layer and Transaction Notes •

Use in , , and layers.

Example ; Test if the response’s “Content-Type” header has the value “image/jpeg” response.header.Content-Type=”image/jpeg”

See Also

166

•

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.header.header_name=, response.x_header.header_name=

Chapter 3: Condition Reference

response.raw_headers.count= Test the total number of HTTP response headers. This trigger tests the total number of raw HTTP response headers, as defined by the response.raw_headers.regex trigger. Syntax response.raw_headers.count=N|..N|N..|N1..N2

where N is an unsigned integer. Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example Reject the response if it contains 40 or more response headers. DENY("Too many response headers") response.raw_headers.count=40..

167

Volume 10: Content Policy Language Guide

response.raw_headers.length= Test the total length of all HTTP response headers. This trigger tests the total number of bytes of HTTP response header data, including the header names, values, delimiters and newlines. The tally does not include the HTTP response line, which is the first line of the response, and it does not include the terminating blank line. Syntax response.raw_headers.length=N|..N|N..|N1..N2

where: N is an unsigned integer. Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example Reject the response if it contains more than 4K of response header data. DENY("Too much response header data") response.raw_headers.length=4096..

168

Chapter 3: Condition Reference

response.raw_headers.regex= Test the value of all HTTP response headers with a regular expression. This trigger allows you to test the complete, unaltered HTTP response header text, which includes the header names, delimiters and header values. It iterates over all of the raw HTTP response headers. If the specified regular expression matches one of these strings, then the condition is true. Each "raw header" is a string consisting of a header line concatenated with zero or more continuation lines. The initial header line consists of a header name, followed by colon, followed by the header value, if any, followed by newline. The header value may have leading and trailing whitespace. Each continuation line begins with a space or tab, followed by additional text which is part of the header value, followed by a newline. Therefore, each "raw header" string contains a minimum of one newline, plus an additional newline for each continuation line. Here is how certain regex patterns work in the context of response.raw_headers.regex: * "." matches any character, including newline. * "^" only matches at the beginning of the header name. * "$" only matches at the end of the string. The last character of the string is newline, so "$" will only match after the final newline. You probably want to use "\s*$" instead. * "\s" matches any white space character, including newline. * "\n" matches newline. Syntax response.raw_headers.regex=regular_expression

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example Reject the response if it contains a header continuation line. Although this syntax is part of the HTTP standard, it isn't normally used, and may not be interpreted correctly by some downstream devices. exception(invalid_response) response.raw_headers.regex="\n[ \t]"

169

Volume 10: Content Policy Language Guide

response.x_header.header_name= Tests the specified response header (header_name) against a regular expression. For HTTP requests, any response header can be tested, including custom headers. For recognized HTTP headers, use response.header.header_name= instead so that typing errors can be caught at compile time. Syntax response.x_header.header_name=regular_expression

where: •

header_name—Any HTTP header, including custom headers.

•

regular_expression—A regular expression. For more information, see Appendix E: "Using Regular Expressions"

Layer and Transaction Notes •

Use in , , and layers.

Example ; Tests if the custom header “Security” has the value of “confidential” response.x_header.Security=”confidential”

See Also

170

•

Actions: append( ), delete( ), delete_matching( ), rewrite( ), set( )

•

Conditions: request.x_header.header_name=, response.header.header_name=

Chapter 3: Condition Reference

server.certificate.hostname.category= Test the content filter categories of the hostname extracted from the X.509 certificate returned by the server while establishing an SSL connection. This condition is NULL for transactions that do not involve an SSL connection to the server. Syntax server.certificate.hostname.category=none|unlicensed|unavailable|pending| category_name1, category_name2, ...

Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions.

Example This example uses both URL content filtering category definitions and categories provided by a content filtering vendor to to restrict SSL access to certain sites define category Internal example1.com www.example1.org end client.is_ssl Allow server.certificate.hostname.category=Internal ; local definition Allow server.certificate.hostname.category=(Sports, Games) ; or vendor supplied Allow server.certificate.hostname.category=unavailable \ action.log_content_filter_down(yes) ; vendor down - allow but log Deny define action log_content_filter_down log_message( "content filter vendor unavailable to test $(server.certificate.hostname)" ) end

See Also •

Conditions: server.certificate.hostname=, server.certificate.common_name=, server.certificate.subject=, category=, url.category=, request.header.Referer.url.category=

•

Properties: server.certificate.validate( ), server.certificate.validate.ignore( ), server.certificate.validate.check_revocation( )

171

Volume 10: Content Policy Language Guide

server.connection.dscp= Test the server-side inbound DSCP value. Syntax client.server.dscp = dscp_value

where dscp_value is 0..63 | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | best-effort | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | ef Layer and Transaction Notes •

Valid in , , layers.

•

Applies to all transactions.

Example The first QoS policy rule tests the client inbound QoS/DSCP value against 50, and deny if it matches; the second QoS policy rule tests the client inbound QoS/DSCP value against 50, and deny if it matches. deny server.connection.dscp = 50 deny server.connection.dscp = best-effort

172

Chapter 3: Condition Reference

server_url= Tests if a portion of the URL used in server connections matches the specified criteria. The basic server_url= test attempts to match the complete possibly-rewritten request URL against a specified pattern. The pattern may include the scheme, host, port, path and query components of the URL. If any of these is not included in the pattern, then the corresponding component of the URL is not tested and can have any value. Specific portions of the URL can be tested by applying URL component modifiers to the condition. In addition to component modifiers, optional test type modifiers can be used to change the way the pattern is matched. Note:

This set of tests match against the requested URL, taking into account the effect of any rewrite( ) actions. Because any rewrites of the URL intended for servers or other upstream devices must be respected by layer policy, the url= conditions are not allowed in layers. Instead, the equivalent set of server_url= tests are provided for use in the layer. Those tests always take into account the effect of any rewrite( ) actions on

the URL. Syntax server_url[.case_sensitive][.no_lookup]=prefix_pattern server_url.domain[.case_sensitive][.no_lookup]=domain_suffix_pattern server_url.exact=string server_url.prefix=string server_url.substring=string server_url.suffix=string server_url.regex=regular_expressionregular_expression server_url.address=ip_address|subnet|subnet_label server_url.extension[.case_sensitive]=[.]filename_extension server_url.host[.exact] [.no_lookup]=host server_url.host.[prefix|substring|suffix]=string server_url.host.regex=regular_expression server_url.is_absolute=yes|no server_url.host.is_numeric=yes|no server_url.host.has_name=yes|no|restricted|refused|nxdomain|error server_url.host.no_name=yes|no server_url.path[.case_sensitive]=/string server_url.path[.substring|.suffix][.case_sensitive]=string server_url.path.regex[.case_sensitive]=regular_expression server_url.port={[low_port_number]..[high_port_number]|exact_port_number} server_url.query.regex[.case_sensitive]=regular_expression server_url.scheme=url_scheme

where all options are identical to url=, except for the URL being tested. For more information, see "url=" on page 186.

173

Volume 10: Content Policy Language Guide

Discussion The server_url= condition is identical to url=, except for the lack of a define server_url condition and [server_url] section. Most optimization in forwarding is done with server_url.domain conditions and sections. Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to all non-administrator transactions.

Example ; Test if the server URL includes this pattern, and block access. ; Relative URLs, such as docs subdirectories and pages, will match. server_url=http://www.example.com/docs access_server(no) ; Test if the URL host’s IP address is a match. server_url.address=10.1.198.0 ; Test whether the URL includes company.com as domain. server_url.domain=company.com ; Test whether the URL includes .com. server_url.domain=.com ; Test if the URL includes this domain-suffix pattern, ; and block service. Relative URLs, such as docs ; subdirectories and pages, will match. server_url.domain=company.com/docs access_server(no) ; Example of the use of server_url.extension= server_url.extension=.txt server_url.extension=(.htm, .html) server_url.extension=(img, jpg, jpeg) ; This example matches the first request and doesn’t match the second from ; the following two requests: ; http://1.2.3.4/test ; http://www.example.com server_url.host.is_numeric=yes ; In the example below we assume that 1.2.3.4 is the IP of the host mycompany ; The condition will match the following two requests if the reverse DNS was ; successful: ;request http://1.2.3.4/ ;request http://mycompany.com/ ; If the reverse DNS fails then the first request is not matched server_url.host.regex=mycompany ; server_url.path tests

174

Chapter 3: Condition Reference

; The following server_url.path strings would all match the example URL: ; http://www.example.com/cgi-bin/query.pl?q=test#fragment server_url.path=”/cgi-bin/query.pl?q=test” server_url.path=”/cgi-bin/query.pl” server_url.path=”/cgi-bin/” server_url.path=”/cgi” ; partial components match too server_url.path=”/” ; Always matches regardless of URL. ; testing the url port server_url.port=80

See Also •

Conditions: content_management=, url=

•

Definitions: define subnet, define server_url.domain condition

175

Volume 10: Content Policy Language Guide

socks= This condition is true whenever the session for the current transaction involves SOCKS to the client. The SOCKS=yes condition is intended as a way to test whether a request arrived via the SOCKS proxy. It will be true for both SOCKS requests that the SG appliance tunnels and for SOCKS requests the SG appliance accelerates by handing them off to HTTP or IM. In particular, socks=yes remains true even in the resulting HTTP or IM transactions. Other conditions, such as proxy.address or proxy.port do not maintain a consistent value across the SOCKS transaction and the later HTTP or IM transaction, so they cannot be reliably used to do this kind of cross-protocol testing. Syntax socks=yes|no

Layer and Transaction Notes •

Use in , , , layers.

•

Applies to all proxy transactions.

See Also

176

•

Conditions: socks.accelerate=

•

Properties: socks_gateway( ), socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( ).

Chapter 3: Condition Reference

socks.accelerated= Tests whether the SOCKS proxy will hand off this transaction to other protocol agents for acceleration. Syntax socks.accelerated={yes|http|aol-im|msn-im|yahoo-im|no}

where: •

yes is true only for SOCKS transactions that will hand off to another protocol-specific

proxy agent. •

no implies the transaction is a SOCKS tunnel.

•

http is true if the transaction will be accelerated by the http proxy.

•

aol-im is true if the transaction will be accelerated by the aol-im proxy.

•

msn-im is true if the transaction will be accelerated by the msn-im proxy.

•

yahoo-im is true if the transaction will be accelerated by the yahoo-im proxy.

Layer and Transaction Notes •

Use in and layers.

•

Applies to SOCKS transactions.

See Also •

Conditions: socks.method=, socks.version=

•

Properties: socks_gateway( ), socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( ).

177

Volume 10: Content Policy Language Guide

socks.method= Tests the SOCKS protocol method name associated with the transaction. Syntax socks.method=CONNECT|BIND|UDP_ASSOCIATE

Layer and Transaction Notes •

Use in and layers.

•

Applies to SOCKS transactions.

See Also •

Conditions: ftp.method=, http.method=, http.x_method=, im.method=, server_url=, socks.version=

•

Properties: socks_gateway( ), socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( ).

178

Chapter 3: Condition Reference

socks.version= Tests whether the version of the SOCKS protocol used to communicate to the client is SOCKS 4/4a or SOCKS 5. SOCKS 5 has more security and is more highly recommended. SOCKS 5 supports authentication and can be used to authenticate transactions that may be accelerated by other protocol services. SOCKS 4/4a does not support authentication. If socks.authenticate() or socks.authenticate.force() is set during evaluation of a SOCKS 4/4a transaction, that transaction will be denied. Syntax socks.version=4..5

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to SOCKS transactions.

•

Does not apply to administrator transactions.

Example This example authenticates SOCKS v5 clients, and allows only a known set of client IP addresses to use SOCKS v4/4a. socks.version=5 socks.authenticate(my_realm ) deny socks.version=4 client.address=!old_socks_allowed_subnet

See Also •

Conditions: socks.method=, socks.version=

•

Properties: socks_gateway( ), socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( )

179

Volume 10: Content Policy Language Guide

ssl.proxy_mode= Test if the SG appliance is intercepting and decrypting an SSL connection. Syntax ssl.proxy_mode = yes|no|https-reverse-proxy|https-forward-proxy

where: yes

means the same as (https-reverse-proxy||https-forward-proxy)

Layer and Transaction Notes •

Use in and layers.

•

Applies to proxy transactions.

Example Test if an HTTPS reverse proxy request is being terminated. ssl.proxy_mode = https-reverse-proxy

180

Chapter 3: Condition Reference

streaming.client= Tests the client agent associated with the current transaction. Syntax streaming.client=yes|no|windows_media|real_media|quicktime

where: •

yes is true if the user agent is recognized as a windows media player, real media player or

quicktime player. •

no is true if the user agent is not recognized as a windows media player, real media player

or quicktime player. •

other values are true if the user agent is recognized as a media player of the specified type.

Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to HTTP and streaming transactions. Does not apply to administrator transactions.

See Also •

Conditions: bitrate=, live=, streaming.content=

•

Properties: access_server( ), max_bitrate( ), streaming.transport( )

181

Volume 10: Content Policy Language Guide

streaming.content= Tests the content of the current transaction to determine whether it is streaming media, and to determine the streaming media type. Syntax streaming.content=yes|no|windows_media|real_media|quicktime

where: •

yes is true if the content is recognized as Windows media, Real media, or QuickTime

content. •

no is true if the content is not recognized as Windows media, Real media, or QuickTime

content. •

other values are true if the streaming content is recognized as the specified type.

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to all transactions.

See Also

182

•

Conditions: bitrate=, live=, streaming.client=

•

Properties: access_server(), max_bitrate( ), streaming.transport( )

Chapter 3: Condition Reference

time= Tests if the time of day is in the specified range or an exact match. The current time is determined by the SG appliance’s configured clock and time zone by default, although the UTC time zone can be specified by using the form time.utc=. The numeric pattern used to test the time condition can contain no whitespace. Syntax time[.utc]={[start_time]..[end_time]|exact_time}

where:

Note:

•

start_time—Four digits (nnnn) in 24-hour time format representing the start of a time range; for example, 0900 specifies 9:00 a.m. If left blank, midnight (0000) is assumed.

•

end_time—Four digits (nnnn) in 24-hour time format representing the end of a time range; for example, 1700 specifies 5:00 p.m. If left blank, 2359 (11:59 p.m.) is assumed.

•

exact_time—Four digits (nnnn) in 24-hour time format representing an exact time.

To test against an inverted range, such as a range that crosses from one day into the next, the following shorthand expression is available. While time=(..0600|1900..) specifies midnight to 6 a.m. and 7 p.m. to midnight, the policy language also recognizes time=1900..0600 as equivalent.

Layer and Transaction Notes •

Use in all layers.

•

Using time-related conditions to control caching behavior in a layer may cause thrashing of the cached objects.

•

Applies to all transactions.

Example ; Tests for 3 a.m. to 1 p.m. UTC. time.utc=0300..1300 ; Allow access to a particular site only during 9 a.m. ; to noon UTC (presented in two forms). ; Restrict form: deny url.host=special_event.com time=!0900..1200 ; Grant form: allow url.host=special_event.com time=0900..1200 ; This example restricts the times during which certain ; stations can log in with administrative privileges.

183

Volume 10: Content Policy Language Guide

define subnet restricted_stations 10.10.10.4/30 10.10.11.1 end client.address=restricted_stations allow time=0800..1800 weekday=1..5 admin.access=(READ||WRITE); deny

See Also •

184

Conditions: date[.utc]=, day=, hour=, minute=, month=, weekday=, year=

Chapter 3: Condition Reference

tunneled= Tests if the current transaction represents a tunneled request. A tunneled request is one of: •

TCP tunneled request

•

HTTP CONNECT request

•

Unaccelerated SOCKS request

Note:

HTTPS connections to the management console are not tunneled for the purposes of this test.

Syntax tunneled=yes|no

Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions.

Example This example denies tunneled transactions except when they originate from the corporate subnet. define subnet corporate_subnet 10.1.2.0/24 10.1.3.0/24 end deny tunneled=yes client.address=!corporate_subnet

See Also Conditions: http.method=, socks.accelerated=, url.scheme= Properties: sock.accelerate()

185

Volume 10: Content Policy Language Guide

url= Tests if a portion of the requested URL matches the specified criteria. The basic url= test attempts to match the complete request URL against a specified pattern. The pattern may include the scheme, host, port, path and query components of the URL. If any of these is not included in the pattern, then the corresponding component of the request URL is not tested and can have any value. Specific portions of the URL can be tested by applying URL component modifiers to the condition. In addition to component modifiers, optional test type modifiers can be used to change the way the pattern is matched. Note:

This set of tests match against the originally requested URL, disregarding the effect of any rewrite( ) actions. Because any rewrites of the URL intended for servers or other upstream devices must be respected by layer policy, the url= conditions are not allowed in layers. Instead, an equivalent set of server_url= tests are provided for use in the layer. Those tests always take into account the effect of any rewrite( ) actions on

the URL. Replaces: various url_xxx forms. Syntax url[.case_sensitive][.no_lookup]=prefix_pattern url.domain[.case_sensitive][.no_lookup]=domain_suffix_pattern url.exact[.case_sensitive]=string url.prefix[.case_sensitive]=string url.substring[.case_sensitive]=string url.suffix[.case_sensitive]=string url.regex[.case_sensitive]=regular_expression url.address=ip_address|subnet|subnet_label url.extension[.case_sensitive]=[.]filename_extension url.host[.exact][.no_lookup]=host url.host.[prefix|substring|suffix]=string url.host.regex=regular_expression url.is_absolute=yes|no url.host.is_numeric=yes|no url.host.no_name=yes|no url.host.has_name=yes|no|restricted|refused|nxdomain|error url.path[.case_sensitive]=/string url.path[.substring|.suffix][.case_sensitive]=string url.path.regex[case_sensitive]=regular_expression url.port={[low_port_number]..[high_port_number]|exact_port_number} url.query.regex[.case_sensitive]=regular_expression url.scheme=url_scheme

where the URL test patterns are: •

prefix_pattern—A URL pattern that includes at least a portion of the following: scheme://host:port/path

186

Chapter 3: Condition Reference

Accepted prefix patterns include the following: scheme://host scheme://host:port scheme://host:port/path_query scheme://host/path_query //host //host:port //host:port/path_query //host/path_query host host:port host:port/path_query host/path_query /path_query

•

domain_suffix_pattern—A URL pattern that includes a domain suffix, as a minimum, using the following syntax: scheme://domain_suffix:port/path

Accepted domain suffix patterns include the following: scheme://domain_suffix scheme://domain_suffix:port scheme://domain_suffix:port/path_query scheme://domain_suffix/path_query //domain_suffix //domain_suffix:port //domain_suffix:port/path_query //domain_suffix/path_query domain_suffix domain_suffix:port domain_suffix:port/path_query domain_suffix/path_query

•

url.scheme—One of http, https, ftp, mms, rtsp, icp, tcp, aol-im, msn-im, or yahoo-im.

The request URL has the scheme https only in the case of SSL termination. A request URL with the scheme tcp only has a host and a port, and occurs in two cases: when a connection is made to a TCP tunnel service port, and when the CONNECT method is used in an explicitly proxied HTTP request. For example, when the Web browser has an explicit HTTP proxy and the user requests an HTTPS URL, the browser creates a TCP tunnel using the CONNECT method. •

host—A domain name or IP address. Host names must be complete; for example, url=http://www fails to match a URL such as http://www.example.com. This use of a complete host instead of a domain_suffix (such as example.com) indicates the difference between the url= and url.domain= conditions.

•

domain_suffix—A pattern which matches either a complete domain name or is a suffix

of the domain name, respecting component boundaries. An IP address is not allowed. This use of a domain_suffix pattern instead of a complete host name marks the difference between the url.domain= and url= conditions.

187

Volume 10: Content Policy Language Guide

•

port—A port number, between 1 and 65535.

•

path_query—The path_query portion of a URL is the string beginning with ‘/’ that follows the host and port, and precedes any URL fragment. A path_query pattern is a string beginning with a ‘/’ that matches the beginning of the path_query.

•

filename_extension—A string representing a filename extension to be tested, optionally preceded by a period (.). A quoted empty string (url.extension=””) matches URLs that do not include a filename extension, such as http://example.com/ and http://example.com/test. To test multiple extensions, use parentheses and a comma separator (see the Example section below).

•

regular_expression—A Perl regular expression. The expression must be quoted if it contains whitespace or any of the following: & | ( ) < > { } ; ! . = " '. For more information, see Appendix E: "Using Regular Expressions".

Objects with paths relative to the prefix_pattern and domain_suffix_pattern are also considered a match (see the “Example” section). The following are test modifiers: •

.case_sensitive—By default, all matching is case-insensitive; however, the matches on the path and query portions can be made case-sensitive by using the form url.case_sensitive=.

•

.domain—Changes the way the match is performed on the host portion of the URL. The host pattern is a domain_suffix pattern which either matches the hostname exactly, or matches a suffix of the hostname on component boundaries. The host is converted to a domain name by reverse DNS lookup if necessary. For example, the condition url.domain=//example.com matches the request URL http://www.example.com/, but does not match the request URL http://www.myexample.com/.

•

.exact—Forces an exact string comparison on the full URL or component.

•

.no_lookup—Depending on the form of the request’s host and the form of the pattern being matched, a DNS or reverse DNS lookup is performed to convert the request’s host before the comparison is made. This lookup can be suppressed by using the .no_lookup= form of the condition. The .no_lookup modifier speeds up policy evaluation, but use of it may introduce loopholes into your security policy that can be exploited by those who want to bypass your security measures. DNS and reverse DNS lookups can be globally restricted by restrict definitions.

The

.no_lookup option

should only be applied to url, url.host and url.domain conditions.

When applied to the url.host= condition, if the URL host was specified as an IP address, the behavior depends on whether the no_lookup modifier was specified. If no_lookup was specified, then the condition is false. If no_lookup was not specified, then a reverse DNS lookup is performed to convert the IP address to a domain name. If the reverse DNS lookup fails, then the condition is false.

188

Chapter 3: Condition Reference

Note:

If you deny the URL using url=http://www.sex.com/ for example, you cannot bypass the policy by simply requesting the IP address of www.sex.com, since the underlying DNS lookup exists for that particular condition. If, however, you deny the URL by using url.exact=http://www.sex.com, you can bypass the policy by simply using the IP address of that site.

When applied to the url.host= condition, this pattern match is always case-insensitive. •

.prefix—Test if the string pattern is a prefix of the URL or component.

•

.regex—Test the URL or component against a regular_expression pattern.

When applied to the url.host= condition, if the URL host was specified as an IP address, the behavior depends on whether the no_lookup modifier was specified. If no_lookup was specified, then the condition is false. If no_lookup was not specified, then a reverse DNS lookup is performed to convert the IP address to a domain name. If the reverse DNS lookup fails, then the condition is false. This leads to the following edge conditions: url.host.regex=!”” has the same truth value as url.host.no_name=yes, and url.host.regex.no_lookup=!”” has the same truth value as url.host.is_numeric=yes. When applied to the url.host= condition, this pattern match is always case-insensitive. •

.substring—Test if the string pattern is a substring of the URL or component. The substring need not match on a boundary (such as a subdomain or path directory) within a component.

•

.suffix—Test if the string pattern is a suffix of the URL or component. The suffix need not

match on a boundary (such as a domain component or path directory) within a URL component. Note:

.prefix, .regex, .substring, and .suffix are string comparisons that do not require a match on component boundaries. For this reason, url.host.suffix= differs from the host comparison used in url.domain= tests, which does require component level matches.

The URL component modifiers are: •

.address—Tests if the host IP address of the requested URL matches the specified IP address, IP

subnet, or subnet definition. If necessary, a DNS lookup is performed on the host name. DNS lookups can be globally restricted by a restrict DNS definition.

The patterns supported by the url.address= test are: •

ip_address—Host IP address or subnet; for example, 10.1.198.0.

•

subnet—A subnet mask; for example, 10.1.198.0/24.

•

subnet_label—Label of a subnet definition block that binds a number of IP addresses or

subnets.

The

modifier is primarily useful when the expression uses either a subnet or a subnet_label. If a literal ip_address is used, then the url.address= condition is equivalent to url.host=. .address

189

Volume 10: Content Policy Language Guide

•

.host—Tests the host component of the requested URL against the IP address or domain name specified by the host pattern. The pattern cannot include a forward slash (/) or colon (:). It does not recognize wild cards or suffix matching. Matches are case-insensitive. The default test type is .exact.

Note:

url.host.exact= can be tested using hash techniques rather than string matches, and will therefore have significantly better performance than other, string based, versions of the url.host= tests. .

Since the host component of a request URL can be either an IP address or a domain name, a conversion is sometimes necessary to allow a comparison. •

If the expression uses a domain name and the host component of the request URL is an IP address, then the IP address is converted to a domain name by doing a reverse DNS lookup.

•

If the expression uses an IP address and the host component of the request URL is a domain name, then the domain name is converted to an IP address by doing a DNS lookup.

The .host component supports additional test modifiers: •

.is_numeric—This is true if the URL host was specified as an IP address. For some types of transactions (for example, transparent requests on a non-accelerated port), this condition will always be true.

•

.no_name—This is true if no domain name can be found for the URL host. Specifically, it is

true if the URL host was specified as an IP address, and a reverse DNS lookup on this IP address fails, either because it returns no name or a network error occurs. •

.path—Tests the path component of the request URL. By default, the pattern is tested as a prefix of the complete path component of the requested URL, as well as any query component. The path and query components of a URL consist of all text from the first forward slash (/) that follows the host or port, to the end of the URL, not including any fragment identifier. The leading forward slash is always present in the request URL being tested, because the URL is normalized before any comparison is performed. Unless an .exact, .substring, or .regex modifier is used, the pattern specified must include the leading ‘/’ character.

In the following URL example, bolding shows the components used in the comparison; ?q=test is the included query component and #fragment is the ignored fragment identifier: http://www.example.com/cgi-bin/query.pl?q=test#fragment

A URL such as the following is normalized so that a forward slash replaces the missing path component: http://www.example.com becomes http://www.example.com/. •

.port—Tests if the port number of the requested URL is within the specified range or an exact

match. URLs that do not explicitly specify a port number have a port number that is implied by the URL scheme. The default port number is 80 for HTTP, so url.port=80 is true for any HTTP-based URL that does not specify a port.

The patterns supported by the url.address= test are: •

low_port_number—A port number at the low end of the range to be tested. Can be a number

between 1 and 65535. •

high_port_number—A port number at the high end of the range to be tested. Can be a

number between 1 and 65535.

190

Chapter 3: Condition Reference

•

exact_port_number—A single port number; for example, 80. Can be a number between 1

and 65535.

Note that the numeric pattern used to test the whitespace. •

url.port

condition can contain no

.query—Tests if the regex matches a substring of the query string component of the request URL. If no query string is present, the test is false. As a special case, url.query_regex=!"" is true no

query string exists. The query string component of the request URL, if present, consists of all text from the first question mark (?) following the path to the end of the URL. Note that pound (#) characters following the ? are included in the query string for compatibility with certain Web applications. a query string component exists, it begins with a ? character. •

.scheme—Tests if the scheme of the requested URL matches the specified schema string. The comparison is always case-insensitive.

Discussion The url= condition can be considered a convenient way to do testing that would require a combination of the following conditions: url.scheme=, url.host=, url.port=, and url.path=. For example, url=http://example.com:8080/index.html

is equivalent to: url.scheme=http url.host=example.com url.port=8080 url.path=/index.html

If you are testing a large number of URLs using the url= condition, consider the performance benefits of a url definition block or a [url] section (see Chapter 6: "Definition Reference"). If you are testing a large number of URLs using the url.domain= condition, consider the performance benefits of a url.domain definition block or a [url.domain] section (see Chapter 6: "Definition Reference"). Regular expression matches are not anchored. You may want to use either or both of the ^ and $ operators to anchor the match. Alternately, use the .exact, .prefix, or .suffix form of the test, as appropriate. Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to all non-administrator transactions.

Example ; Test if the URL includes this pattern, and block service. ; Relative URLs, such as docs subdirectories and pages, will match. url=http://www.example.com/docs max_bitrate(no) ; Test if the URL host’s IP address is a match. url.address=10.1.198.0 ; Test whether the URL includes company.com as domain. url.domain=company.com

191

Volume 10: Content Policy Language Guide

; Test whether the URL includes .com. url.domain=.com ; Test if the URL includes this domain-suffix pattern, ; and block service. Relative URLs, such as docs ; subdirectories and pages, will match. url.domain=company.com/docs max_bitrate(no) ; examples of the use of url.extension= url.extension=.txt url.extension=(.htm, .html) url.extension=(img, jpg, jpeg) ; ; ; ;

This example matches the first request and doesn’t match the second from the following two requests: http://1.2.3.4/test http://www.example.com

url.host.is_numeric=yes; ; In the example below we assume that 1.2.3.4 is the IP of the host mycompany ; The condition will match the following two requests if the reverse DNS was ; successful: ;request http://1.2.3.4/ ;request http://mycompany.com/ ; If the reverse DNS fails then the first request is not matched url.host.regex=mycompany ; url.path tests ; The following server_url.path strings would all match the example URL: ; http://www.example.com/cgi-bin/query.pl?q=test#fragment url.path=”/cgi-bin/query.pl?q=test” url.path=”/cgi-bin/query.pl” url.path=”/cgi-bin/” url.path=”/cgi” ; partial components match too url.path=”/” ; Always matches regardless of URL. ; testing the url port url.port=80

See Also

192

•

Conditions: category=, console_access=, content_management=, server_url=

•

Definitions: define subnet, define url condition, define url.domain condition

Chapter 3: Condition Reference

url.category= Test the content filter categories of the request URL. Synonym for 'category='. Syntax url.category=none|unlicensed|unavailable|pending|category_name1, category_name2, ...

Layer and Transaction Notes •

Use in , , , , and layers.

•

Applies to proxy transactions with a request URL.

Example url.category=Sports

See Also •

Conditions: category=, request.header.Referer.url.category=, server.certificate.hostname.category=

193

Volume 10: Content Policy Language Guide

user= Tests the authenticated username associated with the transaction. This condition is only available if the transaction was authenticated (that is, the authenticate( ) property was set to something other than no, and the proxy_authentication( ) property was not set to no). Syntax user=user_name

where user_name is a username. •

IWA realm: Usernames are case-insensitive. In IWA this provides the flexibility of matching either a full username or relative username. For example: user=bluecoat\mary.jones

matches a complete username, and user=mary.jones

matches a relative name. •

UNIX (local) realm: Usernames are case-sensitive.

•

RADIUS realm: Username case-sensitivity depends on the RADIUS server’s setting. The case-sensitive setting should also be set correctly when defining a RADIUS realm in the SG appliance.

•

LDAP realm: Username case-sensitivity depends on the LDAP server’s setting. The case-sensitive setting should also be set correctly when defining an LDAP realm in SG appliance. In LDAP this provides the flexibility of matching either a fully qualified domain name or relative username. For example: user=”cn=mary.jones,cn=sales,dc=bluecoat,dc=com”

-oruser=”uid=mary.jones,ou=sales,o=bluecoat”

matches a complete username, and user=mary.jones

matches a relative name.

194

Chapter 3: Condition Reference

Layer and Transaction Notes •

Use in , , and layers. Note:

When used in the layer, this condition can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Example ; Test for user john.smith. user=john.smith

See Also •

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user.domain=, user.x509.issuer=, user.x509.serialNumber=, user.x509.subject=

•

Properties: authenticate( ), authenticate.force( ), check_authorization( ), deny.unauthorized( ), socks.authenticate( ), socks.authenticate.force( )

195

Volume 10: Content Policy Language Guide

user.authentication_error= Test what, if any, error was encountered during user authentication. This condition is used to test what, if any, user authentication error was encountered. It will only be evaluated if the encountered error was also specified as a tolerated error. Syntax user.authenticaExampletion_error(any|none|not_attempted|,...)

where: •

any - evaluates to true if there was an authentication error.

•

none - evaluates to true if there were no authentication errors and authentication was attempted.

•

not_attempted - evaluates to true if authentication was not attempted.

•

,... - specifies a single error or a group of errors. If the authentication error is

one of the errors in the list then the condition will evaluate to true. Layer and Transaction Notes •

Valid layers: Proxy, SSL, Forward, Exception

•

Applies to: Proxy transactions

Example Redirect a user to a password change page after a password expiry authenticate(realm) authenticate.tolerate_error(expired_credentials) user.authentication_error=(expired_credentials) action.redirect_to_password_change_page define action redirect_to_password_change_page redirect(302, '.*', 'http://ourcompany.com/password_change'); end

196

Chapter 3: Condition Reference

user.authorization_error= Test what, if any, error was encountered during user authorization. This condition is used to test what, if any, user authorization error was encountered. It will only be evaluated if the encountered error was also specified as a tolerated error. Syntax user.authorization_error(any|none|not_attempted|,...)

where: •

any - evaluates to true if there was an authorization error.

•

none - evaluates to true if there were no authorization errors and authorization was

attempted. •

not_attempted - evaluates to true if authorization was not attempted.

•

,... - specifies a single error or a group of errors. If the authorization error is

one of the errors in the list then the condition will evaluate to true. Layer and Transaction Notes •

Valid layers: Proxy, SSL, Forward, Exception

•

Applies to: Proxy transactions

Example Add a user to a default group if authentication succeeded but authorization failed due to a communication error with the authorization server. authenticate(realm) authorize.tolerate_error(communication_error)

user.authorization_error=(communication_error) authorize.add_group(default_group)

197

Volume 10: Content Policy Language Guide

user.domain= Tests if the client is authenticated, the logged-into realm is an NTLM realm, and the domain component of the username is the specified domain. If all of these conditions are met, the response will be true. This condition is unavailable if the current transaction is not authenticated (that is, the authenticate( ) property is set to no). Syntax user.domain=windows_domain_name

where windows_domain_name is a Windows domain name. This name is case-insensitive. Layer and Transaction Notes •

Use in , , and layers.

Note:

When used in the layer, this condition can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Example ; Test if the user is in domain all-staff. user.domain=all-staff

See Also

198

•

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.x509.issuer=, user.x509.serialNumber=, user.x509.subject=

•

Properties: authenticate( ), authenticate.force( ), check_authorization( ), deny.unauthorized( ), socks.authenticate( ), socks.authenticate.force( )

Chapter 3: Condition Reference

user.is_guest= Test whether a user is authenticated as a guest user. Test whether a user is authenticated as a guest user. Only useful if used in conjunction with an authenticate.guest property. Syntax user.is_guest=(yes|no)

Layer and TransExampleaction Notes •

Valid layers: Proxy, SSL, Forward, Exception

•

Applies to: Proxy transactions

Example Add a guest user to a default group. authenticate.guest(guest_user, 900, realm)

user.is_guest=yes authorize.add_group(default_group)

199

Volume 10: Content Policy Language Guide

user.login.address= Test the address that user is logged in from. This condition is used to match the IP address or subnet that the user has logged in from. This may be different than the client IP address if the user is behind a proxy chain. The user login address can be set with the property: authenticate.credentials.address. Syntax user.login.address=ip_address|subnet|subnet_label

Layer and Transaction Notes •

Valid layers: , , ,

•

Applies to: All transactions

Example Allow the user if logged in from the subnet 10.167.146.0/24 user.login.address=10.167.146.0/24 allow

200

Chapter 3: Condition Reference

user.login.count= Test the number active logins of this user. This condition is used to test how many times the current user is logged in. It can be used to manage the maximum number of times a user is allowed to log in. Syntax user.login.count([lower]..[upper]|exact)

where: •

[lower] is optionally the fewest number of logins that will match this condition.

•

[upper] is optionally the most number of logins that will match this condition.

•

exact is optionally the exact number of logins that will match this condition.

Layer and Transaction Notes •

Valid layers: Proxy, Admin, Forward, Exception

•

Applies to: All transactions

Example Log out the other logins of a user if the user is logged in more than once. user.login.count=2.. user.login.log_out_other(yes)

201

Volume 10: Content Policy Language Guide

user.login.time= Test the number seconds that the current login has been active. This condition is used to test how many seconds the current user has been logged in at the current ip address. It can be used to manage the maximum time that a user is allowed to be logged in. Syntax user.login.time([lower]..[upper]|exact)

where: •

[lower] is optionally the fewest number of seconds that will match this condition

•

[upper] is optionally the most number of seconds that will match this condition

•

exact is optionally the exact number of seconds that will match this condition

Layer and Transaction Notes •

Valid layers: Proxy, Admin, Forward, Exception

•

Applies to: All transactions

Example Log out the user if the user has been logged in for more than one hour. user.login.time=3600.. user.login.log_out(yes)

202

Chapter 3: Condition Reference

user.x509.issuer= Tests the issuer of the x509 certificate used in authentication to certificate realms. The user.x509.issuer= condition is primarily useful in constructing explicit certificate revocation lists. This condition will only be true for users authenticated against a certificate realm. Syntax user.x509.issuer=issuer_DN

where issuer_DN is an RFC2253 LDAP DN, appropriately escaped. Comparisons are case-sensitive. Layer and Transaction Notes •

Use in , , , and layers. Note:

•

When used in the layer, this condition can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Applies to proxy transactions.

See Also •

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=, user.x509.serialNumber=, user.x509.subject=

•

Properties: authenticate( ), authenticate.force( )

203

Volume 10: Content Policy Language Guide

user.x509.serialNumber= Tests the serial number of the x509 certificate used to authenticate the user against a certificate realm. The user.x509.serialNumber= condition is primarily useful in constructing explicit certificate revocation lists. Comparisons are case-insensitive. Syntax user.x509.serialNumber=serial_number

where serial_number 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. This can be up to 160 bits. Layer and Transaction Notes •

Use in , , , and layers. Note:

•

When used in the layer, this condition can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Applies to proxy transactions.

See Also

204

•

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=, user.x509.issuer=, user.x509.subject=

•

Properties: authenticate( ), authenticate.force( )

Chapter 3: Condition Reference

user.x509.subject= Tests the subject field of the x509 certificate used to authenticate the user against a certificate realm. The user.x509.subject= condition is primarily useful in constructing explicit certificate revocation lists. Syntax user.x509.subject=subject

where subject is an RFC2253 LDAP DN, appropriately escaped. Comparisons are case-sensitive. Layer and Transaction Notes •

Use in , , , and layers. Note:

•

When used in the layer, this condition can evaluate to NULL (shown in a trace as N/A) if no authenticated client exists. Rules containing these conditions can be guarded by authenticated= to preserve normal logic.

Applies to proxy transactions.

See Also •

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=, user.x509.issuer=, user.x509.serialNumber=

•

Properties: authenticate( ), authenticate.force( )

205

Volume 10: Content Policy Language Guide

virus_detected= Test whether a virus has been detected. Note that rules containing this trigger will not match for a transaction that does not involve virus scanning. Syntax virus_detected=yes|no

Layer and Transaction Notes •

Use in and layers.

•

Applies to All HTTP transactions (proxy, refresh, pipeline), FTP proxy transactions.

Example virus_detected=yes

206

Chapter 3: Condition Reference

weekday= Tests if the day of the week is in the specified range or an exact match. By default, the SG appliance’s date is used to determine the day of the week. To specify the UTC time zone, use the form weekday.utc=. The numeric pattern used to test the weekday= condition can contain no whitespace Syntax weekday[.utc]={[first_weekday]..[last_weekday]|exact_weekday}

where: •

first_weekday—An integer from 1 to 7, where 1 specifies Monday and 7 specifies

Sunday, indicating the first day of the week that tests true. If left blank, Monday is assumed. •

last_weekday—An integer from 1 to 7, where 1 specifies Monday and 7 specifies Sunday,

indicating the last day of the week that tests true. If left blank, Sunday is assumed. •

exact_weekday—An integer from 1 to 7, where 1 specifies Monday and 7 specifies

Sunday, indicating the day of the week that tests true. Note:

When you want to test a range that wraps from one week into the next, the following shorthand expression is available. While weekday=(..1|6..) specifies a long weekend that includes Monday, the policy language also recognizes weekday=6..1 as equivalent.

Layer and Transaction Notes •

Use in all layers.

•

Using time-related conditions to control caching behavior in a layer may cause thrashing of the cached objects.

•

Applies to all transactions.

Example ; Test for the weekend. weekday=6..7 ; Test for Saturday through Monday. weekday=6..1

See Also •

Conditions: date[.utc]=, day=, hour=, minute=, month=, time=, year=

207

Volume 10: Content Policy Language Guide

year= Tests if the year is in the specified range or an exact match. The current year is determined by the date set on the SG appliance by default. To specify the UTC time zone, use the form year.utc=. Note that the numeric pattern used to test the year= condition can contain no whitespace. Syntax year[.utc]={[first_year]..[last_year]|exact_year}

where: •

first_year—Four digits (nnnn) representing the start of a range of years; for

example, 2002.

Note:

•

last_year—Four digits (nnnn) representing the end of a range of years. If left blank, all years from first_year on are assumed.

•

exact_year—Four digits (nnnn) representing an exact year.

To test against an inverted range of years, the following shorthand expression is available. While year=(..1998|2003..) specifies years up to and including 1998, and from 2003 on, the policy language also recognizes year=2003..1998 as equivalent.

Layer and Transaction Notes •

Use in all layers.

•

Using time-related conditions to control caching behavior in a layer may cause thrashing of the cached objects.

•

Applies to all transactions.

Example ; Tests for the years 2004 through 2006. year=2004..2006

See Also •

208

Conditions: date[.utc]=, day=, hour=, minute=, month=, time=, weekday=, year=

Chapter 4:

Property Reference

A property is a variable that can be set to a value. At the beginning of a transaction, all properties are set to their default values. As each layer in the policy is evaluated in sequence, it can set a property to a particular value. A property retains the final value setting when evaluation ends, and the transaction is processed accordingly. Properties that are not set within the policy maintain their default values.

Property Reference The remainder of this chapter lists the properties and their accepted values. It also provides tips as to where each property can be used and examples of how to use them.

209

Volume 10: Content Policy Language Guide

access_log( ) Selects the access log used for this transaction. Multiple access logs can be selected to record a single transaction. Individual access logs are referenced by the name given in configuration. Configuration also determines the format of the each log. For more information on logging, refer to Volume 9: Access Logging.

To record entries in the event log, see "log_message( )" on page 364. Syntax access_log(auto|no|log_name_list) access_log.log_name(yes|no) access_log.[log_name_list](yes|no)

The default value is auto. where: •

auto—use the default log for this protocol.

•

no—turns off logging, either for this transaction or to the specified log_name or log_name_list.

•

yes—turns on logging for this transaction to the specified log_name or log_name_list.

•

log_name—an access log name as defined in configuration

•

log_name_list—a list of access log names as defined in configuration, of the form: log_name_1, log_name_2, ...

Discussion Each of the syntax variants has a different role in selecting the list of access logs used to record the transaction: •

access_log( ) overrides any previous access log selections for this transaction.

•

access_log.log_name( ) selects or de-selects the named log, according to the specified value. Any other log selections for the transaction are unaltered.

•

access_log.[log_name_list]( ) selects or de-selects all the logs named in the list, according to the specified value. The selection of logs not named in the list is unaffected.

Layer and Transaction Notes •

Use in all , . , layers.

•

Applies to proxy transactions.

See Also

210

•

Properties: log.suppress.field-id, log.rewrite.field-id( )

•

Actions: log_message( )

Chapter 4: Property Reference

access_server( ) Determines whether the client can receive streaming content directly from the origin content server or other upstream device. Set to no to serve only cached content. Note:

Since part of a stream can be cached, and another part of the same stream can be uncached, access_server(no) can cause a streaming transaction to be terminated after some of the

content has been served from the cache. Syntax access_server(yes|no)

The default value is yes. Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to DNS, HTTP, SOCKS, and streaming transactions.

See Also •

Conditions: bitrate=, live=, streaming.client=, streaming.content=

211

Volume 10: Content Policy Language Guide

action( ) Selectively enables or disables a specified define action block. The default value is no. Note:

Several define action blocks may be enabled for a transaction. If more than one action selected rewrites the URL or header a specific header, the actions are deemed to conflict and only one will be executed. When detected at runtime, action conflicts will be reported in the event log as a severe event. Action conflicts may also be reported at compilation time.

Syntax action(action_label) action.action_label(yes|no)

The default value is no for all defined actions. where action_label is the label of the define action block to be enabled or disabled. Discussion Each of the different syntax variants has a different role in selecting the list of actions applied to the transaction: •

action() enables the specified action block and disables all other actions blocks.

•

action.action_label( ) enables or disables the specific action block. Any other action block selections for the transaction are unaltered.

Layer and Transaction Notes •

Use in , , and layers. The actions specified in the action block must be appropriate to the referencing layer.

See Also •

212

Definitions: define action

Chapter 4: Property Reference

adn.server( ) This property is used to enable or disable ADN service. Syntax adn.server(yes|no)

The default value is taken from the applicable service configuration. Layer and Transaction Notes •

Valid layers: Forward

•

Applies to: Proxy transactions

Example This property allows control of whether an ADN service is enabled in the layer. The following example shows the property used to disable ADN service. adn.server(no)

See Also •

Properties: adn.server.optimize( )

213

Volume 10: Content Policy Language Guide

adn.server.optimize( ) If the value is set to yes then data both to and from the server will be optimized. This property is applied only if the application proxy server connection is forwarded over an ADN tunnel. Syntax adn.server.optimize(yes|no|byte_cache|compress) adn.server.optimize.optimization-setting(yes|no) adn.server.optimize[optimization-settings](yes|no)

Where optimization-setting is one of byte_cache or compress. The default value is taken from the applicable service configuration, which is dependent on the service. Layer and Transaction Notes •

Valid layers: Forward

•

Applies to: Proxy transactions

Example This property allows control of the optimization of individual connections based on any policy conditions available in the layer. The following example shows the property used to disable optimizations for data flowing in both directions between clients from a specified subnet and a particular service. client.address=10.10.167.0/24 \ service.name="XWindows" \ adn.server.optimize(no)

See Also •

214

Properties: adn.server.optimize.inbound( ), adn.server.optimize.outbound( )

Chapter 4: Property Reference

adn.server.optimize.inbound( ) If the value is set to yes then data received from the server will be optimized. This property is applied only if the application proxy server connection is forwarded over an ADN tunnel. Syntax adn.server.optimize.inbound(yes|no|byte_cache|compress) adn.server.optimize.inbound.optimization-setting(yes|no) adn.server.optimize.inbound[optimization-settings](yes|no)

where optimization-setting is one of byte_cache or compress. The default value is taken from the applicable service configuration, which is dependent on the service. Layer and Transaction Notes •

Valid layers: Forward

•

Applies to: Proxy transactions

Example This property allows control of the optimization of data received over individual server connections based on any policy conditions available in the layer. The following example shows the property used to disable optimization for data from a particular host. server_url.host=my_host.my_business.com \ adn.server.optimize.inbound(no)

See Also •

Properties: adn.server.optimize( ), adn.server.optimize.outbound( )

215

Volume 10: Content Policy Language Guide

adn.server.optimize.outbound( ) If the value is set to yes then data sent to the server will be optimized. This property is applied only if the application proxy server connection is forwarded over an ADN tunnel. Syntax adn.server.optimize.outbound(yes|no|byte_cache|compress) adn.server.optimize.outbound.optimization-setting(yes|no) adn.server.optimize.outbound[optimization-settings](yes|no)

where optimization-setting is one of byte_cache or compress. The default value is taken from the applicable service configuration, which is dependent on the service. Layer and Transaction Notes •

Valid layers: Forward

•

Applies to: Proxy transactions

Example This property allows control of the optimization of data sent over individual server connections based on any policy conditions available in the layer. The following example shows the property used to disable optimization for data sent to a particular host. server_url.host=my_host.my_business.com \ adn.server.optimize.outbound(no)

See Also •

216

Properties: adn.server.optimize( ), adn.server.optimize.inbound( )

Chapter 4: Property Reference

advertisement( ) Determines whether to treat the objects at a particular URL as banner ads to improve performance. If the content is not specific to a particular user or client, then the hit count on the origin server is maintained while the response time is optimized using the following behavior: •

Always serve from the cache if a cached response is available. Ignore any request headers that bypass the cache; for example, Pragma: No-Cache.

•

Always cache the response from the origin server, similar to force_cache(all).

•

If the request was served from the cache, request the object from the origin server in the background to maintain the origin server's hit count on the ad and also allow ad services to deliver changing ads.

A number of CPL properties affect caching behavior, as listed in the “See Also” section below. Remember that any conflict between their settings is resolved by CPL evaluation logic, which uses the property value that was last set when evaluation ends. Syntax advertisement (yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP transactions, except FTP over HTTP transactions.

See Also •

Properties: always_verify( ), cache( ), cookie_sensitive( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

217

Volume 10: Content Policy Language Guide

allow Allows the transaction to be served. Allow can be overridden by the access_server( ), deny( ), force_deny( ), authenticate( ), exception( ), or force_exception( ) properties or by the redirect( ) action. Allow overrides deny( ) and exception( ) properties. Note:

Caution should be exercised when using allow in layers evaluated after layers containing deny, to ensure that security is not compromised.

Syntax allow

Layer and Transaction Notes •

Use in , , , and layers. Use "access_server( )" on page 211.

•

Applies to all transactions.

See Also •

Properties: access_server( ), deny( ), force_deny( ), authenticate( ), exception( ), force_exception( )

•

218

Actions: redirect( )

Chapter 4: Property Reference

always_verify( ) Determines whether each request for the objects at a particular URL must be verified with the origin server. This property provides a URL-specific alternative to the global caching setting always-verify-source. If there are multiple simultaneous accesses of an object, the requests are reduced to a single request to the origin server. Syntax always_verify(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions, except FTP over HTTP transactions.

See Also •

Properties: advertisement( ), bypass_cache( ), cache( ), cookie_sensitive( ), force_cache( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

219

Volume 10: Content Policy Language Guide

authenticate() Authenticate the user in the specified realm, or disable authentication for this transaction. When authentication is dependent on any condition that is not part of the client's identity, then some transactions from the client will be authenticated and some won't. However the browser will offer some credential types pro-actively. The default behavior of the SG appliance is to forward any proxy credentials that it does not consume. To prevent forwarding of proxy credentials in situations where there is no upstream proxy authentication, use the no_upstream_authentication option. Syntax authenticate(realm_name) -orauthenticate(no [, upstream_authentication|no_upstream_authentication])

where: ❐ ❐

realm_name is the name of a configured authentication realm. upstream_authentication indicates that offered proxy credentials should be passed

upstream ❐

no_upstream_authentication indicates that offered proxy credentials should not be passed

upstream Layer and Transaction Notes •

Use in and layers.

•

Applies to Proxy and Administrative transactions.

Example This example implements the following policy: 1.

All traffic to a.com will be authenticated.

2.

All traffic to b.com will be authenticated by an upstream proxy.

3.

All other traffic will be unauthenticated, and proxy credentials will not be forwarded.

url.domain=//a.com/ authenticate(localr) url.domain=//b.com/ authenticate(no) authenticate(no, no_upstream_authentication)

See Also •

Conditions: authenticated=, exception.id=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=

•

Properties: authenticate.force( ), authenticate.mode( ), authenticate.use_url_cookie( ), check_authorization( ), socks.authenticate( ), socks.authenticate.force( )

220

Chapter 4: Property Reference

authenticate.authorization_refresh_time( ) Specify the number of seconds that authorization data can be cached. Once the authorization data for a user (groups and attributes) is determined, that data is cached on the Proxy. This property sets the number of seconds that this cached data can be trusted. After that time, the data must be refreshed. This property overrides the equivalent setting in the realm. If this property does not exist, then the realm setting will apply. Syntax authenticate.authorization_refresh_time(seconds)

where: seconds is the number of seconds that authorization data can be cached and reused. Once that time

expires, the authorization data must be refreshed from the authorization server. The default value is 1. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Set the authorization refresh time to one hour. authenticate(myrealm) authenticate.authorization_refresh_time(3600)

221

Volume 10: Content Policy Language Guide

authenticate.charset( ) Specify the character encoding used by HTTP basic authentication. The HTTP Basic authentication protocol sends the username and password to the proxy or origin server as an array of bytes. The character encoding is arbitrarily chosen by the client. Within the HTTP protocol, there is no way for the client to tell the upstream device which encoding is used. If the username or password contains non-ASCII characters, then the SG appliance needs to know what this character encoding is. Since there is no way for the proxy to determine this from the HTTP request, it must be specified in policy, using the authenticate.charset property. The default value is ascii. If the HTTP Basic credentials are not encoded as specified by the authenticate.charset property, then the HTTP request is terminated by an invalid_credentials exception. Therefore, if authenticate.charset is set to its default value of ascii, and the username or password contain non-ascii characters, then the request will be terminated. You must configure authenticate.charset to use non-ascii credentials using the HTTP Basic authentication protocol. An alternative to configuring this property is to use a different client-side authentication protocol, such as IWA, or forms-based authentication. Syntax authenticate.charset(charset)

where: charset

A MIME charset name. Any of the standard charset names for encodings commonly supported by Web browsers may be used. One list of standard charset names is: http://www.iana.org/assignments/character-sets.

If you use Microsoft Windows, then you can use the "chcp" command in the Windows CLI to find out your active code page. Once you know the code page number n, you can use "windows-n" as the charset name. The default value is ascii. Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example Set the authentication character encoding to "windows-936", which is the "extended ascii" encoding used by Microsoft Windows in North America. authenticate(myrealm) authenticate.charset(windows-936)

222

Chapter 4: Property Reference

authenticate.credential_refresh_time() Specify the number of seconds that passwords can be cached. When a realm uses Basic authentication, the password is cached by the User Management framework. This cached password can be trusted for the given number of seconds. After that time expires, the password must be verified with the authentication server. This property overrides the equivalent setting in the realm. If this property does not exist, then the realm setting will apply. Syntax authenticate.credential_refresh_time(seconds)

where seconds is the number of seconds that passwords can be cached and reused. Once that time expires, the password must be verified with the authentication server. The default value is 1. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Set the credential refresh time to one hour. authenticate(myrealm) authenticate.credential_refresh_time(3600)

223

Volume 10: Content Policy Language Guide

authenticate.credentials.address( ) Specify the number of seconds that surrogates can be trusted. This property allows overriding the address used for authentication. It will set the IP address of the login session. Syntax authenticate.credentials.address(ip address

The default value is 0.0.0.0. Layer and Transaction Notes •

Valid layers:

•

Applies to: Proxy transactions

Example Set the address of the login to value from the Client-IP header. authenticate(myrealm)\ authenticate.credentials.address($(request.header.Client-IP))

224

Chapter 4: Property Reference

authenticate.guest( ) Specify to authenticate as a guest user. This property can be used to support authenticating guest users. If a transaction matches both a guest and regular authentication request it will first attempt regular authentication. If regular authentication fails on a tolerated error it will then fallback to guest authentication. Syntax authenticate.guest(username [, surrogate-refresh-time [, realm] ])

where •

username specifies the substitution string to evaluate to determine the guest username e.g.

"guest_$(client.address)" •

surrogate-refresh-time (optional) specifies the refresh time for the guest user's surrogate credential. If no refresh time is specified (or "0" is specified) then the surrogate refresh time specified in the authentication realm is used.

•

realm (optional) specifies the authentication realm to authenticate the user in. The user does not actually have to exist on the authentication server. If no realm is specified then the realm used in a previous authentication attempt in the transaction will be used. If the transaction has not attempted a regular authentication and no realm is specified the user will receive an authentication exception.

Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: Proxy transactions

Example To log users in as guest automatically authenticate.guest(realm,guest_user) allow

To attempt authentication of a user first and then have the user explicitly select to login as guest if authentication fails, modify the authentication_failed exception to included a link that has been designated as the guest login URL for that realm and then use the following policy: url= authenticate.guest("guest_$(client.address)", 0, realm) authenticate(realm) allow

225

Volume 10: Content Policy Language Guide

authenticate.force( ) This property controls the relation between authentication and denial. Syntax authenticate.force(yes|no)

The default value is no. where: •

yes —Makes an authenticate( ) higher priority than deny( )or exception( ). Use yes to ensure that user IDs are available for access logging (including denied requests).

•

no—deny( ) and exception( ) have a higher priority than authenticate( ). This setting allows early denial.

Layer and Transaction Notes •

Use in and layers and transactions.

•

Does not apply to layers or transactions.

See Also •

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=

•

Properties: authenticate( ), check_authorization( ), socks.authenticate( ), socks.authenticate.force( )

226

Chapter 4: Property Reference

authenticate.form( ) When forms-based authentication is in use, this property selects the form used to challenge the user. Syntax authenticate.form(authentication-form)

Layer and Transaction Notes •

Used in layers.

•

Applies to HTTP proxy transactions.

Example This example implements the following policy: •

All traffic from subnet HR_subnet must use the authentication form “HR_form.”

•

All traffic from subnet ENG_subnet must use the authentication form “ENG_form.”

•

All other traffic uses the default authentication form. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end =authenticate(myrealm) authenticate.mode(form-cookie-redirect) ; 1 client.address=HR_subnet authenticate.form(HR_form) ; 2 client.address=ENG_subnet authenticate.form(ENG_form) ; 3 -- no modification to 'authenticate.form' selects the default form

227

Volume 10: Content Policy Language Guide

authenticate.mode( ) Using the authentication.mode( ) property selects a combination of challenge type and surrogate credentials. Challenge type is what kind of challenge (proxy, origin or origin-redirect) is issued. Surrogate credentials are credentials accepted in place of the user’s real credentials. They are used for a variety of reasons. Blue Coat supports three kinds of surrogate credentials. •

IP surrogate credentials authenticate the user based on the IP address of the client. Once any client has been successfully authenticated, all future requests from that IP address are assumed to be from the same user.

•

Cookie surrogate credentials use a cookie constructed by the SG appliance as a surrogate. The cookie contains information about the user, so multiple users from the same IP address can be distinguished. The cookie contains a temporary password to authenticate the cookie; this password expires when the credential cache entry expires.

•

Connection surrogate credentials use the TCP/IP connection to authenticate the user. Once authentication is successful, the connection is marked authenticated and all future requests on that connection are considered to be from the same user.

In SGOS 3.x, the connection’s authentication information includes the realm in which it was authenticated. The surrogate credentials are accepted only if the current transaction’s realm matches the realm in which the session was authenticated. Syntax authenticate.mode(mode_type)

where mode_type is one of the following, shown followed by the implied challenge type and surrogate credential:

228

•

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 SG appliance 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 SG appliance 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 SG appliance acts like an OCS and issues OCS challenges. The authenticated connection serves as the surrogate credential.

•

Origin-IP: The SG appliance 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.

Chapter 4: Property Reference

•

Origin-cookie: The SG appliance 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 SG appliance does not support origin-redirects with the CONNECT method.

•

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

•

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. Layer and Transaction Notes •

Use in layers

•

Applies to proxy transactions.

229

Volume 10: Content Policy Language Guide

authenticate.new_pin_form() When Forms-Based authentication is in use, this selects the form to prompt user to enter a new PIN. Syntax authenticate.new_pin_form(new-pin-form-name)

where new-pin-form-name is the name of a valid new-pin form Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

Example This example implements the following policy: 1.

All traffic from subnet HR_subnet must use the new-pin form 'HR_new_pin_form'

2.

All traffic from subnet ENG_subnet must use the new-pin form ENG_new_pin_form

3.

All other traffic uses the default authentication form. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end authenticate(myrealm) authenticate.mode(form-cookie-redirect) ; 1 client.address=HR_subnet authenticate.new_pin_form(HR_new_pin_form) ; 2 client.address=ENG_subnet authenticate.new_pin_form(ENG_new_pin_form) ; 3 -- no modification to 'authenticate.new_pin_form' selects the default form

230

Chapter 4: Property Reference

authenticate.query_form() When Forms-Based authentication is in use, this selects the form to display to the user when a yes/no questions needs to be answered. Syntax authenticate.query_form(query-form-name)

where query-form-name is the name of a valid query form. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

Example This example implements the following policy: 1.

All traffic from subnet HR_subnet must use the query form HR_query_form

2.

All traffic from subnet ENG_subnet must use the query form ENG_query_form

3.

All other traffic uses the default authentication form . define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end authenticate(myrealm) authenticate.mode(form-cookie-redirect) ; 1 client.address=HR_subnet authenticate.query_form(HR_query_form) ; 2 client.address=ENG_subnet authenticate.query_form(ENG_query_form) ; 3 -- no modification to 'authenticate.query_form' selects the default form

231

Volume 10: Content Policy Language Guide

authenticate.redirect_stored_requests() Determines whether requests stored during forms-based authentication can be redirected if the upstream host issues a redirecting response. Syntax authenticate.redirect_stored_requests(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

Example authenticate.redirect_stored_requests(yes)

232

Chapter 4: Property Reference

authenticate.surrogate_refresh_time() Specify the number of seconds that surrogates can be trusted. This property is used to control the number of seconds that a surrogate credential is trusted. A surrogate can be a cookie, an ip address or a previously authenticated connection. Once this time expires, the surrogate is no longer trusted and must be refreshed by re-verifying the real credentials. This property overrides the equivalent setting in the realm. If this property does not exist, then the realm setting will apply. Syntax authenticate.surrogate_refresh_time(seconds)

where seconds is the number of seconds that surrogate credentials can be trusted (i.e. ip surrogate, cookie surrogate, connection surrogate). Once that time expires, the real credentials must be verified. The default value is 1. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Set the surrogate refresh time to one hour. authenticate(myrealm) authenticate.surrogate_refresh_time(3600)

233

Volume 10: Content Policy Language Guide

authenticate.tolerate_error() Specify to allow certain errors during user authentication. This property can be used to support attempting authenticating but allowing the transaction to proceed if authentication fails for the specified error. IMPORTANT NOTE: Tolerating the error group "all" will result in all authentication errors including need_credentials to be tolerated. If specified then users will never be challenged which is often not the desired behaviour. Use the error group "all" carefully. Syntax authenticate.tolerate_error.(yes|no) authenticate.tolerate_error[,...](yes|no) authenticate.tolerate_error(,...) where: authenticate.tolerate_error(,?) is equivalent to authenticate.tolerate_error[?](yes) •

yes - specifies that the error is permitted and the transaction should proceed unauthenticated

•

no - specifies that the error is not permitted and the transaction should terminate

•

,... - specifies a single error or a group of errors

Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: Proxy transactions

Example Redirect a user to a password change page after a password expiry authenticate(realm) authenticate.tolerate_error(expired_credentials)

user.authentication_error=(expired_credentials) action.redirect_to_password_change_page

define action redirect_to_password_change_page redirect(302, '.*', 'http://ourcompany.com/password_change'); end

234

Chapter 4: Property Reference

authenticate.use_url_cookie( ) This property is used to authenticate users who have third party cookies explicitly disabled. Note:

With a value of yes, if there is a problem loading the page (you get an error page or you cancel an authentication challenge), the cfauth cookie is displayed. You can also see the cookie in packet traces, but not in the browser URL window or history under normal operation.

Syntax authenticate.use_url_cookie(yes|no)

The default is no. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

See Also Properties: authenticate.mode( )

235

Volume 10: Content Policy Language Guide

authorize.add_group() Add default group(s) to an authenticated user. This property can be used to specify a single group or list of groups to add to an authenticated user. This property can only be used if the user is successfully authenticated. Syntax authorize.add_group(,...)

where: ,... - specifies the group or list of groups to add to the user

Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: All transactions

Example Add a user to a default group if authentication succeeded but authorization failed due to a communication error with the authorization server. authenticate(realm) authorize.tolerate_error(communication_error)

user.authorization_error=(communication_error) authorize.add_group(default_group)

236

Chapter 4: Property Reference

authorize.tolerate_error() Specify to allow certain errors during user authorization. This property can be used to support attempting authorization but allowing the transaction to proceed if authorization fails for the specified error. Note: If this property is not explicitly specified in policy it will default to allowing the same errors as specified in any authenticate.tolerate_error properties. Syntax authorize.tolerate_error.(yes|no) authorize.tolerate_error[,...](yes|no) authorize.tolerate_error(,...)

where: authorize.tolerate_error(,?) is equivalent to authorize.tolerate_error[?](yes) •

yes - specifies that the error is permitted and the transaction should proceed without

authorization data •

no - specifies that the error is not permitted and the transaction should terminate

•

,... - specifies a single error or a group of errors

Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: Proxy transactions

Example Add a user to a default group if authentication succeeded but authorization failed due to a communication error with the authorization server. authenticate(realm) authorize.tolerate_error(communication_error)

user.authorization_error=(communication_error) authorize.add_group(default_group)

237

Volume 10: Content Policy Language Guide

bypass_cache( ) Determines whether the cache is bypassed for a request. If set to yes, the cache is not queried and the response is not stored in the cache. Set to no to specify the default behavior, which is to follow standard caching behavior. While static and dynamic bypass lists allow traffic to bypass the cache based on the destination IP address, the bypass_cache property is intended to allow a bypass based on the properties of the client; for example, you might use it to allow specific users or user groups to bypass the cache. This property has no effect on streaming objects. Syntax bypass_cache(yes|no)

The default is no. Layer and Transaction Notes •

Use only in layers.

•

Applies to HTTP, HTTPS, FTP over HTTP, and transparent FTP transactions.

Example ; Bypass the cache for requests from this client IP address. client.address=10.25.198.0 bypass_cache(yes)

See Also •

Properties: advertisement( ), always_verify( ), cache( ), cookie_sensitive( ), direct( ), dynamic_bypass( ), force_cache( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

238

Chapter 4: Property Reference

cache( ) Controls HTTP and FTP caching behavior. A number of CPL properties affect caching behavior. •

If bypass_cache(yes) is set, then the cache is not accessed and the value of cache( ) is irrelevant.

•

If cache(yes) is set, then the force_cache(all) property setting modifies the definition of what is considered a cacheable response.

•

The properties cookie_sensitive(yes) and ua_sensitive(yes) have the same effect on caching as cache(no).

Other CPL properties that affect caching behavior are listed in the “See Also” section below. Remember that any conflict between their settings is resolved by CPL evaluation logic, which uses the property value that was last set when evaluation ends. Syntax cache(yes|no)

The default is yes. where: •

yes—Specifies the default behavior: cache responses from the origin server if they are cacheable.

•

no—Do not store the response in the cache, and delete any object that was previously cached for this URL.

Layer and Transaction Notes •

Use only in layers.

•

Applies to proxy transactions.

Example ; Prevent objects at this URL from being added to the cache. url=http://www.example.com/docs cache(no)

; This example shows use of cache(yes) in an exception to broader no-cache policy. define url.domain condition non_cached_sites http://example1.com http://example2.com end condition=non_cached_sites cache(no) url.extension=(gif, jpg) cache(yes) ; OK to cache these file types regardless.

239

Volume 10: Content Policy Language Guide

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cookie_sensitive( ), direct( ), dynamic_bypass( ), force_cache( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

240

Chapter 4: Property Reference

category.dynamic.mode( ) Determines how dynamic categorization will be performed. Syntax category.dynamic.mode(none|realtime|background|default)

where: •

none: suppresses dynamic categorization for this request

•

realtime: performs dynamic categorization in real-time; the request waits until the dynamic

category is available from the service •

background: performs dynamic categorization in the background; the request is assigned the category 'pending', and continues to be processed without delay. Later, when the categorization service responds, the dynamically-determined category for the requested object is saved so that future requests for the object can make use of it.

•

default: restores the setting to the configuration-specified default (to undo the effect of a previous policy layer)

The default value is set via configuration. Layer and Transaction Notes •

Use in and layers.

•

Applies to all transactions.

Example This example illustrates how the property is used to control dynamic categorization. ; do not dynamically categorize this domain url.domain=bluecoat.com category.dynamic.mode(none) ; serve this domain and categorize in the background url.domain=yahoo.com category.dynamic.mode(background) ; categorize all other requests in real time category.dynamic.mode(realtime)

241

Volume 10: Content Policy Language Guide

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 sometimes (not always or never) requires the user to authenticate and be authorized for this object. Setting the value to yes results in a GIMS (Get If Modified Since) to check authorization upstream, and the addition of a “Cache-Control: must-revalidate” header to the downstream response. Syntax check_authorization(yes|no)

The default is no. Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP and RTSP proxy transactions.

See Also

242

•

Conditions: authenticated=, group=, has_attribute.name=, http.transparent_authentication=, realm=, user=, user.domain=

•

Properties: authenticate( ), authenticate.force( )

Chapter 4: Property Reference

client.address.login.log_out_other() Log out the any logins at this ip address other than the current login. This property is used to log out any other logins at the current ip address other than the current login of the transaction. Other users will need to re-authenticate at the this ip address before future transactions at this ip address can proceed. Syntax client.address.login.log_out_other(yes|no)

The default value is yes. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Log out the other logins of there is more than one login at this ip address. client.address.login.count=2.. client.address.login.log_out_other(yes)

243

Volume 10: Content Policy Language Guide

client.certificate.require( ) Controls whether a certificate is requested from the client during SSL negotiations. Syntax client.certificate.require(yes|no)

For HTTPS Forward Proxy transactions, the default value is no . For HTTPS Reverse Proxy transactions the default value is the same as the value of the verify-client attribute for the corresponding reverse proxy service. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTPS forward and reverse proxy transactions.

Example This HTTPS forward proxy policy implements consent certificates. The client Web browser is required to send a client certificate. The user has a choice of two predefined certificates: one certificate gives the proxy permission to intercept the SSL session, and the other certificate denies the proxy this permission. Thus, the human end-user gives explicit consent to have the SSL session intercepted. ssl.proxy_mode=https-forward-proxy client.certificate.require(yes) ssl.proxy_mode=https-forward-proxy OK client.certificate.common_name = "Yes decrypt my data" FORCE_DENY

244

Chapter 4: Property Reference

client.certificate.validate( ) Determines whether client X.509 certificates will be verified during the establishment of SSL connections. Syntax client.certificate.validate(yes|no)

The default value is taken from the configuration of the HTTPS service accepting the connection. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTPS forward and reverse proxy transactions.

Example client.certificate.validate(yes)

See Also •

Properties: server.certificate.validate( )

245

Volume 10: Content Policy Language Guide

client.certificate.validate.check_revocation() Determines whether client X.509 certificates will be checked for revocation. Syntax client.certificate.validate.check_revocation(auto|ocsp|local|no)

where: •

auto the certificate will be checked through OCSP if available, otherwise it will be checked against locally installed revocation list.

•

ocsp

•

no

•

local

checks the certificate through OCSP. the certificate will not be checked for revocation. checks the certificate against the locally installed revocation list.

The default value is auto. Layer and Transaction Notes •

Valid layers: SSL.

•

Applies to HTTPS forward and reverse proxy transactions.

Example Sample usage: client.certificate.validate.check_revocation(local)

246

Chapter 4: Property Reference

client.connection.dscp() Controls client side outbound QoS/DSCP value. Syntax client.connection.dscp(dscp_value)

where dscp_value is 0..63 | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | best-effort | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | ef | echo | preserve

The special value preserve means to track the incoming DSCP value on the primary server connection and use that as the value when sending packets on the client connections. The special value echo means the outbound packet's DSCP value will use the same value as the inbound packet's DSCP value. The default value is preserve. Layer and Transaction Notes •

Valid in and layers.

•

Applies to all transactions.

Example The first QoS policy rule sets the client outbound QoS/DSCP value to echo, and the second QoS policy rule sets the client outbound QoS/DSCP value to 50. client.connection.dscp(echo) client.connection.dscp(50)

247

Volume 10: Content Policy Language Guide

cookie_sensitive( ) Used to modify caching behavior by declaring that the object served by the request varies based on cookie values. Set to yes to specify this behavior, or set to no for the default behavior, which caches based on HTTP headers. Using cookie_sensitive(yes) has the same effect as cache(no). There are a number of CPL properties that affect caching behavior, as listed in the “See Also” section below. Remember that any conflict between their settings is resolved by CPL evaluation logic, which uses the property value that was last set when evaluation ends. Syntax cookie_sensitive(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions, except FTP over HTTP transactions.

See Also •

248

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), direct( ), force_cache( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

Chapter 4: Property Reference

delete_on_abandonment( ) If set to yes, specifies that if all clients who may be simultaneously requesting a particular object close their connections before the object is delivered, the object fetch from the origin server is abandoned, and any prior instance of the object is deleted from the cache. Syntax delete_on_abandonment(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions.

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), cookie_sensitive( ), direct( ), dynamic_bypass( ), force_cache( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

249

Volume 10: Content Policy Language Guide

deny( ) Denies service. Denial can be overridden by allow or exception( ). To deny service in a way that cannot be overridden by a subsequent allow, use force_deny( ) or force_exception( ). The relation between authenticate( ) and deny( ) is controlled by the authenticate.force ) property. By default, deny( ) overrides authenticate( ). Recall that this means that a transaction can be denied before authentication occurs, resulting in no user identification available for logging. Similarly, the relation between socks.authenticate( ) and deny( ) is controlled by the socks.authenticate.force( ) property. By default, deny( ) overrides socks.authenticate( ). Syntax deny deny(details)

where details is a string defining a message to be displayed to the user. The details string may contain CPL substitution variables. Discussion The deny(details) property is equivalent to exception(policy_denied, details). The identity of an exception being returned can be tested in an layer using exception.id=. For HTTP, a policy_denied exception results in a 403 Forbidden response. This is appropriate when the denial does not depend on the user identity. When the denial does depend on user identity, use deny.unauthorized( ) instead to give the user an opportunity to retry the request with different credentials. Layer and Transaction Notes •

Use in , , , and layers. In layers, use "access_server( )" on page 211.

•

Applies to all transactions.

Example deny url.address=10.25.100.100

See Also

250

•

Condition: exception.id=

•

Properties: allow, authenticate.force( ), deny.unauthorized( ), force_deny( ), never_refresh_before_expiry( ), never_serve_after_expiry( ), remove_IMS_from_GET( ), remove_PNC_from_GET( ), remove_reload_from_IE_GET( ), request.filter_service( ), socks.authenticate( ), socks.authenticate.force( )

•

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

deny.unauthorized( ) The deny.unauthorized property instructs the SG appliance to issue a challenge (401 Unauthorized or 407 Proxy authorization required). This indicates to the client that the resource cannot be accessed with their current identity, but might be accessible using a different identity. The browsers typically respond by bringing up a dialog box so the user can change their identity. (The details string appears in the challenge page so that if the user cancels, there is some additional help information provided). Typically, use deny( ) if the policy rule forbids everyone access, but use deny.unauthorized if the policy rule forbids only certain people. Syntax deny.unauthorized deny.unauthorized(details)

where details is a string defining a message to be displayed to the user. The details string may contain CPL substitution variables. Discussion If current policy contains rules that use the authenticate() or authenticate.force( ) properties, the deny.unauthorized( ) property is equivalent to exception(authorization_failed). If policy does not contain any rules that require authentication, deny.unauthorized( ) is equivalent to exception(policy_denied). The identity of the exception being returned can be tested in an layer using exception.id=. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP transactions. For other protocols, the property is the equivalent to deny( ).

See Also •

Conditions: exception.id=

•

Properties: deny( ), exception( ), force_deny( ), force_exception( )

•

Appendix D: "CPL Substitutions".

251

Volume 10: Content Policy Language Guide

detect_protocol( ) Determines whether to invoke protocol recognition, and which protocols should be recognized. When one of the specified protocols is detected, the connection will be handled by the appropriate application proxy. Syntax detect_protocol(all|none) detect_protocol(protocol_list) detect_protocol.protocol(yes|no) detect_protocol[protocol_list](yes|no)

where: ❐

protocol_list is a comma separated list of protocol

❐

protocol is one of http, bittorrent, edonkey, fasttrack, gnutella, or epmapper

The default value is all. Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS, HTTP and TCP Tunnel transactions .

Example detect_protocol(gnutella)

See Also •

252

Properties: force_protocol( )

Chapter 4: Property Reference

direct( ) Used to prevent requests from being forwarded to a parent proxy or SOCKS server, when the SG appliance is configured to forward requests. When set to yes, layer policy is not evaluated for the transaction. Syntax direct(yes|no)

The default value is no, which allows request forwarding. Layer and Transaction Notes •

Use in and layers.

•

Does not apply to FTP over HTTP or transparent FTP transactions.

See Also •

Properties: bypass_cache( ), dynamic_bypass( ), force_cache(), forward( ), reflect_ip( )

253

Volume 10: Content Policy Language Guide

dns.respond( ) Terminates a proxied DNS query with the given DNS RCODE. Syntax dns.respond(noerror|formerr|servfail|nxdomain|notimp|refused|yxdomain|yxrrset|n xrrset|notauth|notzone|numeric range from 0 to 15)

Layer and Transaction Notes •

Use in layers.

•

Applies to DNS proxy transactions .

Example This example implements the following policy: 1.

DNS queries using QTYPEs other than “PTR” or “A” are considered “not implemented.”

2.

Any DNS query for a host ending in example.com is refused. ; 1 dns.request.type=!(A||PTR) dns.respond(notimp) ; 2 dns.request.name=.example.com dns.respond(refused)

254

Chapter 4: Property Reference

dns.respond.a( ) Terminates a proxied DNS query of type 'A' with the given response. Syntax dns.respond.a(ip-address[,ip-address]*[,ttl]|hostname[,ip-address]*[,ttl]))

Layer and Transaction Notes •

Use in layers.

•

Applies to DNS-proxy transactions.

Example This example implements the following policies: 1.

DNS queries for host1.example.com are resolved to 10.10.10.1 with a TTL of 7200 seconds.

2.

DNS queries for host2.example.com are resolved to 10.10.10.2 with a CNAME of “myhost.example.com” and a TTL of 9600 seconds. ; 1 dns.request.name=host1.example.com dns.respond.a(10.10.10.1, 7200) ; 2 dns.request.name=host2.example.com \ dns.respond.a(myhost.example.com, 10.10.10.2, 9600)

255

Volume 10: Content Policy Language Guide

dns.respond.ptr( ) Terminates a proxied DNS query of type “PTR” with the given response. Syntax dns.respond.ptr(hostname[,ttl])

Layer and Transaction Notes •

Use in layers.

•

Applies to DNS-proxy transactions.

Example This example implements the following policies: 1.

Reverse DNS queries for 10.10.10.1 are resolved to host1.example.com with a TTL of 7200 seconds.

2.

Reverse DNS queries for 10.10.10.2 are resolved to host2.example.com with the default TTL. ; 1 dns.request.address=10.10.10.1 dns.respond.ptr(host1.example.com, 7200) ; 2 dns.request.address=10.10.10.2 dns.respond.ptr(host2.example.com)

256

Chapter 4: Property Reference

dynamic_bypass( ) Used to indicate that a particular transparent request is not to be handled by the proxy, but instead be subjected to SG appliance dynamic bypass methodology. The dynamic_bypass(yes) property takes precedence over authenticate(); however, a committed denial takes precedence over dynamic_bypass(yes). Syntax dynamic_bypass(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to transparent HTTP transactions only.

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), cookie_sensitive( ), delete_on_abandonment( ), direct( ), force_cache(), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

257

Volume 10: Content Policy Language Guide

exception( ) Selects a built-in or user-defined response to be returned to the user. The exception( ) property is overridden by allow or deny( ). To set an exception that cannot be overridden by allow, use force_exception( ). The identity of the exception being returned can be tested in an layer using exception.id=.

Note:

When the exception response selected would have a Content-Length of 512 or fewer bytes, Internet Explorer may substitute “friendly” error messages. To prevent this behavior use exception.autopad(yes).

Syntax exception(exception_id, details, string_name)

where: •

exception_id—Either the name of a built-in exception (refer to Chapter 15: “Advanced Policy”

in the Blue Coat Systems Configuration and Management Guide for the list of built-in exceptions), or a name of the form user_defined.exception_id that refers to a user-defined exception page. •

details—A text string that is substituted for $(exception.details) within the selected exception.

•

string_name—A string name, as defined by define string, that is substituted for $(exception.details) within the selected exception. The named string overrides the format

field of the exception. The string can contain substitutions. Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to all transactions.

See Also •

Conditions: exception.id=

•

Properties: allow, deny( ), deny.unauthorized( ), exception.autopad( ), force_deny( ), force_exception( )

•

258

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

exception.autopad( ) Pad an HTTP exception response by including trailing white space in the response body so that Content-Length is at least 513 characters. A setting of yes is used to prevent Internet Explorer from substituting friendly error messages in place of the exception response being returned, when the exception as configured would have a Content-Length of less than 512 characters. Syntax exception.autopad(yes|no)

where: •

yes—Enables auto-padding.

•

no—Disables auto-padding.

The default value is yes. Layer and Transaction Notes •

Use in layers only.

•

Applies to HTTP transactions.

See Also •

Conditions: exception.id=

•

Properties: exception( ), force_exception

259

Volume 10: Content Policy Language Guide

force_cache( ) Used to force caching of HTTP responses that would otherwise be considered uncacheable. The default HTTP caching behavior is restored using force_cache(no). The value of the force_cache( ) property is ignored unless all of the following property settings are in effect: bypass_cache(no), cache(yes), cookie_sensitive(no), and ua_sensitive(no). Syntax force_cache(all|no)

The default value is no. Layer and Transaction Notes •

Use only in layers.

•

Applies to proxy transactions, which execute both and layers.

Example ; Ensure objects at this URL are cached. url=http://www.example.com/docs force_cache(all)

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), cookie_sensitive( ), dynamic_bypass( ), pipeline( ), refresh( ), ttl( ), ua_sensitive( )

260

Chapter 4: Property Reference

force_deny( ) The force_deny( ) property is similar to deny( ) except that it: •

Cannot be overridden by an allow.

•

Overrides any pending termination (that is, if a deny( ) has already been matched, and a force_deny or force_exception is subsequently matched, the latter commits.

•

Commits immediately (that is, the first one matched applies).

The force_deny( ) property is equivalent to force_exception(policy_denied). Syntax force_deny force_deny(details) where details is a text string that will be substituted for $(exception.details) within the policy_denied exception. The details string may also contain CPL substitution patterns.

Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to all transactions.

See Also •

Conditions: exception.id=

•

Properties: deny(), force_exception()

•

Appendix D: "CPL Substitutions".

261

Volume 10: Content Policy Language Guide

force_exception( ) The force_exception( ) property is similar to exception except that it: •

Cannot be overridden by an allow.

•

Overrides any pending termination (that is, if a deny( ) has already been matched, and a force_deny( ) or force_exception( ) is subsequently matched, the latter commits.

•

Commits immediately (that is, the first one matched applies).

Syntax force_exception(exception_id) force_exception(details) where details is a text string that will be substituted for $(exception.details) within the specified exception. The details string may also contain CPL substitution patterns.

Layer and Transaction Notes •

Use in , , , and layers.

•

Applies to all transactions.

See Also

262

•

Conditions: exception.id=

•

Properties: deny( ), exception( ), exception.autopad( ), force_deny( )

•

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

force_patience_page( ) This property provides control over the application of the default patience page logic. This syntax has been deprecated. Use response.icap_feedback.force_interactive(). Syntax force_patience_page( yes|no ) force_patience_page.reason( yes|no ) force_patience_page( reason, ... ) force_patience_page[ reason, ...]( yes|no )

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: HTTP proxy transactions

Example Sample usage: force_patience_page(user-agent)

See Also •

Properties: response.icap_feedback.force_interactive( )

263

Volume 10: Content Policy Language Guide

force_protocol( ) Specifies that the client connection should be treated as a particular protocol type. The connection will be handled by the appropriate application proxy. Syntax force_protocol(no|http|bittorrent|edonkey|gnutella|epmapper)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS, HTTP and TCP Tunnel transactions.

Example force_protocol(gnutella)

See Also •

264

Properties: detect_protocol( )

Chapter 4: Property Reference

forward( ) Determines forwarding behavior. There is a box-wide configuration setting (config>forwarding>sequence) for the default forwarding failover sequence. The forward( ) property is used to override the default forwarding failover sequence with a specific list of host and/or group aliases. The list of aliases might contain the special token default, which expands to include the default forward failover sequence defined in configuration. Duplication is allowed in the specified alias list only in the case where a host or group named in the default failover sequence is also named explicitly in the alias_list. In addition, there is a box-wide configuration setting (config>forwarding>failure-mode) for the default forward failure mode. The forward.fail_open( ) property overrides the configured default. Syntax forward(alias_list|no)

where: •

alias_list—Forward this request through the specified alias list, which might refer to both forward hosts and groups. The SG appliance attempts to forward this request through the specified hosts or groups, in the order specified by the list. It proceeds to the next alias as necessary when the current host or group is down, as determined by health checks.

•

no—Do not forward this request through a forwarding host. A SOCKS gateway or ICP host may still be used, depending on those properties. If neither are set, the request is sent directly to the origin server. Note that no overrides the default sequence defined in configuration.

The default value is default, as the only token in the alias_list. Layer and Transaction Notes •

Use only in layers.

•

Applies to all transactions except administrator, instant messaging, and SOCKS.

See Also •

Properties: direct( ), dynamic_bypass( ), icp( ), reflect_ip( ), refresh( ), socks_gateway( ), socks_gateway.fail_open( ), streaming.transport( )

265

Volume 10: Content Policy Language Guide

forward.fail_open( ) Controls whether the SG appliance terminates or continues to process the request if the specified forwarding host or any designated backup or default cannot be contacted. There is a box-wide configuration setting (config>forwarding>failure-mode) for the default forward failure mode. The forward.fail_open( ) property overrides the configured default. Syntax forward.fail_open(yes|no)

where: •

yes—Continue to process the request if the specified forwarding host or any designated backup or default cannot be contacted. This may result in the request being sent through a SOCKS gateway or ICP, or may result in the request going directly to the origin server.

•

no—Terminate the request if the specified forwarding host or any designated backup or default

cannot be contacted. The default value is no. Layer and Transaction Notes •

Use only in layers.

•

Applies to all transactions except administrator, instant messaging, and SOCKS.

See Also •

266

Properties: bypass_cache( ), dynamic_bypass( ), forward( ), reflect_ip( ), socks_gateway( ), socks_gateway.fail_open( )

Chapter 4: Property Reference

ftp.match_client_data_ip( ) Sets whether to make a data connection to the client with the control connection's IP address or the local physical IP address. Syntax ftp.match_client_data_ip(yes|no)

where: •

yes: make the data connection using the control connection's IP address.

•

no: make the data connection using the local physical IP address.

Layer and Transaction Notes •

Use in layers.

•

Applies to FTP proxy transactions.

Example ftp.match_client_data_ip(yes)

267

Volume 10: Content Policy Language Guide

ftp.match_server_data_ip( ) Sets whether to make a data connection to the server with the control connection's IP address or the local physical IP address. Syntax ftp.match_server_data_ip(yes|no)

where: •

yes: make the data connection using the control connection's IP address

•

no: make the data connection using the local physical IP address

Layer and Transaction Notes •

Use in layers.

•

Applies to FTP proxy transactions.

Example ftp.match_server_data_ip(yes)

268

Chapter 4: Property Reference

ftp.server_connection( ) Determines when the control connection to the server is established. If set to deferred, the proxy defers establishing the control connection to the server. Syntax ftp.server_connection(deferred|immediate)

The default value is immediate. Layer and Transaction Notes •

Use in layers.

•

Applies to FTP transactions.

See Also •

Properties: ftp.server_data( ), ftp.transport( )

269

Volume 10: Content Policy Language Guide

ftp.server_data( ) Determines the type of data connection to be used with this FTP transaction. Syntax ftp.server_data(auto|passive|port)

where: •

auto—First attempt a PASV data connection. If this fails, switch to PORT.

•

passive—Use a PASV data connection. PASV data connections are not allowed by some

firewalls. •

port—Use a PORT data connection. FTP servers can be configured to not support PORT connections.

Layer and Transaction Notes •

Use in layers.

•

Applies to FTP transactions.

See Also •

270

Properties: ftp.server_connection( ), ftp.transport( )

Chapter 4: Property Reference

ftp.transport( ) Determines the upstream transport mechanism. This setting is not definitive. It depends on the capabilities of the selected forwarding host. Syntax ftp_transport(auto|ftp|http)

The default value is auto. where: •

auto—Use the default transport for the upstream connection, as determined by the originating transport and the capabilities of any selected forwarding host.

•

ftp—Use FTP as the upstream transport mechanism.

•

http—Use HTTP as the upstream transport mechanism.

Layer and Transaction Notes •

Use in layers.

•

Applies only to WebFTP transactions where the client uses the HTTP protocol to request a URL with an ftp: schema.

See Also •

Properties: ftp.server_connection( ), ftp.server_data( )

271

Volume 10: Content Policy Language Guide

ftp.welcome_banner( ) Sets the welcome banner for a proxied FTP transaction. Syntax ftp.welcome_banner(default | no | substitution-string)

where: ❐

default means use the setting on the SG appliance

❐

no means do not return a welcome banner

Layer and Transaction Notes •

Use in layers.

•

Applies to FTP proxy transactions.

Example This example implements the following policies: 1.

All requests from HR_subnet get the FTP welcome banner “client's address: Welcome to this appliance”

2.

All requests from ENG_subnet get the default FTP welcome banner.

3.

All other requests get no FTP welcome banner. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end ; 1 client.address=HR_subnet \ ftp.welcome_banner("$(client.address): Welcome to $(appliance.name)") ; 2 client.address=ENG_subnet ftp.welcome_banner(default) ; 3 ftp.welcome_banner(no)

See Also •

272

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

http.allow_compression( ) Determines whether the HTTP Proxy is allowed to compress data in transit. Syntax http.allow_compression(yes|no)

The default value is no. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline)

Example http.allow_compression(yes)

See Also •

Properties: http.allow_decompression( )

273

Volume 10: Content Policy Language Guide

http.allow_decompression( ) Determines whether the HTTP proxy is allowed to decompress data in transit. Syntax http.allow_decompression(yes|no)

The default value is no. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline).

Example http.allow_decompression(yes)

See Also •

274

Properties: http.allow_compression( )

Chapter 4: Property Reference

http.client.allow_encoding( ) Determines which encodings are allowed in the response sent to the client. Syntax http.client.allow_encoding(encoding_or_client_list) http.client.allow_encoding.encoding(yes|no) http.client.allow_encoding[encoding_list](yes|no)

where: ❐

encoding_or_client_list is a comma separated list of encoding or client_list

❐

encoding_list is a comma separated list of encoding

❐

encoding is one of gzip, or deflate

❐

client is replaced by the list of encodings specified in the client's request

The default value is client_list. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline).

Example http.client.allow_encoding(gzip)

See Also •

Properties: http.server.accept_encoding( )

275

Volume 10: Content Policy Language Guide

http.client.persistence( ) Controls persistence of the connection to the HTTP client. If set to no, after the current transaction is complete, the client connection will be dropped. Syntax http.client.persistence(yes|no)

The default value is taken from HTTP configuration, which is "yes" by default. Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example This property allows control of the persistence of individual client connections based on any policy conditions available in the or layers. The following example shows the property used to disable persistent connections for clients from a specified subnet going to a particular host and retrieving a particular content type in the response. client.address=10.10.167.0/8 \ url.host=my_host.my_business.com \ response.header.Content-Type="text/html" \ http.client.persistence(no)

See Also •

276

Properties: http.server.persistence( )

Chapter 4: Property Reference

http.client.recv.timeout( ) Sets the socket timeout for receiving bytes from the client. Syntax http.client.recv.timeout(auto | recv-timeout)

Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

Example This example implements the following policies: 1.

Requests from HR_subnet get a receive timeout of 200 seconds.

2.

Any request heading to a host that ends in example.com gets a receive timeout of 20 seconds.

3.

All refresh traffic except that for example.com hosts gets a receive timeout of 300 seconds. define subnet HR_subnet 10.10.0.0/16 end ; 1 client.address=HR_subnet http.client.recv.timeout(200) ; 2 server_url.domain=example.com http.server.recv.timeout(20) \ http.refresh.recv.timeout(auto) ; 3 http.refresh.recv.timeout(300)

277

Volume 10: Content Policy Language Guide

http.compression_level( ) Determines the compression level used by HTTP Proxy when http.allow_compression is true. Syntax http.compression_level(low|medium|high)

The default value is low. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline).

Example http.compression_level(medium)

See Also •

278

Properties: http.allow_compression( )

Chapter 4: Property Reference

http.force_ntlm_for_server_auth( ) http.force_ntlm_for_server_auth( ) is a fine grained control of the global configuration that can be set or unset through CLI commands http force-ntlm or http no force-ntlm.

The force_ntlm commands are used to work around the Microsoft limitation that Internet Explorer does not allow origin content server (OCS) NTLM authentication through a SG appliance when explicitly proxied. To correct this problem, Blue Coat has added a "Proxy-Support: Session-based-authentication" header that is sent by default when the SG appliance receives a 401 authentication challenge when the client connection is an explicit proxy connection. For older browsers or if both the SG appliance and the OCS do NTLM authentication, the Proxy-Support header might not work. In this case, you can disable the header and instead use the CLI command http force-ntlm or the http.force_ntlm_for_server_auth( ) property, which converts the 401-type server authentication challenge to a 407-type proxy authentication challenge, supported by Internet Explorer. The SG appliance also converts the resulting Proxy-Authentication headers in client requests to standard standard server authorization headers, which allows an origin server NTLM authentication challenge to pass through when Internet Explorer is explicitly proxied through the SG appliance. Syntax http.force_ntlm_for_server_auth(yes|no)

This property overrides the default specified in configuration. where: •

yes—Allows Internet Explorer clients explicitly proxied through a SG appliance to

participate in NTLM authentication. •

no—The Proxy-Support: Session-based-authentication header is used to respond to 401

authentication-type challenges. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

Example This example implements the following policies: •

All clients from the HR_subnet have force-ntlm turned off.

•

Requests for hosts in the example.com domain have force-ntlm turned on.

•

Requests for all other hosts have force-ntlm turned off. define subnet HR_subnet 10.10.0.0/16 end

279

Volume 10: Content Policy Language Guide

; 1 client.address=HR_subnet http.force_ntlm_for_server_auth(no) ; 2 url.domain=example.com http.force_ntlm_for_server_auth(yes) ; 3 http.force_ntlm_for_server_auth(no)10.10.0.0/16 end

280

Chapter 4: Property Reference

http.refresh.recv.timeout( ) Sets the socket timeout for receiving bytes from the upstream host when performing a refresh. Syntax http.refresh.recv.timeout(auto| recv-timeout)

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP refresh transactions.

Example This example implements the following policies: 1.

Requests from HR_subnet get a receive timeout of 200 seconds.

2.

Any request heading to a host that ends in example.com gets a receive timeout of 20 seconds.

3.

All refresh traffic except that for example.com hosts gets a receive timeout of 300 seconds. define subnet HR_subnet 10.10.0.0/16 end ; 1 client.address=HR_subnet http.client.recv.timeout(200) ; 2 server_url.domain=example.com http.server.recv.timeout(20) \ http.refresh.recv.timeout(auto) ; 3 http.refresh.recv.timeout(300)

281

Volume 10: Content Policy Language Guide

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. Syntax http.request.version(1.0|1.1)

The default is taken from the CLI configuration setting http version, which can be set to either 1.0 or 1.1. Changing this value in the CLI changes the default for both http.request.version( ) and http.response.version( ). Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP transactions.

See Also

282

•

Conditions: http.request.version=

•

Properties: http.response.version( )

Chapter 4: Property Reference

http.response.parse_meta_tag.Cache-Control( ) Controls whether the 'Cache-Control' META Tag is parsed in an HTML response body. Syntax http.response.parse_meta_tag.Cache-Control(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions, HTTP refresh transactions, and HTTP pipeline transactions.

Example http.response.parse_meta_tag.Cache-Control(yes)

283

Volume 10: Content Policy Language Guide

http.response.parse_meta_tag.Expires( ) Controls whether the 'Expires' META Tag is parsed in an HTML response body. Syntax http.response.parse_meta_tag.Expires(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions, HTTP refresh transactions, and HTTP pipeline transactions.

Example http.response.parse_meta_tag.Expires(yes)

284

Chapter 4: Property Reference

http.response.parse_meta_tag.pragma-no-cache( ) Controls whether the 'Pragma: no-cache' META Tag is parsed in an HTML response body. Syntax http.response.parse_meta_tag.pragma-no-cache(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions, HTTP refresh transactions, and HTTP pipeline transactions

Example http.response.parse_meta_tag.pragma-no-cache(yes)

285

Volume 10: Content Policy Language Guide

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. Syntax http.response.version(1.0|1.1)

The default is taken from the CLI configuration setting http version, which can be set to either 1.0 or 1.1. Changing this value in the CLI changes the default for both http.request.version( ) and http.response.version( ). Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP transactions.

See Also

286

•

Conditions: http.response.version=

•

Properties: http.request.version( )

Chapter 4: Property Reference

http.server.accept_encoding( ) Determines which encodings are allowed in an upstream request. Syntax http.server.accept_encoding(all) http.server.accept_encoding(encoding_or_client_list) http.server.accept_encoding.encoding(yes|no) http.server.accept_encoding[encoding_list](yes|no)

where: ❐

encoding_or_client_list is a comma separated list of encoding or client

❐

encoding_list is a comma separated list of encoding

❐

encoding is one of gzip, deflate or identity

❐

all represents all encodings supported by the client or by the SG appliance (currently gzip, deflate and identity)

❐

client will be replaced by the list of encodings specified in the client's request

The default value for requests from a client is client. For client-less transactions, the default with a valid compression license is all, otherwise identity. Layer and Transaction Notes •

Use in and layers.

•

Applies to All HTTP transactions (proxy, refresh, pipeline).

Example This example illustrates how the property is used to determine the accepted encodings. The conditions used are assumed to be defined elsewhere). ; accept only the identity encoding condition=condition1 http.server.accept_encoding(identity) ; accept only what the client allows condition=condition2 http.server.accept_encoding(client) ; accept all encodings supported by either the client or the SG appliance http.server.accept_encoding(all);

See Also •

Properties: http.client.allow_encoding( ), http.server.accept_encoding.allow_unknown( )

287

Volume 10: Content Policy Language Guide

http.server.accept_encoding.allow_unknown() Determines whether or not unknown encodings in the client's request are allowed. Syntax http.server.accept_encoding.allow_unknown(yes|no)

The default value with a valid compression license is no, otherwise yes. Layer and Transaction Notes •

Use in and layers.

•

Applies to All HTTP transactions (proxy, refresh, pipeline).

Example This example allows only encodings supported by the SG appliance. http.server.accept_encoding(all) http.server.accept_encoding.allow_unknown(no)

See Also •

288

Properties: http.server.accept_encoding( )

Chapter 4: Property Reference

http.server.connect_attempts( ) Set the number of attempts to connect performed per-address when connecting to the upstream host. Syntax http.server.connect_attempts(number from 1 to 10)

Layer and Transaction Notes •

Use in layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline).

Example http.server.connect_attempts(7)

289

Volume 10: Content Policy Language Guide

http.server.persistence( ) Controls persistence of the connection to the HTTP server. Syntax http.server.persistence(yes|no)

The default value is taken from HTTP configuration, which is "yes" by default. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline).

Example This property allows control of the persistence of individual server connections based on any request based conditions available in the layer, or any request or client based conditions in a layer. The following example shows the property used to disable persistent connections to a particular host. server_url.host=my_host.my_business.com \ http.server.persistence(no)

See Also •

290

Properties: http.client.persistence(

)

Chapter 4: Property Reference

http.server.recv.timeout( ) Sets the socket timeout for receiving bytes from the upstream host. Syntax http.server.recv.timeout(auto | recv-timeout)

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions, HTTP pipeline transactions.

Example This example implements the following policies: 1.

Requests from HR_subnet get a receive timeout of 200 seconds

2.

Any request heading to a host that ends in example.com gets a receive timeout of 20 seconds

3.

All refresh traffic except that for example.com hosts gets a receive timeout of 300 seconds define subnet HR_subnet 10.10.0.0/16 end ; 1 client.address=HR_subnet http.client.recv.timeout(200) ; 2 server_url.domain=example.com http.server.recv.timeout(20) \ http.refresh.recv.timeout(auto) ; 3 http.refresh.recv.timeout(300)

291

Volume 10: Content Policy Language Guide

icp( ) Determines whether to consult ICP when forwarding requests. Any forwarding host or SOCKS gateway identified as an upstream target takes precedence over consulting ICP. Syntax icp(yes|no)

The default is yes if ICP hosts are configured, no otherwise. where: •

yes—Consult ICP unless forward( ) or socks_gateway( ) properties are set. If no ICP hosts are configured, yes has no effect.

•

no—Do not consult ICP hosts, even if configured.

Layer and Transaction Notes •

Use in layers.

•

Applies to all but SOCKS transactions.

See Also •

292

Properties: direct( ), forward( ), reflect_ip( ), socks_gateway( )

Chapter 4: Property Reference

im.block_encryption( ) Prevents the encryption of AOL IM messages by modifying messages during IM login time. Syntax im.block_encryption(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to AOL instant messaging transactions.

Example This example implements the following policy: •

Turn on block encryption for HR_subnet define subnet HR_subnet 10.10.0.0/16 end client.address=HR_subnet im.block_encryption(yes)

293

Volume 10: Content Policy Language Guide

im.reflect( ) Sets whether IM reflection should be attempted. Syntax im.reflect(yes|no)

Layer and Transaction Notes •

Use in layers.

•

Applies to instant messaging transactions.

Example im.reflect(yes)

294

Chapter 4: Property Reference

im.strip_attachments( ) Determines whether attachments are stripped from instant messages. If set to yes, attachments are stripped from instant messages. Syntax im.strip_attachments(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to instant messaging transactions.

See Also •

Conditions: im.buddy_id=, im.chat_room.conference=, im.chat_room.id=, im.chat_room.invite_only=, im.chat_room.type=, im.chat_room.member=, im.chat_room.voice_enabled=, im.file.extension=, im.file.name=, im.file.path=, im.file.size=, im.message.route=, im.message.size=, im.message.text=, im.message.type=, im.method=, im.user_id=

295

Volume 10: Content Policy Language Guide

im.transport( ) Sets the type of upstream connection to make for IM traffic. Syntax im.transport(native|http|auto)

Layer and Transaction Notes •

Use in layers.

•

Applies to instant messaging transactions.

Example im.transport(native)

296

Chapter 4: Property Reference

integrate_new_hosts( ) Determines whether to add new host addresses to health checks and load balancing. Syntax integrate_new_hosts(yes|no)

The default is no. If it is set to yes, any new host addresses encountered during DNS resolution of forwarding hosts are added to health checks and load balancing. Layer and Transaction Notes •

Use in layers.

•

Applies to everything but SOCKS and administrator transactions.

See Also •

Properties: forward( )

297

Volume 10: Content Policy Language Guide

limit_bandwidth( ) Assigns the bandwidth used in the specified traffic flows to the named bandwidth class, as defined in configuration. The bandwidth class determines the minimum bandwidth guarantee, maximum bandwidth allowed and relative priority. Syntax limit_bandwidth.client.inbound(no|bandwidth_class) limit_bandwidth.client.outbound(no|bandwidth_class) limit_bandwidth.server.inbound(no|bandwidth_class) limit_bandwidth.server.outbound(no|bandwidth_class)

where: no indicates that the flow is unregulated bandwidth_class is a bandwidth class name defined in configuration.

The default value is no. Layer and Transaction Notes •

Use in all layers.

•

Applies to all transactions.

Example limit_bandwidth(no)

298

Chapter 4: Property Reference

log.rewrite.field-id( ) The log.rewrite.field-id property controls rewrites of a specific log field in one or more access logs. Individual access logs are referenced by the name given in configuration. Configuration also determines the format of the each log. For more information on logging, refer to Chapter 19: “Access Logging” in the Blue Coat Systems Configuration and Management Guide. Syntax log.rewrite.field-id(“substitution”|no) log.rewrite.field-id[log_name_list](“substitution”|no)

where: •

field-id—Specifies the log field to rewrite. Some field-ids have embedded parentheses, for example cs(User-agent). These field-ids must be enclosed in quotes. There are two choices for quoting, either of which are accepted by the CPL compiler: log.rewrite."cs(User-agent)”(...) “log.rewrite.cs(User-agent)(...)”

Either single or double quotes may be used. •

log_name_list—A comma separated list of configured access logs, of the form:

•

log_name_1, log_name_2, ...

•

substitution—A quoted string containing replacement text for the field. The

substitution string can contain CPL substitution variables. •

no—Cancels any previous substitution for this log field.

Discussion Each of the syntax variants has a different role in specifying the rewrites for the access log fields used to record the transaction: •

log.rewrite.field-id( ) specifies a rewrite of the field_id field in all access logs selected for

this transaction. •

log.rewrite.field-id[log_name_list]( ) specifies a rewrite of the field_id field in all access logs named in log_name_list. The field_id field in any logs not named in the list is unaffected.

Layer and Transaction Notes •

Use in all layers.

•

Applies to all proxy transactions.

See Also •

Properties: access_log( ), log.suppress.field-id()

•

Appendix D: "CPL Substitutions".

299

Volume 10: Content Policy Language Guide

log.suppress.field-id( ) The log.suppress.field-id( ) property controls suppression of the specified field-id in one or more access logs. Individual access logs are referenced by the name given in configuration. Configuration also determines the format of the each log. For more information on logging, refer to Volume 9: Access Logging. Syntax log.suppress.field-id(yes|no) log.suppress.field-id[log_name_list](yes|no)

where: •

field-id—Specifies the log field to suppress. Some field-ids have embedded parentheses, for example cs(User-agent). These field-ids must be enclosed in quotes. There are two choices for quoting, either of which are accepted by the CPL compiler: log.suppress."cs(User-agent)"(yes|no) "log.suppress.cs(User-agent)(yes|no)"

Either single or double quotes may be used. •

log_name_list—A comma separated list of configured access logs, of the form:

•

log_name_1, log_name_2, ...

•

yes— Suppresses the specified field-id

•

no—Turns suppression off for the specified field-id

Discussion Each of the syntax variants has a different role in suppressing the access log fields used to record the transaction: •

log.suppress.field-id( ) controls suppression of the field_id field in all access logs selected

for this transaction. •

log.suppress.field-id[log_name_list]( ) controls suppression of the field_id field in all access logs named in log_name_list. The field_id field in any logs not named in the list is unaffected.

Layer and Transaction Notes •

Use in all layers.

•

Applies to all proxy transactions.

See Also •

300

Properties: access_log( ), log.rewrite.field-id( )

Chapter 4: Property Reference

max_bitrate( ) Enforces upper limits on the instantaneous bandwidth of the current streaming transaction. This policy is enforced during initial connection setup. If the client requests a higher bit rate than allowed by policy, the request is denied. Note:

Under certain network conditions, a client may receive a stream that temporarily exceeds the specified bit rate.

Syntax max_bitrate(bitrate|no)

The default value is no. where: •

bitrate—Maximum bit rate allowed. Specify using an integer, in bits, kilobits (1000x), or megabits (1,000,000x), as follows: integer | integerk | integerm.

•

no—Allows any bitrate.

Layer and Transaction Notes •

Use in and layers.

•

Applies to streaming transactions.

Example ; Client bit rate for streaming media cannot exceed 56 kilobits. max_bitrate(56k)

See Also •

Conditions: bitrate=, live=, streaming.content=

301

Volume 10: Content Policy Language Guide

never_refresh_before_expiry( ) The never_refresh_before_expiry( ) property is similar to the CLI command: SGOS#(config) http strict-expiration refresh

except that it provides per-transaction control to allow overriding the box-wide default set by the command. Syntax never_refresh_before_expiry(yes|no)

The default value is taken from configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions.

See Also • •

Properties: never_serve_after_expiry( ), remove_IMS_from_GET( ), remove_PNC_from_GET( ), remove_reload_from_IE_GET( ) Blue Coat Systems Command Line Interface Reference for information on the http strict-expiration command.

302

Chapter 4: Property Reference

never_serve_after_expiry( ) The never_serve_after_expiry( ) property is similar to the CLI command: SGOS#(config) http strict-expiration serve

except that it provides per transaction control to allow overriding the box-wide default set by the command. Syntax never_serve_after_expiry(yes|no)

The default value is taken from configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions.

See Also •

Properties: always_verify(), never_refresh_before_expiry()

•

Volume 12: Command Line Interface Reference for information on the http strict-expiration command.

303

Volume 10: Content Policy Language Guide

patience_page( ) Controls whether or not a patience page can be served, and if so the delay bfore serving.

This syntax has been deprecated. •

For patience_page( no ) use response.icap_feedback.interactive( no )

•

For patience_page( delay ) use reponse.icap_feedback(

patience_page, delay ).

Syntax patience_page(no|delay)

The default value is taken from configuration. where: •

no—A patience page will not be served.

•

delay —number of seconds, in the range 5-65535 before a patience page is served if scanning is not complete.

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy.

•

Applies to: HTTP proxy transactions, FTP proxy transactions.

Example Sample usage: patience_page(5)

See Also •

Properties: response.icap_feedback( ), response.icap_feedback.interactive( ), response.icap_feedback.non_interactive( )

304

Chapter 4: Property Reference

pipeline( ) Determines whether an object embedded within an HTML container object is pipelined. Set to yes to force pipelining, or set to no to prevent the embedded object from being pipelined. Note that this property affects processing of the individual URLs embedded within a container object. It does not prevent parsing of the container object itself. If this property is used with a URL access condition, such as url.host=, each embedded object on a page is evaluated against that policy rule to determine pipelining behavior. For example, a rule that disallows pipelining for a particular host would still allow pipelining for images on the host's pages that come from other hosts. Note:

Pipelining might cause issues for upstream devices that are low in TCP resources. The best solution is to remove the bottleneck. A temporary solution might include fine-tuning the device and disabling pipelining.

Syntax pipeline(yes|no)

The default value is yes. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

305

Volume 10: Content Policy Language Guide

reflect_ip( ) Determines how the client IP address is presented to the origin server for proxied requests. Note:

The SG appliance must be in the routing path for the reflect_ip property to work properly.

Syntax reflect_ip(auto|no|client|vip|ip_address)

The default value is auto. where: •

auto—Might reflect the client IP address, based on a config setting for spoofing.

•

no—The appliance's IP address is used to originate upstream connections.

•

client—The client's IP address is used in initiating upstream connections.

•

vip—The appliance's VIP on which the client request arrived is used to originate

upstream traffic. •

ip_address—A specific IP address, which must be an address (either physical or virtual) belonging to the SG appliance. If not, at runtime this is converted to auto.

Layer and Transaction Notes •

Use in , , and layers.

•

Applies to proxy and DNS transactions.

Example ; For requests from a specific client, use the virtual IP address. client.address=10.1.198.0 reflect_ip(vip)

See Also •

306

Properties: forward( )

Chapter 4: Property Reference

refresh( ) Controls refreshing of requested objects. Set to no to prevent refreshing of the object if it is cached. Set to yes to allow the cache to behave normally. Syntax refresh(yes|no)

The default value is yes. Layer and Transaction Notes •

Use in layers.

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), cookie_sensitive( ), direct( ), force_cache( ), never_refresh_before_expiry( ), Never_serve_after_expiry( ), ttl( ), ua_sensitive( )

307

Volume 10: Content Policy Language Guide

remove_IMS_from_GET( ) The remove_IMS_from_GET( ) property is similar to the CLI command: SGOS#(config) http substitute if-modified-since

except that it provides per transaction control to allow overriding the box-wide default set by the command. Syntax remove_IMS_from_GET(yes|no)

The default value is taken from configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

See Also

308

•

Properties: never_refresh_before_expiry( ), never_serve_after_expiry( ), remove_PNC_from_GET( ), remove_reload_from_IE_GET( )

•

Volume 12: Command Line Interface Reference for information on the http substitute command.

Chapter 4: Property Reference

remove_PNC_from_GET( ) The remove_PNC_from_GET property is similar to the CLI command: SGOS#(config) http substitute pragma-no-cache

except that it provides per transaction control to allow overriding the box-wide default set by the command. Syntax remove_PNC_from_GET(yes|no)

The default value is taken from configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

See Also •

Properties: never_refresh_before_expiry(), never_serve_after_expiry( ), remove_IMS_from_GET( ), remove_reload_from_IE_GET( )

•

Blue Coat Systems Command Line Interface Reference for information on the http substitute command.

309

Volume 10: Content Policy Language Guide

remove_reload_from_IE_GET( ) The remove_reload_from_IE_GET( ) property is similar to the CLI command: SGOS#(config) http substitute ie-reload

except that it provides per transaction control to override the box-wide default set by the command. Syntax remove_reload_from_IE_GET(yes|no)

The default value is taken from configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP proxy transactions.

See Also

310

•

Properties: never_refresh_before_expiry( ), never_serve_after_expiry( ), remove_IMS_from_GET( ), remove_PNC_from_GET( )

•

Blue Coat Systems Command Line Interface Reference for information on the http substitute command.

Chapter 4: Property Reference

request.filter_service( ) Controls whether the request is processed by an external content filter service. The SG appliance currently supports Websense Enterprise Server external content filtering. Directing the request to an external content filter service does not affect policy based on categories determined through an on-box vendor or CPL category definitions. Categories determined by Websense Enterprise Server are not available to the category= condition, although they appear in access logs. Effectively, all policy based on the Websense determined categories must be implemented on the Websense server. Syntax request.filter_service(service_name[, fail_open|fail_closed]) request.filter_service(no)

The default values are no and fail_closed. where: •

service_name—A configured external content filter service that supports request

modification. Currently only Websense Enterprise Server is supported. On upgrade, the service name websense is automatically generated. •

fail_open—If service_name is unavailable, the request is processed and a response may

be delivered, subject to other policy. •

fail_closed—If the service_name is unavailable, the request is denied.

•

no—Prevents the request from being sent from the SG appliance to the external content

filter service. Layer and Transaction Notes •

Use in and layers.

•

Applies to FTP and HTTP transactions.

Example The following example directs requests to the Websense server, but allows processing to continue if the service in unavailable: request_filter_service(websense, fail_open)

The following policy establishes a general rule that all request are processed by the external filter service named filter. It then specifies some exceptions to this general rule in a later layer: ; All request are content-filtered by default request.filter_service( filter ) request.filter_servce(no) ; exceptions to content-filtering url.address=10.0.0.0/8 ; don't filter internal network client.address=10.1.2.3 ; don't filter this client

311

Volume 10: Content Policy Language Guide

See Also •

312

Blue Coat Systems Command Line Interface Reference for information on configuring Websense off-box services.

Chapter 4: Property Reference

request.icap_service( ) Determines whether a request from a client should be processed by an external ICAP service before going out. Typical applications include regulatory compliance monitoring and intellectual property protection. This property can specify a fail-over sequence of ICAP request modification services or service groups. The first healthy service in the sequence will be used to process the request. ICAP request processing can also be disabled using this property. Optionally, the failure mode can be specified to control behaviour if none of the listed services is healthy. Syntax request.icap_service( servicename_1, [servicename_2, ...,] [fail_open|fail_closed] ) request.icap_service( no )

Where: •

servicename-A configured ICAP service or service group that supports request modification.

•

fail_open-If none of the ICAP services listed is healthy, the request is sent out and a response

delivered to the client (subject to other policies). •

fail_closed-If none of the ICAP services listed is healthy, the request is denied. This is the default and need not be specified to be in effect.

•

no-Disables ICAP processing for this request.

The default value is fail_closed. Layer and Transaction Notes •

Valid layers: Cache, Proxy

•

Applies to: HTTP proxy transactions, FTP proxy transactions

Example This example implements the following Intellectual Property protection policy using IP scanners: All requests will be scanned except those going to internal servers. Requests coming from a special group of clients will be allowed out even if the request cannot be scanned. ; general rule - scan all requests ; some users can get out if the scanners are down group=trusted_users request.icap_service( IP_service, IP_backup_service, fail_open ) request.icap_service( IP_service, IP_backup_service ) ; default is fail_closed

; exception - no need to scan requests to internal servers

313

Volume 10: Content Policy Language Guide

condition=internal_servers request.icap_service( no )

See Also •

314

Properties: response.icap_service( )

Chapter 4: Property Reference

response.icap_feedback( ) Controls the type of feedback given to both interactive and non-interactive clients while response scanning is in progress, and the delay before any feedback delivery starts. This controls the feedback delivered to both interactive and non-interactive clients. However since patience pages are served only to interactive clients, response.icap_feedback( patience_page, delay )

is interpreted as: response.icap_feedback.interactive( patience_page, delay ) response.icap_feedback.non_interactive( no )

Administrators should be aware of the increased security risks associated with trickling. Syntax response.icap_feedback( patience_page[, patience_delay] ) response.icap_feedback( trickle_start|trickle_end[, trickle_delay] ) response.icap_feedback( no )

where: •

no prevents any bytes from being delivered to the client until scanning completes. This option has good

security characteristics, but the worst user experience. •

patience_page returns a patience page to an interactive client after patience_delay seconds if scanning has not completed within that time. No feedback is given to non_interactive clients.

This option has good security characteristics, and a reasonable user experience for interactive clients. •

trickle_start begins delivering bytes to the client after trickle_delay seconds if scanning has not

completed within that time. HTTP response headers are delivered at line speed. The response body is delivered to the client at the reduced (trickle) rate. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since all the data is delivered to the client at a reduced rate, this is somewhat more secure than trickle_end, but the user will see very little intermediate progress. •

trickle_end begins delivering bytes at line speed to the client after trickle_delay seconds if scanning has

not completed within that time. The last 16K bytes will be buffered by the appliance and trickling begins only when no more data is expected from the server. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since only the last part of the data is delivered to the client at a reduced rate, this is somewhat less secure than trickle_start, but the user will see immediate initial progress. •

patience_delay is the number of seconds before a patience page is delivered to the client. The allowed range is 5 to 65535. The default is 5.

315

Volume 10: Content Policy Language Guide

•

trickle_delay is the number of seconds before feedback to the client starts. The allowed range is 0 to 65535. The default is 5.

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: HTTP proxy transactions, FTP proxy transactions

Example The following example assumes that automated tools used within the organization can be distinguished through a "robots" condition, defined elsewhere in the policy. ; To prevent timeouts, robots get data trickled to them right away. condition = robots response.icap_feedback( trickle_start, 0 ) ; everyone else (presumably real users) get a patience page after 7 seconds response.icap_feedback( patience_page, 7 )

See Also •

Properties: response.icap_service( ), response.icap_feedback.interactive( ), response.icap_feedback.non_interactive( ), response.icap_feedback.force_interactive( )

316

Chapter 4: Property Reference

response.icap_feedback.force_interactive( ) Modifies the logic used to determine whether or not this HTTP transaction represents an opportunity to interact with the user. Different feedback can be returned to the client depending on whether or not the current transaction is judged to be interactive or non-interactive. For example, patience pages can only be delivered when the transaction is interactive. Logic built into the system makes the determination for each transaction. This property is used to override portions of that logic. This property cannot be used to override the following reasons to consider the transaction non-interactive: •

the request method is not 'GET'

•

the response is not '200 OK'

•

the server provides an unsolicited content encoding (one not requested by the ProxySG)

•

there is a 'Range' or 'If-Range' header in the request

Syntax response.icap_feedback.force_interactive( yes|no ) response.icap_feedback.force_interactive.reason( yes|no ) response.icap_feedback.force_interactive( reason, ... ) response.icap_feedback.force_interactive[ reason, ...]( yes|no )

where: •

reason -Takes one of the following values, corresponding to the overridable portions of the logic used to

determine whether or not interaction with a user is possible. ❐

user-agent overrides the decision to consider non-graphical browsers to be considered interactive.

Any User-Agent header string beginning with mozilla or opera are considered graphical. ❐

extension overrides the decision to consider requests for URLs with graphical file extensions or extensions indicating cascading sytlesheets, javascript, vbscript, vbx, or java applet or flash animation content as non-interactive.

❐

content-type overrides the decision to consider as non-interactive content similar to that listed under extension, but based on the Content-Type header of the HTTP response.

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: HTTP proxy transactions

Example The following example assumes that the organization has an interactive Mozilla-compatible browser that identifies itself with a custom User-Agent header. The policy overrides the default logic so that this user agent will be considered interactive.

317

Volume 10: Content Policy Language Guide

This form of the syntax is used so that this policy will not interfere with other policy making decisions about the content type or extension (for example whether a transaction requesting graphical content for example will be considered interactive.) request.header.User-Agent=brandedagent response.icap_feedback.force_interactive.user-agent(yes)

See Also •

Properties: response.icap_service( ), response.icap_feedback( ), response.icap_feedback.interactive( ), response.icap_feedback.non_interactive( )

318

Chapter 4: Property Reference

response.icap_feedback.interactive( ) Controls the type of feedback given to interactive clients while response scanning is in progress, and the delay before any feedback delivery starts. Administrators should be aware of the increased security risks associated with trickling. Syntax response.icap_feedback.interactive( patience_page[, patience_delay] ) response.icap_feedback.interactive( trickle_start|trickle_end[, trickle_delay] ) response.icap_feedback.interactive( no )

where: •

no prevents any bytes from being delivered to the client until scanning completes. This option has good

security characteristics, but the worst user experience. •

patience_page returns a patience page to an interactive client after patience_delay seconds if

scanning has not completed within that time. No feedback is given to non_interactive clients. This option has good security characteristics, and a reasonable user experience for interactive clients. •

trickle_start begins delivering bytes to the client after trickle_delay seconds if scanning has not

completed within that time. HTTP response headers are delivered at line speed. The response body is delivered to the client at the reduced (trickle) rate. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since all the data is delivered to the client at a reduced rate, this is somewhat more secure than trickle_end, but the user will see very little intermediate progress. •

trickle_end begins delivering bytes at line speed to the client after trickle_delay seconds if

scanning has not completed within that time. The last 16K bytes will be buffered by the appliance and trickling begins only when no more data is expected from the server. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since only the last part of the data is delivered to the client at a reduced rate, this is somewhat less secure than trickle_start, but the user will see immediate initial progress. •

patience_delay is the number of seconds before a patience page is delivered to the client. The allowed range is 5 to 65535. The default is 5.

•

trickle_delay is the number of seconds before feedback to the client starts. The allowed range is 0 to 65535. The default is 5.

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy

319

Volume 10: Content Policy Language Guide

•

Applies to: HTTP proxy transactions, FTP proxy transactions

Example The following sample policy serves patience pages to FTP clients if scanning has not completed within 3 seconds. Note that all FTP transactions are considered interactive. Interactive HTTP transactions will have the first portion of the data delivered at line speed, while the last part of the response will be trickled. No policy is specified for non-interactive clients. client.protocol=ftp response.icap_feedback.interactive( patience_page, 3 ) response.icap_feedback.interactive( trickle_end )

See Also •

Properties: response.icap_service( ), response.icap_feedback( ), response.icap_feedback.non_interactive( ), response.icap_feedback.force_interactive( )

320

Chapter 4: Property Reference

response.icap_feedback.non_interactive( ) Controls the type of feedback given to non-interactive clients while response scanning is in progress, and the delay before any feedback delivery starts. Administrators should be aware of the increased security risks associated with trickling. Syntax response.icap_feedback.non_interactive( trickle_start|trickle_end[, trickle_delay] ) response.icap_feedback.non_interactive( no )

where: •

no prevents any bytes from being delivered to the client until scanning completes. This option has

good security characteristics, but the worst user experience. •

trickle_start begins delivering bytes to the client after trickle_delay seconds if scanning has not

completed within that time. HTTP response headers are delivered at line speed. The response body is delivered to the client at the reduced (trickle) rate. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since all the data is delivered to the client at a reduced rate, this is somewhat more secure than trickle_end, but the user will see very little intermediate progress. •

trickle_end begins delivering bytes at line speed to the client after trickle_delay seconds if

scanning has not completed within that time. The last 16K bytes will be buffered by the appliance and trickling begins only when no more data is expected from the server. The last 12K bytes of the response will be held until the scanning result is known. Trickled data may contain a threat, and although the end of the response is corrupted to render it unusable, some client applications may still be vulnerable. Since only the last part of the data is delivered to the client at a reduced rate, this is somewhat less secure than trickle_start, but the user will see immediate initial progress. •

trickle_delay is the number of seconds before feedback to the client starts. The allowed range is 0 to 65535. The default is 5.

The default value is no. Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: HTTP proxy transactions

Example The following example uses authentication and group membership to set distinct feedback policies for known robots based on whether or not they might execute code from a corrupted package. It is assumed here that automated tools within the organization would provide distinct credentials that associates them with a "robots" group, and with other groups that distinguish risk. No policy is specified for interactive clients.

321

Volume 10: Content Policy Language Guide

authenticate( my_realm )

; the following applies only to members of the "robots" group group = robots ; high risk of executing code from a corrupted package ; -> no feedback group=high_execution_risk response.icap_feedback.non_interactive( no )

; low risk of executing code from a corrupted package ; -> trickle from the start with default delay group=low_execution_risk response.icap_feedback.non_interactive( trickle_start )

; no risk of executing code from a corrupted package ; -> trickle at the end, begin serving data immediately group=no_execution_risk response.icap_feedback.non_interactive( trickle_end, 0 )

See Also •

Properties: response.icap_service( ), response.icap_feedback( ), response.icap_feedback.interactive( ), response.icap_feedback.force_interactive( )

322

Chapter 4: Property Reference

response.icap_service( ) Determines whether a response to a client is first sent to an ICAP service before being given to the client. Depending on the ICAP service, the response may be allowed, denied, or altered. Typical applications include virus scanning. This property can specify a fail-over sequence of ICAP response modification services or service groups. The first healthy service in the sequence will be used to process the response. ICAP response processing can also be disabled using this property. Optionally, the failure mode can be specified to control behaviour if none of the listed services is healthy. Syntax response.icap_service( servicename_1, [servicename_2, ...,] [fail_open|fail_closed] ) response.icap_service( no )

where: •

servicename - A configured ICAP service or service group that supports response modification.

•

fail_open - If none of the ICAP services listed is healthy, the response is processed and delivered

to the client (subject to other policies). •

fail_closed - If none of the ICAP services listed is healthy, the transaction is denied. This is the

default and need not be specified to be in effect. •

no - Disables ICAP processing for this response.

The default value is fail_closed. Layer and Transaction Notes •

Valid layers: Cache

•

Applies to: All HTTP transactions (proxy, refresh, pipeline), FTP proxy transactions

Example This example implements the following Virus Scanning policy using ICAP response scanners: •

All responses will be scanned except those going to internal servers.

•

Responses coming from some business critical sites will be allowed even if the response cannot be scanned.

; general rule - scan all responses ; responses from some critical sites get through even if the scanners are down condition=critical_sites response.icap_service( VS_service, VS_backup_service, fail_open ) response.icap_service( IP_service, IP_backup_service ) ; default is fail_closed

; exception - no need to scan responses from internal servers

323

Volume 10: Content Policy Language Guide

condition=internal_servers response.icap_service( no )

See Also •

324

Properties: request.icap_service( ), patience_page( )

Chapter 4: Property Reference

response.raw_headers.max_count() Limit the number of response headers allowed in an HTTP response. The number of HTTP response headers will be limited to the given number. If this limit is exceeded, then the SG appliance will throw an "invalid_response" exception. A leading white space based header continuation will not be counted as a separate header. In other words, number here refers to headers, not response lines, and does not include response status line or end-of-header marker (blank line). The default value is 1,000. The minimum value is 0, and the maximum value is 10,000. Syntax response.raw_headers.max_count(unsigned-integer)

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example response.raw_headers.max_count(2500)

325

Volume 10: Content Policy Language Guide

response.raw_headers.max_length() Limit the amount of response header data allowed in an HTTP response. The total number of bytes of HTTP response header data is restricted to the given number. If this limit is exceeded, then the SG appliance will throw an "invalid_response" exception. The default value is 100,000. The minimum value is 0, and the maximum value is 1,000,000. Syntax response.raw_headers.max_length(unsigned-integer)

Layer and Transaction Notes •

Use in and layers.

•

Applies to HTTP proxy transactions.

Example response.raw_headers.max_length(250000)

326

Chapter 4: Property Reference

response.raw_headers.tolerate() Determines which deviations from the protocol specification will be tolerated when parsing the response headers. Syntax response.raw_headers.tolerate(none|continue)

where: •

none

•

continue

indicates that no deviations are tolerated

indicates that the response header parsing should tolerate a continuation line (white space) prior to the start of the first header

The default value is none. Layer and Transaction Notes •

Use in and layers.

•

Applies to all HTTP transactions (proxy, refresh, pipeline), HTTPS transactions.

Example This example illustrates how the property is used to specify which errors to tolerate. The conditions used are assumed to be defined elsewhere). ; Tolerate a continuation line prior to the first header, ; but only from a specified list of legacy servers. condition=legacy_server response.raw_headers.tolerate(continue) ; For all other servers, use strict response header parsing rules ; This is actually the default, so it doesn’t need to be specified response.raw_headers.tolerate(none)

See Also •

Properties: response.raw_headers.max_count( ), response.raw_headers.max_length( )

327

Volume 10: Content Policy Language Guide

server.certificate.validate() Determines whether server X.509 certificates will be verified during the establishment of SSL connections. Syntax server.certificate.validate(yes|no)

For HTTPS Reverse Proxy transactions, the default value is taken from the global setting established through the CLI http ssl-verify-server command, or in the configuration of a forwarding host used by the transaction. For HTTPS forward proxy and SSL tunnel transactions, the default is yes. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTPS forward and reverse proxy transactions, SSL tunnel transactions.

Example server.certificate.validate(yes)

See Also •

328

Properties: server.certificate.validate.ignore( )

Chapter 4: Property Reference

server.certificate.validate.check_revocation() Check SSL server certificates for revocation. Syntax server.certificate.validate.check_revocation(auto|ocsp|local|no)

where: •

auto the certificate will be checked through OCSP if available, otherwise it will be checked against locally installed revocation list

•

ocsp

•

local

•

no

checks the certificate through OCSP checks the certificate against the locally installed revocation list

the certificate will not be checked for revocation

The default value is auto. Layer and Transaction Notes •

Valid layers: SSL.

•

Applies to HTTPS forward and reverse proxy transactions, SSL tunnel transactions.

Example server.certificate.validate.check_revocation(local)

329

Volume 10: Content Policy Language Guide

server.certificate.validate.ignore() Ignore errors during server certificate validation. This property specifies which errors should be ignored while validating the server certificate during the setup of an SSL connection. Syntax server.certificate.validate.ignore.flag(yes|no) server.certificate.validate.ignore[flag, ...](yes|no) server.certificate.validate.ignore(all|none) server.certificate.validate.ignore(flag, ...)

; ; ; ;

form form form form

1 2 3 4

where flag is one of expiration, untrusted_issuer, or hostname_mismatch The default value is none. Layer and Transaction Notes •

Use in layers.

•

Applies to: HTTPS forward and reverse proxy transactions, SSL tunnel transactions.

Example For maximum security, you should validate all server certificates. For sites that have bad certificates that you nevertheless must be able to access, you can create a white list that disables only that part of the validation process necessary to access the site. server_url.host=some-server.com server.certificate.validate.ignore.expiration(yes) server_url.host=blah.com server.certificate.validate.ignore.hostname_mismatch(yes) server_url.host=do.this.at.your.own.peril server.certificate.validate.ignore.untrusted_issuer(yes)

See Also •

330

Properties: server.certificate.validate( )

Chapter 4: Property Reference

server.connection.dscp() Controls server-side outbound QoS/DSCP value. Syntax server.connection.dscp(dscp_value)

where dscp_value is 0..63 | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | best-effort | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | ef | echo | preserve

The special value preserve means to track the incoming DSCP value on the primary server connection and use that as the value when sending packets on the client connections. The special value echo means the outbound packet’s DSCP value will use the same value as the inbound packet’s DSCP value. The default value is preserve. Layer and Transaction Notes •

Valid in , , , and layers.

•

Applies to: All transactions

Example The first QoS policy rule sets the server outbound QoS/DSCP value to echo, and the second QoS policy rule sets the server outbound QoS/DSCP value to 50. server.connection.dscp(echo) server.connection.dscp(50)

331

Volume 10: Content Policy Language Guide

shell.prompt( ) Sets the prompt for a proxied shell transaction. Syntax shell.prompt(substitution-string)

Layer and Transaction Notes •

Use in layers.

•

Applies to shell (Telnet) proxy transactions.

Example This example implements the following policies: 1.

All requests from HR_subnet get the Shell prompt “client's address: Welcome to this appliance.”

2.

All requests from ENG_subnet get the default Shell prompt.

3.

All other requests get no Shell prompt. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end ; 1 client.address=HR_subnet \ shell.prompt("$(client.address): Welcome to $(appliance.name)") ; 2 client.address=ENG_subnet shell.prompt(default) ; 3 shell.prompt(no)

See Also •

332

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

shell.realm_banner( ) Sets the realm banner for a proxied shell transaction. Syntax shell.realm_banner(substitution-string)

Layer and Transaction Notes •

Use in layers.

•

Applies to shell (Telnet) proxy transactions.

Example

This example implements the following policies: 1.

All requests from HR_subnet get the Shell realm banner “client's address: Welcome to this appliance.”

2.

All requests from ENG_subnet get the default Shell realm banner.

3.

All other requests get no Shell realm banner. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end ; 1 client.address=HR_subnet \ shell.realm_banner("$(client.address): Welcome to $(appliance.name)") ; 2 client.address=ENG_subnet shell.realm_banner(default) ; 3 shell.realm_banner(no)

See Also •

Appendix D: "CPL Substitutions".

333

Volume 10: Content Policy Language Guide

shell.welcome_banner( ) Sets the welcome banner for a proxied shell transaction. Syntax shell.welcome_banner(substitution-string)

Layer and Transaction Notes •

Use in layers.

•

Applies to shell (Telnet) proxy transactions.

Example This example implements the following policies: 1.

All requests from HR_subnet get the Shell welcome banner “client's address: Welcome to this appliance.”

2.

All requests from ENG_subnet get the default Shell welcome banner.

3.

All other requests get no Shell welcome banner. define subnet HR_subnet 10.10.0.0/16 end define subnet ENG_subnet 10.9.0.0/16 end ; 1 client.address=HR_subnet \ shell.welcome_banner("$(client.address): Welcome to $(appliance.name)") ; 2 client.address=ENG_subnet shell.welcome_banner(default) ; 3 shell.welcome_banner(no)

334

Chapter 4: Property Reference

socks.accelerate( ) The socks.accelerate property controls the SOCKS proxy handoff to other protocol agents. Syntax socks.accelerate(no|auto|http|aol_im|msn_im|yahoo_im)

The default value is auto. where: •

no—The SOCKS proxy does not hand off the transaction to another proxy agent, but

tunnels the SOCKS transaction. •

auto—The handoff is determined by the URL scheme.

Any other value forces the SOCKS proxy to hand off the transaction to the agent for the indicated protocol. The socks.accelerated= condition can be used to test which agent was selected for handoff. The tunneled= condition can be used to test for unaccelerated (tunneled) SOCKS transactions. After the handoff, the transaction is subject to policy as a proxy transaction for the appropriate protocol. Within that policy, the socks= condition can be used to test for transactions use SOCKS for client communication. Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS proxy transactions.

See Also •

Properties: socks_gateway( ), socks.authenticate( ), socks.authenticate.force( )

•

Conditions: socks=, socks.accelerated=, socks.method=, socks.tunneled=, socks.version=

335

Volume 10: Content Policy Language Guide

socks.allow_compression( ) Determines whether the SOCKS proxy is allowed to exchange compressed data with a SG appliance client. Note: The socks.allow_compression property is deprecated in favor of •

"adn.server.optimize( )"

•

"adn.server.optimize.inbound( )"

•

"adn.server.optimize.outbound( )"

Syntax socks.allow_compression(yes|no)

The default value is yes. Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS transactions.

Example socks.allow_compression(yes)

336

Chapter 4: Property Reference

socks.authenticate( ) The same realms can be used for SOCKS proxy authentication as can be used for regular proxy authentication. This form of authentication applies only to SOCKS transactions. The regular authenticate( ) property does not apply to SOCKS transactions. However, if an accelerated SOCKS transaction has already been authenticated in the same realm by the SOCKS proxy, no new authentication challenge is issued. If the realms identified in the socks.authenticate( ) and authenticate( ) properties differ, however, a new challenge is issued by the proxy agent used to accelerate the SOCKS transaction. Note:

There is no optional display name.

Following SOCKS proxy authentication, the standard user=, group=, and realm= tests are available. The relation between SOCKS authentication and denial is controlled through the socks.authenticate.force( ) property. The default setting no implies that denial overrides socks.authenticate( ), with the result that user names may not appear for denied requests if that

denial could be determined without authentication. To ensure that user names appear in access logs, use socks.authenticate.force(yes). Syntax socks.authenticate(realmname)

where: •

realmname—One of the already-configured realms.

•

Consider that socks.authenticate() depends exclusively on a limited number of triggers: •

proxy.address=

•

proxy.card=

•

proxy.port=

•

client.address=

•

socks.version=

Date and time triggers, while available, are not recommended. Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS proxy transactions.

See Also •

Properties: authenticate(), socks_gateway(), socks.accelerate(), socks.authenticate.force()

•

Conditions: socks=, socks.method=, socks.tunneled=, socks.version=

337

Volume 10: Content Policy Language Guide

socks.authenticate.force( ) This property controls the relation between SOCKS authentication and denial. Syntax socks.authenticate.force(yes|no)

The default value is no. where: •

yes—Makes socks.authenticate( ) higher priority than deny( ) or exception( ). Use yes to ensure that user ID's are available for access logging, even of denied requests.

•

no—deny( ) and exception( ) have a higher priority than socks.authenticate( ). This setting allows early denial (based on proxy card, address or port, client address, or SOCKS version, for example). That is, the denial preempts any authentication requirement.

Note:

This does not affect regular authenticate( ).

Layer and Transaction Notes •

Use in layers.

•

Applies to SOCKS proxy transactions.

See Also

338

•

Properties: socks.authenticate( ), socks_gateway( ), socks.accelerate( )

•

Conditions: socks.method=, socks.tunneled=, socks.version=

Chapter 4: Property Reference

socks_gateway( ) Controls whether or not the request associated with the current transaction is sent through a SOCKS gateway. There is a box-wide configuration setting (config > socks-gateways > sequence) for the default SOCKS gateway failover sequence. The socks_gateway( ) property is used to override the default SOCKS gateway failover sequence with a specific list of SOCKS gateway aliases. The list of aliases might contain the special token default, which expands to include the default SOCKS gateway failover sequence defined in configuration. Duplication is allowed in the specified alias list only in the case where a gateway named in the default failover sequence is also named explicitly in alias_list. In addition, there is a box-wide configuration setting (config> socks-gateways > failure-mode) for the default SOCKS gateway failure mode. The socks_gateway.fail_open( ) property overrides the configured default. Syntax socks_gateway(alias_list|no)

The default value is no. where: •

alias_list—Send this request through the specified alias list. The SG appliance attempts to send this request through the specified gateways in the order specified by the list. It proceeds to the next gateway alias as necessary when the gateway is down, as determined by health checks.

•

no—Do not send this request through a SOCKS gateway. A forwarding host or ICP host

may still be used, depending on those properties. If neither are set, the request is sent directly to the origin server. A setting of no overrides the default sequence defined in configuration. Layer and Transaction Notes •

Use in layers.

•

Applies to all except administrator transactions.

See Also •

Properties: direct( ), forward( ), socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( )

•

Conditions: socks.method=, socks.tunneled=, socks.version=

339

Volume 10: Content Policy Language Guide

socks_gateway.fail_open( ) Controls whether the SG appliance terminates or continues to process the request if the specified SOCKS gateway or any designated backup or default cannot be contacted. There is a box-wide configuration setting (config > socks-gateways > failure-mode) for the default SOCKS gateway failure mode. The socks_gateway.fail_open( ) property overrides the configured default. Syntax socks_gateway.fail_open(yes|no)

The default value is no. where: •

yes—Continue to process the request if the specified SOCKS gateway or any designated backup or default cannot be contacted. This may result in the request being forwarded through a forwarding host or ICP, or may result in the request going direct to the origin server.

•

no—Terminates the request if the specified SOCKS gateway or any designated backup or default cannot be contacted.

Layer and Transaction Notes •

Use in layers.

•

Applies to all except administrator transactions.

See Also •

Properties: socks.accelerate( ), socks.authenticate( ), socks.authenticate.force( ), socks_gateway( )

•

340

Conditions: socks.method=, socks.tunneled=, socks.version=

Chapter 4: Property Reference

socks_gateway.request_compression( ) Sets whether to request the upstream SOCKS gateway to allow compression of traffic with this client. When enabled, the upstream SOCKS gateway will be asked to allow traffic to be compressed. If compression is refused by the gateway, the client will continue with normal, uncompressed traffic. If the property is set to default, the 'request-compression' setting in the SOCKS gateway configuration will be used. The upstream SOCKS gateway must be a SG appliance participating in SOCKS compression. Note: The sock_gateway.request_compression property is deprecated in favor of •

"adn.server.optimize( )"

•

"adn.server.optimize.inbound( )"

•

"adn.server.optimize.outbound( )"

Syntax socks_gateway.request_compression(yes|no|default)

The default value is default. Layer and Transaction Notes •

Use in layers.

•

Applies to transactions connecting upstream to a SOCKS gateway.

Example socks_gateway.request_compression(yes)

See Also •

Properties: socks.allow_compression( )

341

Volume 10: Content Policy Language Guide

ssl.forward_proxy( ) Determines whether SSL connections should be intercepted. The default value is https. Syntax ssl.forward_proxy(no|https)

where: •

no tunnels the SSL connection without breaking encryption

•

https intercepts SSL connections using the SSL Proxy

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example Since interception is the default action for HTTPS traffic, the general usage model is to create exceptions for connections that need to be tunneled. server.certificate.hostname.category="Financial Services" ssl.forward_proxy(no)

342

Chapter 4: Property Reference

ssl.forward_proxy.hostname( ) Specify the hostname for the forged certificate that is used for SSL interception. The default value is "". The default behavior is to use the hostname from the original server certificate. Syntax ssl.forward_proxy.hostname(String)

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example When the browser receives a server certificate signed by an unknown CA or with a hostname that does not match the URL hostname, it shows a security alert popup. This popup can be leveraged as an SSL level splashing mechanism. Various combinations of the ssl.forward_proxy.* properties can be used to force the Security Alert popup and provide additional information. The security alert popup can be forced by a hostname mismatch or by using an unknown CA as follows: ssl.forward_proxy.hostname("WE ARE WATCHING YOU") \ ssl.forward_proxy.issuer_keyring(new-private-ca) \ ssl.forward_proxy.splash_text("This session is being monitored.") \ ssl.forward_proxy.splash_url(http://example.com/ssl-intercept-policy.html)

343

Volume 10: Content Policy Language Guide

ssl.forward_proxy.issuer_keyring( ) Specify the CA keyring for signing the forged certificate that is used for SSL interception. The default value is auto. The default behavior is to use the keyring specified in configuration by the SGOS#(config ssl) intercept CLI command. Syntax ssl.forward_proxy.issuer_keyring (auto|KeyringId)

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example When the browser receives a server certificate signed by an unknown CA or with a hostname that does not match the URL hostname, it shows a security alert popup. This popup can be leveraged as an SSL level splashing mechanism. Various combinations of the ssl.forward_proxy.* properties can be used to force the Security Alert popup and provide additional information. The security alert popup can be forced by a hostname mismatch or by using an unknown CA as follows: ssl.forward_proxy.hostname("WE ARE WATCHING YOU") \ ssl.forward_proxy.issuer_keyring(new-private-ca) \ ssl.forward_proxy.splash_text("This session is being monitored.") \ ssl.forward_proxy.splash_url(http://example.com/ssl-intercept-policy.html)

344

Chapter 4: Property Reference

ssl.forward_proxy.server_keyring( ) Specify a static server certificate and keypair for use during SSL interception. When an SSL connection is intercepted, the normal behavior is to dynamically generate a forged server certificate and keypair. The contents of this forged certificate are controlled by the .hostname, .splash_text, .splash_url and .issuer_keyring members of the ssl.forward_proxy family of properties. The ssl.forward_proxy.server_keyring property overrides this behavior, and allows you to specify a static certificate and keypair which will be used instead. It is normally only used for debugging. The default value is no, which causes a forged certificate to be dynamically generated. Syntax ssl.forward_proxy.server_keyring (no|KeyringId)

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example ssl.forward_proxy.server_keyring(my_keyring)

345

Volume 10: Content Policy Language Guide

ssl.forward_proxy.splash_text( ) Specify informational text to be inserted into the forged certificate that is used for SSL interception. . The default value is "". The string argument is limited to 200 printable characters. Syntax ssl.forward_proxy.splash_text(String)

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example When the browser receives a server certificate signed by an unknown CA or with a hostname that does not match the URL hostname, it shows a security alert popup. This popup can be leveraged as an SSL level splashing mechanism. Various combinations of the ssl.forward_proxy.* properties can be used to force the Security Alert popup and provide additional information. The security alert popup can be forced by a hostname mismatch or by using an unknown CA as follows: ssl.forward_proxy.hostname("WE ARE WATCHING YOU") \ ssl.forward_proxy.issuer_keyring(new-private-ca) \ ssl.forward_proxy.splash_text("This session is being monitored.") \ ssl.forward_proxy.splash_url(http://example.com/ssl-intercept-policy.html)

346

Chapter 4: Property Reference

ssl.forward_proxy.splash_url( ) Specify an informational url to be inserted into the forged certificate that is used for SSL interception. The default value is "". Syntax ssl.forward_proxy.splash_url(""|Url)

Layer and Transaction Notes •

Use in layers.

•

Applies to SSL Intercept transactions.

Example When the browser receives a server certificate signed by an unknown CA or with a hostname that does not match the URL hostname, it shows a security alert popup. This popup can be leveraged as an SSL level splashing mechanism. Various combinations of the ssl.forward_proxy.* properties can be used to force the Security Alert popup and provide additional information. The security alert popup can be forced by a hostname mismatch or by using an unknown CA as follows: ssl.forward_proxy.hostname("WE ARE WATCHING YOU") \ ssl.forward_proxy.issuer_keyring(new-private-ca) \ ssl.forward_proxy.splash_text("This session is being monitored.") \ ssl.forward_proxy.splash_url(http://example.com/ssl-intercept-policy.html)

347

Volume 10: Content Policy Language Guide

streaming.transport( ) Determines the upstream transport mechanism to be used for this streaming transaction. This setting is not definitive. The ability to use the specified transport mechanism depends on the capabilities of the selected forwarding host. Syntax streaming.transport(auto|tcp|http)

where: •

auto—Use the default transport for the upstream connection, as determined by the originating transport and the capabilities of any selected forwarding host.

•

tcp—Use TCP as the upstream transport mechanism.

•

http—Use HTTP as the upstream transport mechanism.

Layer and Transaction Notes •

Use in layers.

•

Applies to streaming transactions.

See Also •

348

Conditions: bitrate=, live=, streaming.client=, streaming.content=

Chapter 4: Property Reference

terminate_connection( ) The terminate_connection( ) property is used in an layer to drop the connection rather than return the exception response. The yes option terminates the connection instead of returning the response. Syntax terminate_connection(yes|no)

The default is no. Layer and Transaction Notes •

Use in layers.

•

Applies to HTTP transactions.

349

Volume 10: Content Policy Language Guide

trace.destination( ) Used to change the default path to the trace output file. By default, policy evaluation trace output is written to an object in the cache accessible using a console URL of the following form: http://SG_appliance_IP_address:8081/Policy/Trace/path

Syntax trace.destination(path)

where path is, by default, default_trace.html. You can change path to a filename or directory path, or both. If only a directory is provided, the default trace filename is used. Layer and Transaction Notes •

Use in any layer.

•

Applies to all transactions.

Example ; Change directory location of trace output file to ; http://SG_appliance_IP_address:8081/Policy/Trace/test/default_trace.html trace.destination(test/) ; Change trace output file location to ; http://SG_appliance_IP_address:8081/Policy/Trace/test/phase_2.html trace.destination(test/phase_2.html)

See Also

350

•

Properties: trace.request(), trace.rules()

•

Appendix D: "CPL Substitutions".

Chapter 4: Property Reference

trace.request( ) Determines whether detailed trace output is generated for the current request. The default value is no, which produces no output. Trace output is generated at the end of a request, and includes request parameters, property settings, and the effects of all actions taken. Output tracing can be set conditionally by creating a rule that combines this property with conditions such as url= or client.address=. By default, trace output is written to an object accessible using the following console URL: http://SG_appliance_IP_address:8081/Policy/Trace/default_trace.html

The trace output location can be controlled using the trace.destination( ) property. Note:

Tracing is best used temporarily, such as for troubleshooting; the log_message( ) action is best for on-going monitoring.

Syntax trace.request(yes|no)

The default value is no. Layer and Transaction Notes •

Use in any layer.

•

Applies to all transactions.

Example ; Generate trace details when a specific URL is requested. url=//www.example.com/confidential trace.request(yes)

See Also •

Properties: trace.destination(), trace.rules()

351

Volume 10: Content Policy Language Guide

trace.rules( ) Determines whether trace output is generated showing policy rule evaluation for the transaction. By default, trace output is written to an object accessible using the following console URL: http://SG_appliance_IP_address:8081/Policy/Trace/default_trace.html

The trace output location can be controlled using the trace.destination( ) property. Note:

Tracing is best used temporarily, such as for troubleshooting; the log_message( ) action is best for on-going monitoring.

Syntax trace.rules(yes|no|all)

where: •

yes—Generates output only for rules that match the request.

•

all—Additionally shows which rules were skipped because one or more of their conditions were false or not applicable to the current transaction; displays the specific condition in the rule that failed.

•

no—Suppresses output associated with policy rule evaluation.

The default value is no. Layer and Transaction Note •

Use in and layers.

Example ; Generate trace messages. trace.rules(yes) trace.request(yes)

See Also •

352

Properties: trace.destination(), trace.request()

Chapter 4: Property Reference

trust_destination_ip() This property allows the SG to honor client's destination IP when it intercepts client requests transparently. The Proxy SG will trust the client provided destination IP and not do the DNS lookup for the HOST value in appropriate cases. This feature will not apply (i.e. existing behaviour will be preserved) if : a. The Proxy SG recieves the client requets in explicit proxy deployment cases. b. The Proxy SG has forwarding rules configured for the given HOST value. c. The Proxy SG will connect upstream on SOCKS. d. The Proxy SG will connect upstream using ICP. By default it is configured as enabled. Syntax trust_destination_ip(yes|no)

The default value is taken from a global configuration setting Layer and Transaction Notes •

Valid layers: Proxy

•

Applies to: Proxy transactions

Example Disable trusting destination IP. proxy.address=10.10.167.0/24 trust_destination_ip(no)

353

Volume 10: Content Policy Language Guide

ttl( ) Sets the time-to-live (TTL) value of an object in the cache, in seconds. Upon expiration, the cached copy is considered stale and will be re-obtained from the origin server when next accessed. However, this property has an effect only if the following HTTP command line option is enabled: Force explicit expirations: Never serve after.

If the above option is not set, the SG appliance’s freshness algorithm determines the time-to-live value. Note:

advertisement(yes) overrides any ttl( ) value.

Syntax ttl(seconds)

where seconds is an integer, specifying the number of seconds an object remains in the cache before it is deleted. The maximum value is 4294967295, or about 136 years. The default value is specified by configuration. Layer and Transaction Notes •

Use in layers.

Example ; Delete the specified cached objects after 30 seconds. url=//www.example.com/dyn_images ttl(30)

See Also •

354

Properties: advertisement( ), cache( )

Chapter 4: Property Reference

ua_sensitive( ) Used to modify caching behavior by declaring that the response for a given object is expected to vary based on the user agent used to retrieve the object. Set to yes to specify this behavior. Using ua_sensitive(yes) has the same effect as cache(no). Note:

Remember that any conflict among CPL property settings is resolved by CPL evaluation logic, which uses the property value that was last set when evaluation ends.

Syntax ua_sensitive(yes|no)

The default value is no. Layer and Transaction Notes •

Use in layers.

•

Applies to proxy transactions, which execute both and layers. Does not apply to FTP over HTTP transactions.

See Also •

Properties: advertisement( ), always_verify( ), bypass_cache( ), cache( ), cookie_sensitive( ), delete_on_abandonment( ), direct( ), dynamic_bypass( ), force_cache( ), pipeline( ), refresh( ), ttl( )

355

Volume 10: Content Policy Language Guide

user.login.log_out( ) Log out the current user from the current ip address. This property is used to log out a user from the current ip address. When this property is executed, the current login for the user is logged out. The user will need to re-authenticate at this ip address before future transactions can proceed. Syntax user.login.log_out(yes|no)

The default value is yes. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Log out the user whenever they visit the log out page. url="http://company.com/log_out.html" user.login.log_out(yes)

356

Chapter 4: Property Reference

user.login.log_out_other( ) Log out the current user from logins other than the current ip address. This property is used to log out any other logins of the user on ip addresses other than the current ip address. When this property is executed, the all logins of the user on ip address other than the current ip address are logged out. The user will need to re-authenticate at the other ip address before future transactions at those ip addresses can proceed. Syntax user.login.log_out_other(yes|no)

The default value is yes. Layer and Transaction Notes •

Valid layers: Proxy, Admin

•

Applies to: Proxy transactions, Administrative transactions

Example Log out the user from other workstations if they are logged in more than once. user.login.count=2.. user.login.log_out_other(yes)

357

Volume 10: Content Policy Language Guide

358

Chapter 5:

Action Reference

An action takes arguments and is wrapped in a user-named action definition block. When the action definition is called from a policy rule, any actions it contains operate on their respective arguments. Within a rule, named action definitions are enabled and disabled using the action( )property. Actions take the following general form: action(argument1, ...)

An action block is limited to the common subset among the allowed layers of each of the actions it contains. Actions appear only within action definitions. They cannot appear in layers.

Argument Syntax The allowed syntax for action arguments depends on the action. •

String—A string argument must be quoted if it contains whitespace or other special characters. For example: log_message(“Access alert”).

•

Enumeration—Actions such as delete( ) use as an argument a token specifying the transaction component on which to act. For example: a header name such as request.header.Referer.

•

Regular expression—Several actions take regular expressions. For more information about writing regular expressions, see Appendix E: "Using Regular Expressions".

•

Variable substitution—The quoted strings in some action arguments can include variable substitution substrings. These include the various versions of the replacement argument of the redirect( ), rewrite( ), and rewrite( ) actions, and the string argument in the append( ), log_message( ), and set(header, string) actions. A variable substitution is a substring of the form: $(name)

where name is one of the allowed substitution variables. For a complete list of substitutions, see Appendix D: "CPL Substitutions".

Action Reference The remainder of this chapter lists the actions and their accepted values. It also provides the context in which each action can be used and examples of how to use them.

359

Volume 10: Content Policy Language Guide

append( ) Appends a new component to the specified header. Note:

An error results if two header modification actions modify the same header. This results in a compile time error if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks.

Syntax append(header, string) append(im.message.text, string)

where: •

header—A header specified using the following form. For a list of recognized headers,

including headers that support field repetition, see Appendix C: "Recognized HTTP Headers". •

request.header.header_name—Identifies a recognized HTTP request header.

•

response.header.header_name—Identifies a recognized HTTP response header.

•

request.x_header.header_name—Identifies any request header, including custom

headers. •

response.x_header.header_name—Identifies any response header, including

custom headers. •

string—A quoted string that can optionally include one or more variable substitutions.

•

im.message.text—Appends the specified string to the end of the instant message text.

Layer and Transaction Notes •

Use from or layers.

See Also

360

•

Actions: delete( ), delete_matching( ), rewrite(header, regex_pattern, replacement_component), set(header, string)

•

Conditions: request.header.header_name=, request.header.header_name.address=, request.x_header.header_name=, request.x_header.header_name.address=, response.header.header_name=, response.x_header.header_name=

•

Appendix D: "CPL Substitutions".

Chapter 5: Action Reference

delete( ) Deletes all components of the specified header. Note:

An error results if two header modification actions modify the same header. The error is noted at compile time if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks.

Syntax delete(header)

where: •

header—A header specified using the following form. For a list of recognized headers,

see Appendix C: "Recognized HTTP Headers". •

request.header.header_name—Identifies a recognized HTTP request header.

•

response.header.header_name—Identifies a recognized HTTP response header.

•

request.x_header.header_name—Identifies any request header, including custom

headers. •

response.x_header.header_name—Identifies any response header, including

custom headers. •

exception.response.header.header_name—Identifies a recognized HTTP

response header from the exception response. Layer and Transaction Notes •

Use with exception.response.header.header_name in or layers.

•

Use with request or response headers in or layers.

•

Applies to HTTP transactions.

Example ; Delete the Referer request header, and also log the action taken. define action DeleteReferer log_message("Referer header deleted: $(request.header.Referer)") delete(request.header.Referer) end

See Also •

Actions: append( ), delete_matching( ), rewrite(header, regex_pattern, replacement_component), set(header, string)

•

Conditions: request.header.header_name=, request.header.header_name.address=, request.x_header.header_name=, request.x_header.header_name.address=, response.header.header_name=, response.x_header.header_name=

361

Volume 10: Content Policy Language Guide

delete_matching( ) Deletes all components of the specified header that contain a substring matching a regular-expression pattern. Note:

An error results if two header modification actions modify the same header. The error is noted at compile time if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks.

Syntax delete_matching(header, regex_pattern)

where: •

header—A header specified using the following form. For a list of recognized headers,

see Appendix C: "Recognized HTTP Headers". •

request.header.header_name— Identifies a recognized HTTP request header.

•

response.header.header_name—Identifies a recognized HTTP response header.

•

request.x_header.header_name—Identifies any request header, including custom

headers. •

response.x_header.header_name—Identifies any response header, including

custom headers. •

regex_pattern—A quoted regular-expression pattern. For more information, see

Appendix E: "Using Regular Expressions". Layer and Transaction Notes •

Use in and layers only.

See Also

362

•

Actions: append( ), delete( ), rewrite(header, regex_pattern, replacement_component), set(header, string)

•

Conditions: request.header.header_name=, request.header.header_name.address=, request.x_header.header_name=, request.x_header.header_name.address=, response.header.header_name=, response.x_header.header_name=

Chapter 5: Action Reference

im.alert( ) Deliver a message in-band to the instant messaging user. The text appears in the instant message window. This action is similar to log_message( ), except that it appends entries to a list in the instant messaging transaction that the IM protocol renders in an appropriate way. Multiple alerts can be appended to a transaction. The protocol determines how multiple alerts appear to the user. Syntax im.alert(text)

where text is a quoted string that can optionally include one or more variable substitutions. Layer and Transaction Notes •

Use in and layers.

See Also •

Actions: log_message( )

•

Appendix D: "CPL Substitutions"

363

Volume 10: Content Policy Language Guide

log_message( ) Writes the specified string to the SG appliance event log. Events generated by log_message( ) are viewed by selecting the Policy messages event logging level in the Management Console. Note:

This is independent of access logging.

Syntax log_message(string)

where string is a quoted string that can optionally include one or more variable substitutions. Layer and Transaction Notes •

Can be referenced by any layer.

Example ; Log the action taken, and include the original value of the Referer header. define action DeleteReferer log_message("Referer header deleted: $(request.header.Referer)") delete(request.header.Referer) end

See Also

364

•

Actions: notify_email( ), notify_snmp( )

•

Properties: access_log( ), log.rewrite( ), log.suppress( )

•

Appendix D: "CPL Substitutions"

Chapter 5: Action Reference

notify_email( ) Sends an e-mail notification to the list of recipients specified in the Event Log mail configuration. The sender of the e-mail appears as Primary_SG appliance_IP_address configured_appliance_hostname>. You can specify multiple notify_email actions, which may result in multiple mail messages for a single transaction. The e-mail is sent when the transaction terminates. The e-mail is sent to the list of recipients specified in the Event Log mail configuration. Syntax notify_email(subject, body)

where subject and body are quoted strings that can optionally include one or more variable substitutions. Layer and Transaction Notes •

Can be referenced by any layer.

Example define condition restricted_sites url.domain=a_very_bad_site ... end condition=restricted_sites action.notify_restricted(yes) define action notify_restricted notify_email(“restricted: ”, \ ”$(client.address) accessed url: $(url)”) end

See Also •

Actions: log_message( ), notify_snmp( )

•

Appendix D: "CPL Substitutions"

365

Volume 10: Content Policy Language Guide

notify_snmp( ) Multiple notify_snmp actions may be specified, resulting in multiple SNMP traps for a single transaction. The SNMP trap is sent when the transaction terminates. Syntax notify_snmp(message)

where message is a quoted string that can optionally include one or more variable substitutions. Layer and Transaction Notes •

Can be referenced by any layer.

See Also

366

•

Actions: log_message( ), notify_email( )

•

Appendix D: "CPL Substitutions"

Chapter 5: Action Reference

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

You can't use a redirect to override an exception. Exceptions always override redirects.

FTP over HTTP requests are not redirected for Microsoft Internet Explorer clients. To avoid this issue, do not use the redirect( ) action when the url.scheme=ftp condition is true. For example, if the http_redirect action definition contains a redirect( ) action, you can use the following rule: url.scheme=ftp action.http_redirect(no)

Note:

An error results if two redirect( ) actions conflict. The error is noted at compile time if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks.

Important: It is possible to put the browser into an infinite redirection loop if the URL that the browser is being redirected to also triggers a policy-based redirect response. Syntax redirect(response_code, regex_pattern, redirect_location)

where: •

response_code—An HTTP redirect code used as the HTTP response code; supported

codes are 301, 302, 305, and 307. •

regex_pattern—A quoted regular-expression pattern that is compared with the request URL based on an anchored match. If the regex_pattern does not match the request URL, the redirect action is ignored. A regex_pattern match sets the values for substitution variables. If no variable substitution is performed by the redirect_location string, specify ".* " for regex_pattern to match all request URLs. For more information about

regular expressions, see Appendix E: "Using Regular Expressions". •

redirect_location—A quoted string that can optionally include one or more variable

substitutions. This string is an absolute or relative url that is included in the redirect response, as the value of the Location: header. In normal usage, the redirect_location is an absolute url like http://www.example.com/, which instructs the client to redirect to the specified URL. If the redirect_location does not begin with "://", where scheme is usually http, then it will be interpreted by the client as a relative URL, which is interpreted relative to the original request URL. For more information, see Appendix D: "CPL Substitutions". Layer and Transaction Notes •

Use in or layers.

367

Volume 10: Content Policy Language Guide

See Also

368

•

Actions: rewrite(url.host, host_regex_pattern, replacement_host), rewrite(url, regex_pattern, redirect_location), set(url.port, port_number)

•

Conditions: exception.id=

•

Appendix D: "CPL Substitutions"

Chapter 5: Action Reference

rewrite( ) Rewrites the request URL, URL host, or components of the specified header if it matches the regular-expression pattern. This action is often used in conjunction with the URL rewrite form of the transform action in a server portal application. Note:

The URL form of the rewrite( ) action does not rewrite some URL components for Windows Media (MMS) transactions. The URL scheme, host, and port are restored to their original values and an error logged if the URL specified by redirect_location attempts to change these components. An error results if the URL or URL host form of this action conflicts with another URL rewriting action. The error is noted at compile time if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks. Similarly, an error results if two header modifications act on the same header.

HTTPS Limitation Only the host and port are available for rewriting by the URL or URL host form when the client browser is using a proxy for an HTTPS connection and the CONNECT or TUNNEL method is used. This is because the URL path is encrypted and unavailable for rewriting. Syntax rewrite(url, regex_pattern, redirect_location[, URL_form1, ...]) rewrite(url.host, regex_pattern, replacement_host[, URL_form1, ...]) rewrite(header, regex_pattern, replacement_component)

where: •

url—Specifies a rewrite of the entire URL.

•

url.host—Specifies a rewrite of the host portion of the URL.

•

header—Specifies the header to rewrite, using the following form. For a list of recognized

headers, see Appendix C: "Recognized HTTP Headers". •

request.header.header_name—Identifies a recognized HTTP request header.

•

response.header.header_name—Identifies a recognized HTTP response header.

•

request.x_header.header_name—Identifies any request header, including custom

headers. •

response.x_header.header_name—Identifies any response header, including

custom headers. •

regex_pattern—A quoted regular-expression pattern that is compared with the URL, host or header as specified, based on an anchored match. If the regex_pattern does not match, the rewrite action is ignored. A regex_pattern match sets the values for

substitution variables. If the rewrite should always be applied, but no variable substitution is required for the replacement string, specify ".* " for regex_pattern. For more information about regular expressions, see Appendix E: "Using Regular Expressions".

369

Volume 10: Content Policy Language Guide

•

redirect_location—A quoted string that can optionally include one or more variable substitutions, which replaces the entire URL once the substitutions are performed. The resulting URL is considered complete, and replaces any URL that contains a substring matching the regex_pattern substring. Sub-patterns of the regex_pattern matched can be substituted in redirect_location using the $(n) syntax, where n is an integer from 1 to 32, specifying the matched sub-pattern. For more information, see Appendix D: "CPL Substitutions".

•

replacement_host—A quoted string that can optionally include one or more variable substitutions, which replaces the host portion of the URL once the substitutions are performed. Note that the resulting host is considered complete, and it replaces the host in the URL forms specified. Sub-patterns of the regex_pattern matched can be substituted in replacement_host using the $(n) syntax, where n is an integer from 1 to 32, specifying the matched sub-pattern. For more information, see Appendix D: "CPL Substitutions".

•

URL_form1, ...—An optional list of up to three forms of the request URLs that will have

the URL or host replaced. If this parameter is left blank, all three forms are rewritten. The following are the possible values:

•

•

log—Request URL used when generating log messages.

•

cache—Request URL used to address the object in the local cache.

•

server—Request URL sent to the origin server.

replacement_component—A quoted string that can optionally include one or more

variable substitutions, which replaces the entire component of the header matched by the regex_pattern substring. Sub-patterns of the regex_pattern matched can be substituted in replacement_component using the $(n) syntax, where n is an integer from

1 to 32, indicating the matched sub-pattern. For more information, see Appendix D: "CPL Substitutions". Discussion Any rewrite of the server form of the request URL must be respected by policy controlling upstream connections. The server form of the URL is tested by the server_url= conditions, which are the only URL tests allowed in layers. All forms of the URL are available for access logging. The version of the URL that appears in a specific access log is selected by including the appropriate substitution variable in the access log format: •

c-uri—The original URL

•

cs-uri—The log URL, used when generating log messages

•

s-uri—The cache URL, used to address the object in the local cache

•

sr-uri—The server URL, used in the upstream request

In the absence of actions that modify the URL, all of these substitution variables represent the same value.

370

Chapter 5: Action Reference

Layer and Transaction Notes •

Use in and layers.

•

URL and host rewrites apply to all transactions. Header rewrites apply to HTTP transactions.

Example rewrite(url, "^http://www\.example\.com/(.*)", "http://www.server1.example.com/$(1)")

See Also •

Actions: append( ), delete( ), delete_matching( ), redirect( ), set( ), transform

•

Conditions: request.header.header_name=, request.header.header_name.address=, request.x_header.header_name=, request.x_header.header_name.address=, response.header.header_name=, response.x_header.header_name=, server_url=

•

Definitions: transform url_rewrite

•

Appendix D: "CPL Substitutions".

371

Volume 10: Content Policy Language Guide

set( ) Sets the specified header to the specified string after deleting all components of the header. Note:

An error results if two header modification actions modify the same header. The error is noted at compile time if the conflicting actions are within the same action definition block. A runtime error is recorded in the event log if the conflicting actions are defined in different blocks.

HTTPS Limitation Only the host and port are available for setting when the client browser is using a proxy for an HTTPS connection and the CONNECT or TUNNEL method is used. This is because the URL path is encrypted and unavailable for setting. Syntax set(header, string) set(im.message.text, value) set(url.port, port_number [, URL_form1, URL_form2, ...])

where: •

header—A header specified using the following form. For a list of recognized headers,

see Appendix C: "Recognized HTTP Headers". •

request.header.header_name—Identifies a recognized HTTP request header.

•

response.header.header_name—Identifies a recognized HTTP response header.

•

request.x_header.header_name—Identifies any request header, including custom

headers. •

response.x_header.header_name—Identifies any response header, including

custom headers. •

exception.response.header.header_name—Identifies a recognized HTTP

response header from the exception response. •

exception.response.x_header.header_name—Identifies any response header

from the exception response, including custom headers. •

string—A quoted string that can optionally include one or more variable substitutions,

which replaces the specified header components once the substitutions are performed. •

im.message.text, value—Sets the instant message text to the specified value.

•

port_number—The port number that the request URL is set to. The range is an integer

between 1 and 65535. •

URL_form1, URL_form2, ...—An optional list of up to three forms of the request URLs that have the port number set. If this parameter is left blank, all three forms of the request URL are rewritten. The possible values are the following:

•

372

log—Request URL used when generating log messages.

Chapter 5: Action Reference

•

cache—Request URL used to address the object in the local cache.

•

server—Request URL sent to the origin server.

Discussion Any change to the server form of the request URL must be respected by policy controlling upstream connections. The server form of the URL is tested by the server_url= conditions, which are the only URL tests allowed in layers. All forms of the URL are available for access logging. The version of the URL that appears in a specific access log is selected by including the appropriate substitution variable in the access log format: •

c-uri—The original URL.

•

cs-uri—The log URL, used when generating log messages.

•

s-uri—The cache URL, used to address the object in the local cache.

•

sr-uri—The server URL, used in the upstream request.

In the absence of actions that modify the URL, all of these substitution variables represent the same value. Layer and Transaction Notes •

Use with exception.response.header.header_name in or layers; otherwise use only from or layers.

•

When used with headers, applies to HTTP transactions.

•

When used with im.message.text, applies to IM transactions.

•

When used with url.port, applies to all transactions.

Example ; Modifies the URL port component to 8081 for requests sent to the server and cache. set(url.port, 8081, server, cache)

See Also •

Actions: append( ), delete( ), delete_matching( ), redirect( ), rewrite(url.host, regex_pattern, replacement_host), rewrite(url, regex_pattern, redirect_location)

•

Conditions: request.header.header_name=, request.header.header_name.address=, request.x_header.header_name=, request.x_header.header_name.address=, response.header.header_name=, response.x_header.header_name=, server_url=

•

Appendix D: "CPL Substitutions".

373

Volume 10: Content Policy Language Guide

transform Invokes an active_content, javascript, or URL_rewrite transformer. The invoked transformer takes effect only if the transform action is used in a define action definition block, and that block is in turn enabled by an action( ) property. Note:

Any transformed content is not cached, in contrast with content that has been sent to a virus scanning server. This means the transform action can be safely triggered based on any condition, including client identity and time of day.

Syntax transform transformer_id

where transformer_id is a user-defined identifier for a transformer definition block. This identifier is not case-sensitive. Layer and Transaction Notes •

Use in or layers.

Example ; The transform action is part of an action block enabled by a rule. url.domain=!my_site.com action.strip_active_content(yes) ; transformer definition define active_content strip_with_indication tag_replace applet

Bluecoat Admin guide

Short Description

Description

Comments

We need your help!