AlteonOS-32-6-0-AppWall For Alteon User Guide

AppWall for Alteon
USER GUIDE
Software Version 32.6.0

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 February, 2020
AppWall for Alteon User Guide
2 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Important Notices
The following important notices are presented in English, French, and German.
Important Notices
This guide is delivered subject to the following conditions and restrictions:
Copyright Radware Ltd. 2020. All rights reserved.
The copyright and all other intellectual property rights and trade secrets included in this guide are
owned by Radware Ltd.
The guide is provided to Radware customers for the sole purpose of obtaining information with
respect to the installation and use of the Radware products described in this document, and may not
be used for any other purpose.
The information contained in this guide is proprietary to Radware and must be kept in strict
confidence.
It is strictly forbidden to copy, duplicate, reproduce or disclose this guide or any part thereof without
the prior written consent of Radware.
Notice importante
Ce guide est sujet aux conditions et restrictions :
Copyright Radware Ltd. 2020. Tous droits réservés.
Le copyright ainsi que tout autre droit lié à la propriété intellectuelle et aux secrets industriels
contenus dans ce guide sont la propriété de Radware Ltd.
Ce guide d’informations est fourni à nos clients dans le cadre de l’installation et de l’usage des
produits de Radware décrits dans ce document et ne pourra être utilisé dans un but autre que celui
pour lequel il a été conçu.
Les informations répertoriées dans ce document restent la propriété de Radware et doivent être
conservées de manière confidentielle.
Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce
manuel sans avoir obtenu le consentement préalable écrit de Radware.
Wichtige Anmerkung
Dieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschränkungen ausgeliefert:
Copyright Radware Ltd. 2020. Alle Rechte vorbehalten.
Das Urheberrecht und alle anderen in diesem Handbuch enthaltenen Eigentumsrechte und
Geschäftsgeheimnisse sind Eigentum von Radware Ltd.
Dieses Handbuch wird Kunden von Radware mit dem ausschließlichen Zweck ausgehändigt,
Informationen zu Montage und Benutzung der in diesem Dokument beschriebene Produkte von
Radware bereitzustellen. Es darf für keinen anderen Zweck verwendet werden.
Die in diesem Handbuch enthaltenen Informationen sind Eigentum von Radware und müssen streng
vertraulich behandelt werden.
Es ist streng verboten, dieses Handbuch oder Teile daraus ohne vorherige schriftliche Zustimmung
von Radware zu kopieren, vervielfältigen, reproduzieren oder offen zu legen.
Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 3

Copyright Notices
The following copyright notices are presented in English, French, and German.
Copyright Notices
The programs included in this product are subject to a restricted use license and can only be used in
conjunction with this application.
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 openssl-core@openssl.org.
OpenSSL License
Copyright (c) 1998-2011 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
acknowledgement:
This product includes software developed by the OpenSSL Project for use in the OpenSSL
Toolkit. (http://www.openssl.org/)
4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote
products derived from this software without prior written permission. For written permission,
please contact openssl-core@openssl.org.
5. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in
their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
“This product includes software developed by the OpenSSL Project for use in the OpenSSL
Toolkit (http://www.openssl.org/)”
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS'' AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This
product includes software written by Tim Hudson (tjh@cryptsoft.com).
Original SSLeay License
Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
All rights reserved.
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).
The implementation was written so as to conform with Netscapes SSL.

This library is free for commercial and non-commercial use as long as the following conditions are
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 (tjh@cryptsoft.com).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be
removed.
If this package is used in a product, Eric Young should be given attribution as the author of the parts
of the library used.
This can be in the form of a textual message at program startup or in documentation (online or
textual) provided with the package.
1. Redistributions of source code must retain the copyright notice, this list of conditions and the
following disclaimer.
distribution.
3. All advertising materials mentioning features or use of this software must display the following
acknowledgement:
"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)"
The word 'cryptographic' can be left out if the 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 acknowledgment:
"This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS”' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
The 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.]
This product contains the Rijndael cipher
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)
Optimized ANSI C code for the Rijndael cipher (now AES)
@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
@author Paulo Barreto <paulo.barreto@terra.com.br>
The OnDemand Switch may use software components licensed under the GNU General Public
License Agreement Version 2 (GPL v.2) including LinuxBios and Filo open source projects. The
source code of the LinuxBios and Filo is available from Radware upon request. A copy of the license
can be viewed at: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.
This code is hereby placed in the public domain.

This product contains code developed by the OpenBSD Project

Copyright ©1983, 1990, 1992, 1993, 1995
The Regents of the University of California. All rights reserved.
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 product includes software developed by Markus Friedl.
This product includes software developed by Theo de Raadt.
This product includes software developed by Niels Provos
This product includes software developed by Dug Song
This product includes software developed by Aaron Campbell
This product includes software developed by Damien Miller
This product includes software developed by Kevin Steves
This product includes software developed by Daniel Kouril
This product includes software developed by Wesley Griffin
This product includes software developed by Per Allansson
This product includes software developed by Nils Nordman
This product includes software developed by Simon Wilkinson
distribution.
This product contains work derived from the RSA Data Security, Inc. MD5 Message-Digest
Algorithm. RSA Data Security, Inc. makes no representations concerning either the merchantability
of the MD5 Message - Digest Algorithm or the suitability of the MD5 Message - Digest Algorithm for
any particular purpose. It is provided “as is” without express or implied warranty of any kind.
This product contains a Access Protocol API developed by The OpenLDAP Foundation titled
“OpenLDAP Lightweight Directory Access Protocol API”. Copyright 1999-2003 The OpenLDAP
Foundation, Redwood City, California, USA. All Rights Reserved.
OpenLDAP is a registered trademark of the OpenLDAP Foundation.
The following license terms apply to the openLDAP Access Protocol API, including, without
limitations, the below list of conditions and disclaimer:
The OpenLDAP Public License
Version 2.8, 17 August 2003

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 in source form must retain copyright statements and notices,
2. Redistributions in binary form must reproduce applicable copyright statements and notices, this
list of conditions, and the following disclaimer in the documentation and/or other materials
provided with the distribution, and
3. Redistributions must contain a verbatim copy of this document.
The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished
by a version number. You may use this Software under terms of this license revision or under the
terms of any subsequent revision of the license.
THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS CONTRIBUTORS “AS IS”
AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S) OR
OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The names of the authors and copyright holders must not be used in advertising or otherwise to
promote the sale, use or other dealing in this Software without specific, written prior permission.
Title to copyright in this Software shall at all times remain with copyright holders.
OpenLDAP is a registered trademark of the OpenLDAP Foundation. Copyright 1999-2003 The
OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy and
distribute verbatim copies of this document is granted.
This product contains the ACE RADIUS library developed by Mr. Alex Agranov. Copyright ©2004-
2009, Alex Agranov <alexagr@users.sourceforge.net> All rights reserved.
The ACE RADIUS library is licensed under BSD License, which allows its use both in open-source and
commercial projects.
The license terms are as follows:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER 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.
This software includes the SNMP++v3.2.25 library Copyright ©2001-2010 Jochen Katz, Frank Fock
The SNMP++v3.2.25 library is based on SNMP++2.6 from Hewlett Packard: Copyright ©1996
Hewlett-Packard Company
ATTENTION: USE OF THIS SOFTWARE IS SUBJECT TO THE FOLLOWING TERMS.

Permission to use, copy, modify, distribute and/or sell this software and/or its documentation is
hereby granted without fee. User agrees to display the above copyright notice and this license notice
in all copies of the software and any documentation of the software. User agrees to assume all
liability for the use of the software; Hewlett-Packard and Jochen Katz make no representations
about the suitability of this software for any purpose. It is provided “AS-IS” without warranty of any
kind, either express or implied. User hereby grants a royalty-free license to any and all derivatives
based upon this software code base.
Stuttgart, Germany, Thu Sep 2 00:07:47 CEST 2010
Notice traitant du copyright

Les programmes intégrés dans ce produit sont soumis à une licence d’utilisation limitée et ne
peuvent être utilisés qu’en lien avec cette application.
L’implémentation de Rijindael par Vincent Rijmen, Antoon Bosselaers et Paulo Barreto est du
domaine public et distribuée sous les termes de la licence suivante:
@version 3.0 (Décembre 2000)
Code ANSI C code pour Rijndael (actuellement AES)
@author Paulo Barreto <paulo.barreto@terra.com.br>.
Le commutateur OnDemand peut utiliser les composants logiciels sous licence, en vertu des termes
de la licence GNU General Public License Agreement Version 2 (GPL v.2), y compris les projets à
source ouverte LinuxBios et Filo. Le code source de LinuxBios et Filo est disponible sur demande
auprès de Radware. Une copie de la licence est répertoriée sur: http://www.gnu.org/licenses/old-
licenses/gpl-2.0.html.
Ce code est également placé dans le domaine public.
Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Copyright ©1983, 1990, 1992, 1993, 1995
Les membres du conseil de l’Université de Californie. Tous droits réservés.
La distribution et l’usage sous une forme source et binaire, avec ou sans modifications, est autorisée
pour autant que les conditions suivantes soient remplies:
1. La distribution d’un code source doit inclure la notice de copyright mentionnée ci-dessus, cette
liste de conditions et l’avis de non-responsabilité suivant.
2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout
autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et
l’avis de non-responsabilité suivant.
3. Le nom de l’université, ainsi que le nom des contributeurs ne seront en aucun cas utilisés pour
approuver ou promouvoir un produit dérivé de ce programme sans l’obtention préalable d’une
autorisation écrite.
Ce produit inclut un logiciel développé par Markus Friedl.
Ce produit inclut un logiciel développé par Theo de Raadt.
Ce produit inclut un logiciel développé par Niels Provos.
Ce produit inclut un logiciel développé par Dug Song.
Ce produit inclut un logiciel développé par Aaron Campbell.
Ce produit inclut un logiciel développé par Damien Miller.
Ce produit inclut un logiciel développé par Kevin Steves.
Ce produit inclut un logiciel développé par Daniel Kouril.
Ce produit inclut un logiciel développé par Wesley Griffin.
Ce produit inclut un logiciel développé par Per Allansson.

Ce produit inclut un logiciel développé par Nils Nordman.

Ce produit inclut un logiciel développé par Simon Wilkinson.
La distribution et l’usage sous une forme source et binaire, avec ou sans modifications, est autorisée
pour autant que les conditions suivantes soient remplies:
1. La distribution d’un code source doit inclure la notice de copyright mentionnée ci-dessus, cette
liste de conditions et l’avis de non-responsabilité suivant.
2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout
autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et
l’avis de non-responsabilité suivant.
LE LOGICIEL MENTIONNÉ CI-DESSUS EST FOURNI TEL QUEL PAR LE DÉVELOPPEUR ET TOUTE
GARANTIE, EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S’Y LIMITER, TOUTE GARANTIE
IMPLICITE DE QUALITÉ MARCHANDE ET D’ADÉQUATION À UN USAGE PARTICULIER EST EXCLUE.
EN AUCUN CAS L’AUTEUR NE POURRA ÊTRE TENU RESPONSABLE DES DOMMAGES DIRECTS,
INDIRECTS, ACCESSOIRES, SPÉCIAUX, EXEMPLAIRES OU CONSÉCUTIFS (Y COMPRIS, MAIS SANS
S’Y LIMITER, L’ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D’USAGE,
DE DONNÉES OU DE PROFITS OU L’INTERRUPTION DES AFFAIRES), QUELLE QU’EN SOIT LA CAUSE
ET LA THÉORIE DE RESPONSABILITÉ, QU’IL S’AGISSE D’UN CONTRAT, DE RESPONSABILITÉ
STRICTE OU D’UN ACTE DOMMAGEABLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE), DÉCOULANT DE
QUELLE QUE FAÇON QUE CE SOIT DE L’USAGE DE CE LOGICIEL, MÊME S’IL A ÉTÉ AVERTI DE LA
POSSIBILITÉ D’UN TEL DOMMAGE.
Copyrightvermerke
Die in diesem Produkt enthalten Programme unterliegen einer eingeschränkten Nutzungslizenz und
können nur in Verbindung mit dieser Anwendung benutzt werden.
Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist
öffentlich zugänglich und wird unter folgender Lizenz vertrieben:
@version 3.0 (December 2000)
Optimierter ANSI C Code für den Rijndael cipher (jetzt AES)
@author Paulo Barreto <paulo.barreto@terra.com.br>
Der OnDemand Switch verwendet möglicherweise Software, die im Rahmen der DNU Allgemeine
Öffentliche Lizenzvereinbarung Version 2 (GPL v.2) lizensiert sind, einschließlich LinuxBios und Filo
Open Source-Projekte. Der Quellcode von LinuxBios und Filo ist bei Radware auf Anfrage erhältlich.
Eine Kopie dieser Lizenz kann eingesehen werden unter http://www.gnu.org/licenses/old-licenses/
gpl-2.0.html.
Dieser Code wird hiermit allgemein zugänglich gemacht.
Dieses Produkt enthält einen vom OpenBSD-Projekt entwickelten Code
Copyright ©1983, 1990, 1992, 1993, 1995
The Regents of the University of California. Alle Rechte vorbehalten.
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind
unter folgenden Bedingungen erlaubt:
1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss beibehalten.
2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere
Materialien, die mit verteilt werden, reproduzieren.
3. Weder der Name der Universität noch die Namen der Beitragenden dürfen ohne ausdrückliche
vorherige schriftliche Genehmigung verwendet werden, um von dieser Software abgeleitete
Produkte zu empfehlen oder zu bewerben.

Dieses Produkt enthält von Markus Friedl entwickelte Software.

Dieses Produkt enthält von Theo de Raadt entwickelte Software.
Dieses Produkt enthält von Niels Provos entwickelte Software.
Dieses Produkt enthält von Dug Song entwickelte Software.
Dieses Produkt enthält von Aaron Campbell entwickelte Software.
Dieses Produkt enthält von Damien Miller entwickelte Software.
Dieses Produkt enthält von Kevin Steves entwickelte Software.
Dieses Produkt enthält von Daniel Kouril entwickelte Software.
Dieses Produkt enthält von Wesley Griffin entwickelte Software.
Dieses Produkt enthält von Per Allansson entwickelte Software.
Dieses Produkt enthält von Nils Nordman entwickelte Software.
Dieses Produkt enthält von Simon Wilkinson entwickelte Software.
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind
unter folgenden Bedingungen erlaubt:
1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss beibehalten.
2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere
Materialien, die mit verteilt werden, reproduzieren.
SÄMTLICHE VORGENANNTE SOFTWARE WIRD VOM AUTOR IM IST-ZUSTAND (“AS IS”)
BEREITGESTELLT. JEGLICHE AUSDRÜCKLICHEN ODER IMPLIZITEN GARANTIEN, EINSCHLIESSLICH,
DOCH NICHT BESCHRÄNKT AUF DIE IMPLIZIERTEN GARANTIEN DER MARKTGÄNGIGKEIT UND DER
ANWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK, SIND AUSGESCHLOSSEN.
UNTER KEINEN UMSTÄNDEN HAFTET DER AUTOR FÜR DIREKTE ODER INDIREKTE SCHÄDEN, FÜR
BEI VERTRAGSERFÜLLUNG ENTSTANDENE SCHÄDEN, FÜR BESONDERE SCHÄDEN, FÜR
SCHADENSERSATZ MIT STRAFCHARAKTER, ODER FÜR FOLGESCHÄDEN EINSCHLIESSLICH, DOCH
NICHT BESCHRÄNKT AUF, ERWERB VON ERSATZGÜTERN ODER ERSATZLEISTUNGEN; VERLUST AN
NUTZUNG, DATEN ODER GEWINN; ODER GESCHÄFTSUNTERBRECHUNGEN) GLEICH, WIE SIE
ENTSTANDEN SIND, UND FÜR JEGLICHE ART VON HAFTUNG, SEI ES VERTRÄGE,
GEFÄHRDUNGSHAFTUNG, ODER DELIKTISCHE HAFTUNG (EINSCHLIESSLICH FAHRLÄSSIGKEIT
ODER ANDERE), DIE IN JEGLICHER FORM FOLGE DER BENUTZUNG DIESER SOFTWARE IST, SELBST
WENN AUF DIE MÖGLICHKEIT EINES SOLCHEN SCHADENS HINGEWIESEN WURDE.
Standard Warranty
The following standard warranty is presented in English, French, and German.
Standard Warranty
Radware offers a limited warranty for all its products (“Products”). Radware hardware products are
warranted against defects in material and workmanship for a period of one year from date of
shipment. Radware software carries a standard warranty that provides bug fixes for up to 90 days
after date of purchase. Should a Product unit fail anytime during the said period(s), Radware will, at
its discretion, repair or replace the Product.
For hardware warranty service or repair, the product must be returned to a service facility
designated by Radware. Customer shall pay the shipping charges to Radware and Radware shall pay
the shipping charges in returning the product to the customer. Please see specific details outlined in
the Standard Warranty section of the customer’s purchase order.

Radware shall be released from all obligations under its Standard Warranty in the event that the
Product and/or the defective component has been subjected to misuse, neglect, accident or
improper installation, or if repairs or modifications were made by persons other than Radware
authorized service personnel, unless such repairs by others were made with the written consent of
Radware.
EXCEPT AS SET FORTH ABOVE, ALL RADWARE PRODUCTS (HARDWARE AND SOFTWARE) ARE
PROVIDED BY “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.
Garantie standard
Radware octroie une garantie limitée pour l’ensemble de ses produits (“Produits”). Le matériel
informatique (hardware) Radware est garanti contre tout défaut matériel et de fabrication pendant
une durée d’un an à compter de la date d’expédition. Les logiciels (software) Radware sont fournis
avec une garantie standard consistant en la fourniture de correctifs des dysfonctionnements du
logiciels (bugs) pendant une durée maximum de 90 jours à compter de la date d’achat. Dans
l’hypothèse où un Produit présenterait un défaut pendant ladite (lesdites) période(s), Radware
procédera, à sa discrétion, à la réparation ou à l’échange du Produit.
S’agissant de la garantie d’échange ou de réparation du matériel informatique, le Produit doit être
retourné chez un réparateur désigné par Radware. Le Client aura à sa charge les frais d’envoi du
Produit à Radware et Radware supportera les frais de retour du Produit au client. Veuillez consulter
les conditions spécifiques décrites dans la partie “Garantie Standard” du bon de commande client.
Radware est libérée de toutes obligations liées à la Garantie Standard dans l’hypothèse où le Produit
et/ou le composant défectueux a fait l’objet d’un mauvais usage, d’une négligence, d’un accident ou
d’une installation non conforme, ou si les réparations ou les modifications qu’il a subi ont été
effectuées par d’autres personnes que le personnel de maintenance autorisé par Radware, sauf si
Radware a donné son consentement écrit à ce que de telles réparations soient effectuées par ces
personnes.
SAUF DANS LES CAS PREVUS CI-DESSUS, L’ENSEMBLE DES PRODUITS RADWARE (MATERIELS ET
LOGICIELS) SONT FOURNIS “TELS QUELS” ET TOUTES GARANTIES EXPRESSES OU IMPLICITES
SONT EXCLUES, EN CE COMPRIS, MAIS SANS S’Y RESTREINDRE, LES GARANTIES IMPLICITES DE
QUALITE MARCHANDE ET D’ADÉQUATION À UNE UTILISATION PARTICULIÈRE.
Standard Garantie
Radware bietet eine begrenzte Garantie für alle seine Produkte (“Produkte”) an. Hardware Produkte
von Radware haben eine Garantie gegen Material- und Verarbeitungsfehler für einen Zeitraum von
einem Jahr ab Lieferdatum. Radware Software verfügt über eine Standard Garantie zur
Fehlerbereinigung für einen Zeitraum von bis zu 90 Tagen nach Erwerbsdatum. Sollte ein Produkt
innerhalb des angegebenen Garantiezeitraumes einen Defekt aufweisen, wird Radware das Produkt
nach eigenem Ermessen entweder reparieren oder ersetzen.
Für den Hardware Garantieservice oder die Reparatur ist das Produkt an eine von Radware
bezeichnete Serviceeinrichtung zurückzugeben. Der Kunde hat die Versandkosten für den Transport
des Produktes zu Radware zu tragen, Radware übernimmt die Kosten der Rückversendung des
Produktes an den Kunden. Genauere Angaben entnehmen Sie bitte dem Abschnitt zur Standard
Garantie im Bestellformular für Kunden.
Radware ist von sämtlichen Verpflichtungen unter seiner Standard Garantie befreit, sofern das
Produkt oder der fehlerhafte Teil zweckentfremdet genutzt, in der Pflege vernachlässigt, einem
Unfall ausgesetzt oder unsachgemäß installiert wurde oder sofern Reparaturen oder Modifikationen
von anderen Personen als durch Radware autorisierten Kundendienstmitarbeitern vorgenommen
wurden, es sei denn, diese Reparatur durch besagte andere Personen wurden mit schriftlicher
Genehmigung seitens Radware durchgeführt.

MIT AUSNAHME DES OBEN DARGESTELLTEN, SIND ALLE RADWARE PRODUKTE (HARDWARE UND
SOFTWARE) GELIEFERT “WIE GESEHEN” UND JEGLICHE AUSDRÜCKLICHEN ODER
STILLSCHWEIGENDEN GARANTIEN, EINSCHLIESSLICH ABER NICHT BEGRENZT AUF
STILLSCHWEIGENDE GEWÄHRLEISTUNG DER MARKTFÄHIGKEIT UND EIGNUNG FÜR EINEN
BESTIMMTEN ZWECK AUSGESCHLOSSEN.
Limitations on Warranty and Liability

The following limitations on warranty and liability are presented in English, French, and German.
Limitations on Warranty and Liability

IN NO EVENT SHALL RADWARE LTD. OR ANY OF ITS AFFILIATED ENTITIES BE LIABLE FOR ANY
DAMAGES INCURRED BY THE USE OF THE PRODUCTS (INCLUDING BOTH HARDWARE AND
SOFTWARE) DESCRIBED IN THIS USER GUIDE, OR BY ANY DEFECT OR INACCURACY IN THIS USER
GUIDE ITSELF. THIS INCLUDES BUT IS NOT LIMITED TO 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). THE ABOVE LIMITATIONS WILL APPLY EVEN IF RADWARE HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF IMPLIED WARRANTIES OR LIABILITY FOR INCIDENTAL OR
CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU.
Limitations de la Garantie et Responsabilité

RADWARE LTD. OU SES ENTITIES AFFILIES NE POURRONT EN AUCUN CAS ETRE TENUES
RESPONSABLES DES DOMMAGES SUBIS DU FAIT DE L’UTILISATION DES PRODUITS (EN CE
COMPRIS LES MATERIELS ET LES LOGICIELS) DECRITS DANS CE MANUEL D’UTILISATION, OU DU
FAIT DE DEFAUT OU D’IMPRECISIONS DANS CE MANUEL D’UTILISATION, EN CE COMPRIS, SANS
TOUTEFOIS QUE CETTE ENUMERATION SOIT CONSIDEREE COMME LIMITATIVE, TOUS DOMMAGES
DIRECTS, INDIRECTS, ACCIDENTELS, SPECIAUX, EXEMPLAIRES, OU ACCESSOIRES (INCLUANT,
MAIS SANS S’Y RESTREINDRE, LA FOURNITURE DE PRODUITS OU DE SERVICES DE
REMPLACEMENT; LA PERTE D’UTILISATION, DE DONNEES OU DE PROFITS; OU L’INTERRUPTION
DES AFFAIRES). LES LIMITATIONS CI-DESSUS S’APPLIQUERONT QUAND BIEN MEME RADWARE A
ETE INFORMEE DE LA POSSIBLE EXISTENCE DE CES DOMMAGES. CERTAINES JURIDICTIONS
N’ADMETTANT PAS LES EXCLUSIONS OU LIMITATIONS DE GARANTIES IMPLICITES OU DE
RESPONSABILITE EN CAS DE DOMMAGES ACCESSOIRES OU INDIRECTS, LESDITES LIMITATIONS
OU EXCLUSIONS POURRAIENT NE PAS ETRE APPLICABLE DANS VOTRE CAS.
Haftungs- und Gewährleistungsausschluss

IN KEINEM FALL IST RADWARE LTD. ODER EIN IHR VERBUNDENES UNTERNEHMEN HAFTBAR FÜR
SCHÄDEN, WELCHE BEIM GEBRAUCH DES PRODUKTES (HARDWARE UND SOFTWARE) WIE IM
BENUTZERHANDBUCH BESCHRIEBEN, ODER AUFGRUND EINES FEHLERS ODER EINER
UNGENAUIGKEIT IN DIESEM BENUTZERHANDBUCH SELBST ENTSTANDEN SIND. DAZU GEHÖREN
UNTER ANDEREM (OHNE DARAUF BEGRENZT ZU SEIN) JEGLICHE DIREKTEN; IDIREKTEN; NEBEN;
SPEZIELLEN, BELEGTEN ODER FOLGESCHÄDEN (EINSCHLIESSLICH ABER NICHT BEGRENZT AUF
BESCHAFFUNG ODER ERSATZ VON WAREN ODER DIENSTEN, NUTZUNGSAUSFALL, DATEN- ODER
GEWINNVERLUST ODER BETRIEBSUNTERBRECHUNGEN). DIE OBEN GENANNTEN BEGRENZUNGEN
GREIFEN AUCH, SOFERN RADWARE AUF DIE MÖGLICHKEIT EINES SOLCHEN SCHADENS
HINGEWIESEN WORDEN SEIN SOLLTE. EINIGE RECHTSORDNUNGEN LASSEN EINEN AUSSCHLUSS
ODER EINE BEGRENZUNG STILLSCHWEIGENDER GARANTIEN ODER HAFTUNGEN BEZÜGLICH
NEBEN- ODER FOLGESCHÄDEN NICHT ZU, SO DASS DIE OBEN DARGESTELLTE BEGRENZUNG ODER
DER AUSSCHLUSS SIE UNTER UMSTÄNDEN NICHT BETREFFEN WIRD.

Safety Instructions
The following safety instructions are presented in English, French, and German.
Safety Instructions
CAUTION
A readily accessible disconnect device shall be incorporated in the building installation wiring.
Due to the risks of electrical shock, and energy, mechanical, and fire hazards, any procedures that
involve opening panels or changing components must be performed by qualified service personnel
only.
To reduce the risk of fire and electrical shock, disconnect the device from the power line before
removing cover or panels.
The following figure shows the caution label that is attached to Radware platforms with dual power
supplies.
Figure 1: Electrical Shock Hazard Label
DUAL-POWER-SUPPLY-SYSTEM SAFETY WARNING IN CHINESE

The following figure is the warning for Radware platforms with dual power supplies.
Figure 2: Dual-Power-Supply-System Safety Warning in Chinese
Translation of Dual-Power-Supply-System Safety Warning in Chinese:

This unit has more than one power supply. Disconnect all power supplies before maintenance to
avoid electric shock.
SERVICING
Do not perform any servicing other than that contained in the operating instructions unless you are
qualified to do so. There are no serviceable parts inside the unit.
HIGH VOLTAGE
Any adjustment, maintenance, and repair of the opened instrument under voltage must be avoided
as much as possible and, when inevitable, must be carried out only by a skilled person who is aware
of the hazard involved.
Capacitors inside the instrument may still be charged even if the instrument has been disconnected
from its source of supply.

GROUNDING
Before connecting this device to the power line, the protective earth terminal screws of this device
must be connected to the protective earth in the building installation.
LASER
This equipment is a Class 1 Laser Product in accordance with IEC60825 - 1: 1993 + A1:1997 +
A2:2001 Standard.
FUSES
Make sure that only fuses with the required rated current and of the specified type are used for
replacement. The use of repaired fuses and the short-circuiting of fuse holders must be avoided.
Whenever it is likely that the protection offered by fuses has been impaired, the instrument must be
made inoperative and be secured against any unintended operation.
LINE VOLTAGE
Before connecting this instrument to the power line, make sure the voltage of the power source
matches the requirements of the instrument. Refer to the Specifications for information about the
correct power rating for the device.
48V DC-powered platforms have an input tolerance of 36-72V DC.
SPECIFICATION CHANGES
Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a Class A digital
device pursuant to Part 15B of the FCC Rules and EN55022 Class A, EN 55024; EN 61000-3-2; EN
61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11For CE MARK Compliance.
These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment generates, uses and can
radiate radio frequency energy and, if not installed and used in accordance with the instruction
manual, may cause harmful interference to radio communications. Operation of this equipment in a
residential area is likely to cause harmful interference in which case the user is required to correct
the interference at his own expense.
SPECIAL NOTICE FOR NORTH AMERICAN USERS
For North American power connection, select a power supply cord that is UL Listed and CSA Certified
3 - conductor, [18 AWG], terminated in a molded on plug cap rated 125 V, [10 A], with a minimum
length of 1.5m [six feet] but no longer than 4.5m...For European connection, select a power supply
cord that is internationally harmonized and marked “<HAR>”, 3 - conductor, 0,75 mm2 minimum
mm2 wire, rated 300 V, with a PVC insulated jacket. The cord must have a molded on plug cap rated
250 V, 3 A.
RESTRICT AREA ACCESS
The DC powered equipment should only be installed in a Restricted Access Area.
INSTALLATION CODES
This device must be installed according to country national electrical codes. For North America,
equipment must be installed in accordance with the US National Electrical Code, Articles 110 - 16,
110 -17, and 110 -18 and the Canadian Electrical Code, Section 12.
INTERCONNECTION OF UNITS
Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or
DP-2. (Note- when residing in non LPS circuit)
OVERCURRENT PROTECTION
A readily accessible listed branch-circuit over current protective device rated 15 A must be
incorporated in the building wiring for each power input.

REPLACEABLE BATTERIES
If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type,
then an explosion may occur. This is the case for some Lithium batteries and the following is
applicable:
• If the battery is placed in an Operator Access Area, there is a marking close to the battery or
a statement in both the operating and service instructions.
• If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a
statement in the service instructions.
This marking or statement includes the following text warning:

CAUTION
RISK OF EXPLOSION IF BATTERY IS REPLACED BY AN INCORRECT BATTERY TYPE.
DISPOSE OF USED BATTERIES ACCORDING TO THE INSTRUCTIONS.
Caution – To Reduce the Risk of Electrical Shock and Fire
1. This equipment is designed to permit connection between the earthed conductor of the DC
supply circuit and the earthing conductor equipment. See Installation Instructions.
2. All servicing must be undertaken only by qualified service personnel. There are not user
serviceable parts inside the unit.
3. DO NOT plug in, turn on or attempt to operate an obviously damaged unit.
4. Ensure that the chassis ventilation openings in the unit are NOT BLOCKED.
5. Replace a blown fuse ONLY with the same type and rating as is marked on the safety label
adjacent to the power inlet, housing the fuse.
6. Do not operate the device in a location where the maximum ambient temperature exceeds
40°C/104°F.
7. Be sure to unplug the power supply cord from the wall socket BEFORE attempting to remove
and/or check the main power fuse.
CLASS 1 LASER PRODUCT AND REFERENCE TO THE MOST RECENT LASER STANDARDS IEC 60
825-1:1993 + A1:1997 + A2:2001 AND EN 60825-1:1994+A1:1996+ A2:2001
AC units for Denmark, Finland, Norway, Sweden (marked on product):
• Denmark - “Unit is class I - unit to be used with an AC cord set suitable with Denmark
deviations. The cord includes an earthing conductor. The Unit is to be plugged into a wall socket
outlet which is connected to a protective earth. Socket outlets which are not connected to earth
are not to be used!”
• Finland - (Marking label and in manual) - “Laite on liitettävä suojamaadoituskoskettimilla
varustettuun pistorasiaan”
• Norway (Marking label and in manual) - “Apparatet må tilkoples jordet stikkontakt”
• Unit is intended for connection to IT power systems for Norway only.
• Sweden (Marking label and in manual) - “Apparaten skall anslutas till jordat uttag.”
To connect the power connection:

1. Connect the power cable to the main socket, located on the rear panel of the device.
2. Connect the power cable to the grounded AC outlet.
CAUTION
Risk of electric shock and energy hazard. Disconnecting one power supply disconnects only one
power supply module. To isolate the unit completely, disconnect all power supplies.
Instructions de sécurité
AVERTISSEMENT
Un dispositif de déconnexion facilement accessible sera incorporé au câblage du bâtiment.

En raison des risques de chocs électriques et des dangers énergétiques, mécaniques et d’incendie,
chaque procédure impliquant l’ouverture des panneaux ou le remplacement de composants sera
exécutée par du personnel qualifié.
Pour réduire les risques d’incendie et de chocs électriques, déconnectez le dispositif du bloc
d’alimentation avant de retirer le couvercle ou les panneaux.
La figure suivante montre l’étiquette d’avertissement apposée sur les plateformes Radware dotées
de plus d’une source d’alimentation électrique.
Figure 3: Étiquette d’avertissement de danger de chocs électriques
AVERTISSEMENT DE SÉCURITÉ POUR LES SYSTÈMES DOTÉS DE DEUX SOURCES D’ALIMENTATION

ÉLECTRIQUE (EN CHINOIS)
La figure suivante représente l’étiquette d’avertissement pour les plateformes Radware dotées de
deux sources d’alimentation électrique.
Figure 4: Avertissement de sécurité pour les systèmes dotes de deux sources d’alimentation
électrique (en chinois)
Traduction de la Avertissement de sécurité pour les systèmes dotes de deux sources d’alimentation
électrique (en chinois):
Cette unité est dotée de plus d’une source d’alimentation électrique. Déconnectez toutes les sources
d’alimentation électrique avant d’entretenir l’appareil ceci pour éviter tout choc électrique.
ENTRETIEN
N’effectuez aucun entretien autre que ceux répertoriés dans le manuel d’instructions, à moins d’être
qualifié en la matière. Aucune pièce à l’intérieur de l’unité ne peut être remplacée ou réparée.
HAUTE TENSION
Tout réglage, opération d’entretien et réparation de l’instrument ouvert sous tension doit être évité.
Si cela s’avère indispensable, confiez cette opération à une personne qualifiée et consciente des
dangers impliqués.
Les condensateurs au sein de l’unité risquent d’être chargés même si l’unité a été déconnectée de la
source d’alimentation électrique.
MISE A LA TERRE
Avant de connecter ce dispositif à la ligne électrique, les vis de protection de la borne de terre de
cette unité doivent être reliées au système de mise à la terre du bâtiment.

LASER
Cet équipement est un produit laser de classe 1, conforme à la norme IEC60825 - 1: 1993 + A1:
1997 + A2: 2001.
FUSIBLES
Assurez-vous que, seuls les fusibles à courant nominal requis et de type spécifié sont utilisés en
remplacement. L’usage de fusibles réparés et le court-circuitage des porte-fusibles doivent être
évités. Lorsqu’il est pratiquement certain que la protection offerte par les fusibles a été détériorée,
l’instrument doit être désactivé et sécurisé contre toute opération involontaire.
TENSION DE LIGNE
Avant de connecter cet instrument à la ligne électrique, vérifiez que la tension de la source
d’alimentation correspond aux exigences de l’instrument. Consultez les spécifications propres à
l’alimentation nominale correcte du dispositif.
Les plateformes alimentées en 48 CC ont une tolérance d’entrée comprise entre 36 et 72 V CC.
MODIFICATIONS DES SPÉCIFICATIONS
Les spécifications sont sujettes à changement sans notice préalable.
Remarque: Cet équipement a été testé et déclaré conforme aux limites définies pour un appareil
numérique de classe A, conformément au paragraphe 15B de la réglementation FCC et EN55022
Classe A, EN 55024, EN 61000-3-2; EN 61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8, et IEC
61000-4-11, pour la marque de conformité de la CE. Ces limites sont fixées pour fournir une
protection raisonnable contre les interférences nuisibles, lorsque l’équipement est utilisé dans un
environnement commercial. Cet équipement génère, utilise et peut émettre des fréquences radio et,
s’il n’est pas installé et utilisé conformément au manuel d’instructions, peut entraîner des
interférences nuisibles aux communications radio. Le fonctionnement de cet équipement dans une
zone résidentielle est susceptible de provoquer des interférences nuisibles, auquel cas l’utilisateur
devra corriger le problème à ses propres frais.
NOTICE SPÉCIALE POUR LES UTILISATEURS NORD-AMÉRICAINS
Pour un raccordement électrique en Amérique du Nord, sélectionnez un cordon d’alimentation
homologué UL et certifié CSA 3 - conducteur, [18 AWG], muni d’une prise moulée à son extrémité,
de 125 V, [10 A], d’une longueur minimale de 1,5 m [six pieds] et maximale de 4,5m...Pour la
connexion européenne, choisissez un cordon d’alimentation mondialement homologué et marqué
“<HAR>”, 3 - conducteur, câble de 0,75 mm2 minimum, de 300 V, avec une gaine en PVC isolée. La
prise à l’extrémité du cordon, sera dotée d’un sceau moulé indiquant: 250 V, 3 A.
ZONE A ACCÈS RESTREINT
L’équipement alimenté en CC ne pourra être installé que dans une zone à accès restreint.
CODES D’INSTALLATION
Ce dispositif doit être installé en conformité avec les codes électriques nationaux. En Amérique du
Nord, l’équipement sera installé en conformité avec le code électrique national américain, articles
110-16, 110 -17, et 110 -18 et le code électrique canadien, Section 12.
INTERCONNEXION DES UNÎTES
Les câbles de connexion à l’unité RS232 et aux interfaces Ethernet seront certifiés UL, type DP-1 ou
DP-2. (Remarque- s’ils ne résident pas dans un circuit LPS).
PROTECTION CONTRE LES SURCHARGES
Un circuit de dérivation, facilement accessible, sur le dispositif de protection du courant de 15 A doit
être intégré au câblage du bâtiment pour chaque puissance consommée.

BATTERIES REMPLAÇABLES
Si l’équipement est fourni avec une batterie, et qu’elle est remplacée par un type de batterie
incorrect, elle est susceptible d’exploser. C’est le cas pour certaines batteries au lithium, les
éléments suivants sont donc applicables:
• Si la batterie est placée dans une zone d’accès opérateur, une marque est indiquée sur la
batterie ou une remarque est insérée, aussi bien dans les instructions d’exploitation que
d’entretien.
• Si la batterie est placée ailleurs dans l’équipement, une marque est indiquée sur la batterie ou
une remarque est insérée dans les instructions d’entretien.
Cette marque ou remarque inclut l’avertissement textuel suivant:

AVERTISSEMENT
RISQUE D’EXPLOSION SI LA BATTERIE EST REMPLACÉE PAR UN MODÈLE INCORRECT.
METTRE AU REBUT LES BATTERIES CONFORMÉMENT AUX INSTRUCTIONS.
Attention - Pour réduire les risques de chocs électriques et d’incendie
1. Cet équipement est conçu pour permettre la connexion entre le conducteur de mise à la terre du
circuit électrique CC et l’équipement de mise à la terre. Voir les instructions d’installation.
2. Tout entretien sera entrepris par du personnel qualifié. Aucune pièce à l’intérieur de l’unité ne
peut être remplacée ou réparée.
3. NE branchez pas, n’allumez pas ou n’essayez pas d’utiliser une unité manifestement
endommagée.
4. Vérifiez que l’orifice de ventilation du châssis dans l’unité n’est PAS OBSTRUE.
5. Remplacez le fusible endommagé par un modèle similaire de même puissance, tel qu’indiqué sur
l’étiquette de sécurité adjacente à l’arrivée électrique hébergeant le fusible.
6. Ne faites pas fonctionner l’appareil dans un endroit, où la température ambiante dépasse la
valeur maximale autorisée. 40°C/104°F.
7. Débranchez le cordon électrique de la prise murale AVANT d’essayer de retirer et/ou de vérifier
le fusible d’alimentation principal.
PRODUIT LASER DE CLASSE 1 ET RÉFÉRENCE AUX NORMES LASER LES PLUS RÉCENTES: IEC 60
825-1: 1993 + A1: 1997 + A2: 2001 ET EN 60825-1: 1994+A1: 1996+ A2: 2001
Unités à CA pour le Danemark, la Finlande, la Norvège, la Suède (indiqué sur le produit):
• Danemark - Unité de classe 1 - qui doit être utilisée avec un cordon CA compatible avec les
déviations du Danemark. Le cordon inclut un conducteur de mise à la terre. L’unité sera
branchée à une prise murale, mise à la terre. Les prises non-mises à la terre ne seront pas
utilisées!
• Finlande (Étiquette et inscription dans le manuel) - Laite on liitettävä
suojamaadoituskoskettimilla varustettuun pistorasiaan
• Norvège (Étiquette et inscription dans le manuel) - Apparatet må tilkoples jordet stikkontakt
• L’unité peut être connectée à un système électrique IT (en Norvège uniquement).
• Suède (Étiquette et inscription dans le manuel) - Apparaten skall anslutas till jordat uttag.
Pour brancher à l’alimentation électrique:

1. Branchez le câble d’alimentation à la prise principale, située sur le panneau arrière de l’unité.
2. Connectez le câble d’alimentation à la prise CA mise à la terre.
AVERTISSEMENT
Risque de choc électrique et danger énergétique. La déconnexion d’une source d’alimentation
électrique ne débranche qu’un seul module électrique. Pour isoler complètement l’unité, débranchez
toutes les sources d’alimentation électrique.

ATTENTION
Risque de choc et de danger électriques. Le débranchement d’une seule alimentation stabilisée ne
débranche qu’un module “Alimentation Stabilisée”. Pour Isoler complètement le module en cause, il
faut débrancher toutes les alimentations stabilisées.
Attention: Pour Réduire Les Risques d’Électrocution et d’Incendie
1. Toutes les opérations d’entretien seront effectuées UNIQUEMENT par du personnel d’entretien
qualifié. Aucun composant ne peut être entretenu ou remplacée par l’utilisateur.
2. NE PAS connecter, mettre sous tension ou essayer d’utiliser une unité visiblement défectueuse.
3. Assurez-vous que les ouvertures de ventilation du châssis NE SONT PAS OBSTRUÉES.
4. Remplacez un fusible qui a sauté SEULEMENT par un fusible du même type et de même
capacité, comme indiqué sur l’étiquette de sécurité proche de l’entrée de l’alimentation qui
contient le fusible.
5. NE PAS UTILISER l’équipement dans des locaux dont la température maximale dépasse 40
degrés Centigrades.
6. Assurez vous que le cordon d’alimentation a été déconnecté AVANT d’essayer de l’enlever et/ou
vérifier le fusible de l’alimentation générale.
Sicherheitsanweisungen
VORSICHT
Die Elektroinstallation des Gebäudes muss ein unverzüglich zugängliches Stromunterbrechungsgerät
integrieren.
Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr dürfen Vorgänge,
in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschließlich von
qualifiziertem Servicepersonal durchgeführt werden.
Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gerät vor der Entfernung der
Abdeckung oder der Paneele von der Stromversorgung getrennt werden.
Folgende Abbildung zeigt das VORSICHT-Etikett, das auf die Radware-Plattformen mit
Doppelspeisung angebracht ist.
Figure 5: Warnetikett Stromschlaggefahr
SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

Die folgende Abbildung ist die Warnung für Radware-Plattformen mit Doppelspeisung.

Figure 6: Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung
Übersetzung von Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung:

Die Einheit verfügt über mehr als eine Stromversorgungsquelle. Ziehen Sie zur Verhinderung von
Stromschlag vor Wartungsarbeiten sämtliche Stromversorgungsleitungen ab.
WARTUNG
Führen Sie keinerlei Wartungsarbeiten aus, die nicht in der Betriebsanleitung angeführt sind, es sei
denn, Sie sind dafür qualifiziert. Es gibt innerhalb des Gerätes keine wartungsfähigen Teile.
HOCHSPANNUNG
Jegliche Einstellungs-, Instandhaltungs- und Reparaturarbeiten am geöffneten Gerät unter
Spannung müssen so weit wie möglich vermieden werden. Sind sie nicht vermeidbar, dürfen sie
ausschließlich von qualifizierten Personen ausgeführt werden, die sich der Gefahr bewusst sind.
Innerhalb des Gerätes befindliche Kondensatoren können auch dann noch Ladung enthalten, wenn
das Gerät von der Stromversorgung abgeschnitten wurde.
ERDUNG
Bevor das Gerät an die Stromversorgung angeschlossen wird, müssen die Schrauben der
Erdungsleitung des Gerätes an die Erdung der Gebäudeverkabelung angeschlossen werden.
LASER
Dieses Gerät ist ein Laser-Produkt der Klasse 1 in Übereinstimmung mit IEC60825 - 1: 1993 +
A1:1997 + A2:2001 Standard.
SICHERUNGEN
Vergewissern Sie sich, dass nur Sicherungen mit der erforderlichen Stromstärke und der
angeführten Art verwendet werden. Die Verwendung reparierter Sicherungen sowie die
Kurzschließung von Sicherungsfassungen muss vermieden werden. In Fällen, in denen
wahrscheinlich ist, dass der von den Sicherungen gebotene Schutz beeinträchtigt ist, muss das
Gerät abgeschaltet und gegen unbeabsichtigten Betrieb gesichert werden.
LEITUNGSSPANNUNG
Vor Anschluss dieses Gerätes an die Stromversorgung ist zu gewährleisten, dass die Spannung der
Stromquelle den Anforderungen des Gerätes entspricht. Beachten Sie die technischen Angaben
bezüglich der korrekten elektrischen Werte des Gerätes.
Plattformen mit 48 V DC verfügen über eine Eingangstoleranz von 36-72 V DC.
ÄNDERUNGEN DER TECHNISCHEN ANGABEN
Änderungen der technischen Spezifikationen bleiben vorbehalten.
Hinweis: Dieses Gerät wurde geprüft und entspricht den Beschränkungen von digitalen Geräten der
Klasse 1 gemäß Teil 15B FCC-Vorschriften und EN55022 Klasse A, EN55024; EN 61000-3-2; EN; IEC
61000 4-2 to 4-6, IEC 61000 4-8 und IEC 61000-4- 11 für Konformität mit der CE-Bezeichnung.
Diese Beschränkungen dienen dem angemessenen Schutz vor schädlichen Interferenzen bei Betrieb
des Gerätes in kommerziellem Umfeld. Dieses Gerät erzeugt, verwendet und strahlt
elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im
Handbuch montiert und benutzt, könnte es mit dem Funkverkehr interferieren und ihn
beeinträchtigen. Der Betrieb dieses Gerätes in Wohnbereichen wird höchstwahrscheinlich zu
schädlichen Interferenzen führen. In einem solchen Fall wäre der Benutzer verpflichtet, diese
Interferenzen auf eigene Kosten zu korrigieren.

BESONDERER HINWEIS FÜR BENUTZER IN NORDAMERIKA

Wählen Sie für den Netzstromanschluss in Nordamerika ein Stromkabel, das in der UL aufgeführt
und CSA-zertifiziert ist 3 Leiter, [18 AWG], endend in einem gegossenen Stecker, für 125 V, [10 A],
mit einer Mindestlänge von 1,5 m [sechs Fuß], doch nicht länger als 4,5 m. Für europäische
Anschlüsse verwenden Sie ein international harmonisiertes, mit “<HAR>” markiertes Stromkabel,
mit 3 Leitern von mindestens 0,75 mm2, für 300 V, mit PVC-Umkleidung. Das Kabel muss in einem
gegossenen Stecker für 250 V, 3 A enden.
BEREICH MIT EINGESCHRÄNKTEM ZUGANG
Das mit Gleichstrom betriebene Gerät darf nur in einem Bereich mit eingeschränktem Zugang
montiert werden.
INSTALLATIONSCODES
Dieses Gerät muss gemäß der landesspezifischen elektrischen Codes montiert werden. In
Nordamerika müssen Geräte entsprechend dem US National Electrical Code, Artikel 110 - 16, 110 -
17 und 110 - 18, sowie dem Canadian Electrical Code, Abschnitt 12, montiert werden.
VERKOPPLUNG VON GERÄTEN Kabel für die Verbindung des Gerätes mit RS232- und Ethernet-
müssen UL-zertifiziert und vom Typ DP-1 oder DP-2 sein. (Anmerkung: bei Aufenthalt in einem
nicht-LPS-Stromkreis)
ÜBERSTROMSCHUTZ
Ein gut zugänglicher aufgeführter Überstromschutz mit Abzweigstromkreis und 15 A Stärke muss für
jede Stromeingabe in der Gebäudeverkabelung integriert sein.
AUSTAUSCHBARE BATTERIEN
Wird ein Gerät mit einer austauschbaren Batterie geliefert und für diese Batterie durch einen
falschen Batterietyp ersetzt, könnte dies zu einer Explosion führen. Dies trifft zu für manche Arten
von Lithiumsbatterien zu, und das folgende gilt es zu beachten:
• Wird die Batterie in einem Bereich für Bediener eingesetzt, findet sich in der Nähe der Batterie
eine Markierung oder Erklärung sowohl im Betriebshandbuch als auch in der Wartungsanleitung.
• Ist die Batterie an einer anderen Stelle im Gerät eingesetzt, findet sich in der Nähe der Batterie
eine Markierung oder einer Erklärung in der Wartungsanleitung.
Diese Markierung oder Erklärung enthält den folgenden Warntext:

VORSICHT
EXPLOSIONSGEFAHR, FALLS BATTERIE DURCH EINEN FALSCHEN BATTERIETYP ERSETZT
WIRD. GEBRAUCHTE BATTERIEN DEN ANWEISUNGEN ENTSPRECHEND ENTSORGEN.
• Denmark - “Unit is class I - mit Wechselstromkabel benutzen, dass für die Abweichungen in
Dänemark eingestellt ist. Das Kabel ist mit einem Erdungsdraht versehen. Das Kabel wird in eine
geerdete Wandsteckdose angeschlossen. Keine Steckdosen ohne Erdungsleitung verwenden!”
• Finland - (Markierungsetikett und im Handbuch) - Laite on liitettävä suojamaadoituskoskettimilla
varustettuun pistorasiaan
• Norway - (Markierungsetikett und im Handbuch) - Apparatet må tilkoples jordet stikkontakt
Ausschließlich für Anschluss an IT-Netzstromsysteme in Norwegen vorgesehen
• Sweden - (Markierungsetikett und im Handbuch) - Apparaten skall anslutas till jordat uttag.
Anschluss des Stromkabels:

1. Schließen Sie das Stromkabel an den Hauptanschluss auf der Rückseite des Gerätes an.
2. Schließen Sie das Stromkabel an den geerdeten Wechselstromanschluss an.
VORSICHT
Stromschlag- und Energiegefahr Die Trennung einer Stromquelle trennt nur ein
Stromversorgungsmodul von der Stromversorgung. Um das Gerät komplett zu isolieren, muss es
von der gesamten Stromversorgung getrennt werden.

Vorsicht - Zur Reduzierung der Stromschlag- und Feuergefahr

1. Dieses Gerät ist dazu ausgelegt, die Verbindung zwischen der geerdeten Leitung des
Gleichstromkreises und dem Erdungsleiter des Gerätes zu ermöglichen. Siehe
Montageanleitung.
2. Wartungsarbeiten jeglicher Art dürfen nur von qualifiziertem Servicepersonal ausgeführt
werden. Es gibt innerhalb des Gerätes keine vom Benutzer zu wartenden Teile.
3. Versuchen Sie nicht, ein offensichtlich beschädigtes Gerät an den Stromkreis anzuschließen,
einzuschalten oder zu betreiben.
4. Vergewissern Sie sich, dass sie Lüftungsöffnungen im Gehäuse des Gerätes NICHT BLOCKIERT
SIND.
5. Ersetzen Sie eine durchgebrannte Sicherung ausschließlich mit dem selben Typ und von der
selben Stärke, die auf dem Sicherheitsetikett angeführt sind, das sich neben dem
Stromkabelanschluss, am Sicherungsgehäuse.
6. Betreiben Sie das Gerät nicht an einem Standort, an dem die Höchsttemperatur der Umgebung
40°C überschreitet.
7. Vergewissern Sie sich, das Stromkabel aus dem Wandstecker zu ziehen, BEVOR Sie die
Hauptsicherung entfernen und/oder prüfen.
Electromagnetic-Interference Statements
The following statements are presented in English, French, and German.
Electromagnetic-Interference Statements
SPECIFICATION CHANGES
Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a Class A digital
device pursuant to Part 15B of the FCC Rules and EN55022 Class A, EN 55024; EN 61000-3-2; EN
61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11For CE MARK Compliance.
These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment generates, uses and can
radiate radio frequency energy and, if not installed and used in accordance with the instruction
manual, may cause harmful interference to radio communications. Operation of this equipment in a
residential area is likely to cause harmful interference in which case the user is required to correct
the interference at his own expense.
VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS
Figure 7: Statement for Class A VCCI-certified Equipment
Translation of Statement for Class A VCCI-certified Equipment:

This is a Class A product based on the standard of the Voluntary Control Council for Interference by
Information Technology Equipment (VCCI). If this equipment is used in a domestic environment,
radio disturbance may occur, in which case, the user may be required to take corrective actions.

KCC KOREA
Figure 8: KCC—Korea Communications Commission Certificate of Broadcasting and

Communication Equipment
Figure 9: Statement For Class A KCC-certified Equipment in Korean
Translation of Statement For Class A KCC-certified Equipment in Korean:

This equipment is Industrial (Class A) electromagnetic wave suitability equipment and seller or user
should take notice of it, and this equipment is to be used in the places except for home.
BSMI
Figure 10: Statement for Class A BSMI-certified Equipment

這是甲類的資訊產品，在居住的環境使用中時，可能會造成射頻
干擾，在這種情況下，使用者會被要求採取某些適當的對策。
Translation of Statement for Class A BSMI-certified Equipment:

This is a Class A product, in use in a residential environment, it may cause radio interference in
which case the user will be required to take adequate measures.
Déclarations sur les Interférences Électromagnétiques

MODIFICATIONS DES SPÉCIFICATIONS
Les spécifications sont sujettes à changement sans notice préalable.
Remarque: Cet équipement a été testé et déclaré conforme aux limites définies pour un appareil
numérique de classe A, conformément au paragraphe 15B de la réglementation FCC et EN55022
Classe A, EN 55024, EN 61000-3-2; EN 61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8, et IEC
61000-4-11, pour la marque de conformité de la CE. Ces limites sont fixées pour fournir une
protection raisonnable contre les interférences nuisibles, lorsque l’équipement est utilisé dans un
environnement commercial. Cet équipement génère, utilise et peut émettre des fréquences radio et,
s’il n’est pas installé et utilisé conformément au manuel d’instructions, peut entraîner des
interférences nuisibles aux communications radio. Le fonctionnement de cet équipement dans une
zone résidentielle est susceptible de provoquer des interférences nuisibles, auquel cas l’utilisateur
devra corriger le problème à ses propres frais.
DÉCLARATIONS SUR LES INTERFÉRENCES ÉLECTROMAGNÉTIQUES VCCI

Figure 11: Déclaration pour l’équipement de classe A certifié VCCI
Traduction de la Déclaration pour l’équipement de classe A certifié VCCI:

Il s’agit d’un produit de classe A, basé sur la norme du Voluntary Control Council for Interference by
Information Technology Equipment (VCCI). Si cet équipement est utilisé dans un environnement
domestique, des perturbations radioélectriques sont susceptibles d’apparaître. Si tel est le cas,
l’utilisateur sera tenu de prendre des mesures correctives.
KCC Corée
Figure 12: KCC—Certificat de la commission des communications de Corée pour les equipements de
radiodiffusion et communication.
Figure 13: Déclaration pour l’équipement de classe A certifié KCC en langue coréenne
Translation de la Déclaration pour l’équipement de classe A certifié KCC en langue coréenne:

Cet équipement est un matériel (classe A) en adéquation aux ondes électromagnétiques et le
vendeur ou l’utilisateur doit prendre cela en compte. Ce matériel est donc fait pour être utilisé
ailleurs qu’ á la maison.
BSMI
Figure 14: Déclaration pour l’équipement de classe A certifié BSMI

Translation de la Déclaration pour l’équipement de classe A certifié BSMI:

Il s’agit d’un produit de Classe A; utilisé dans un environnement résidentiel il peut provoquer des
interférences, l’utilisateur devra alors prendre les mesures adéquates.
Erklärungen zu Elektromagnetischer Interferenz

ÄNDERUNGEN DER TECHNISCHEN ANGABEN
Änderungen der technischen Spezifikationen bleiben vorbehalten.

Hinweis: Dieses Gerät wurde geprüft und entspricht den Beschränkungen von digitalen Geräten der
Klasse 1 gemäß Teil 15B FCC-Vorschriften und EN55022 Klasse A, EN55024; EN 61000-3-2; EN; IEC
61000 4-2 to 4-6, IEC 61000 4-8 und IEC 61000-4- 11 für Konformität mit der CE-Bezeichnung.
Diese Beschränkungen dienen dem angemessenen Schutz vor schädlichen Interferenzen bei Betrieb
des Gerätes in kommerziellem Umfeld. Dieses Gerät erzeugt, verwendet und strahlt
elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im
Handbuch montiert und benutzt, könnte es mit dem Funkverkehr interferieren und ihn
beeinträchtigen. Der Betrieb dieses Gerätes in Wohnbereichen wird höchstwahrscheinlich zu
schädlichen Interferenzen führen. In einem solchen Fall wäre der Benutzer verpflichtet, diese
Interferenzen auf eigene Kosten zu korrigieren.
ERKLÄRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ
Figure 15: Erklärung zu VCCI-zertifizierten Geräten der Klasse A
Übersetzung von Erklärung zu VCCI-zertifizierten Geräten der Klasse A:

Dies ist ein Produkt der Klasse A gemäß den Normen des Voluntary Control Council for Interference
by Information Technology Equipment (VCCI). Wird dieses Gerät in einem Wohnbereich benutzt,
können elektromagnetische Störungen auftreten. In einem solchen Fall wäre der Benutzer
verpflichtet, korrigierend einzugreifen.
KCC KOREA
Figure 16: KCC—Korea Communications Commission Zertifikat für Rundfunk-und

Nachrichtentechnik
Figure 17: Erklärung zu KCC-zertifizierten Geräten der Klasse A
Übersetzung von Erklärung zu KCC-zertifizierten Geräten der Klasse A:

Verkäufer oder Nutzer sollten davon Kenntnis nehmen, daß dieses Gerät der Klasse A für industriell
elektromagnetische Wellen geeignete Geräten angehört und dass diese Geräte nicht für den
heimischen Gebrauch bestimmt sind.
BSMI

Figure 18: Erklärung zu BSMI-zertifizierten Geräten der Klasse A

Übersetzung von Erklärung zu BSMI-zertifizierten Geräten der Klasse A:

Dies ist ein Class A Produkt, bei Gebrauch in einer Wohnumgebung kann es zu Funkstörungen
kommen, in diesem Fall ist der Benutzer verpflichtet, angemessene Maßnahmen zu ergreifen.
Altitude and Climate Warning

This warning only applies to The People’s Republic of China.
1. 对于在非热带气候条件下运行的设备而言，Tma：为制造商规范允许的最大环境温度，或者为 25°C，采用两
者中的较大者。
2. 关于在海拔不超过 2000m 或者在非热带气候地区使用的设备，附加警告要求如下：
关于在海拔不超过 2000m 的地区使用的设备，必须在随时可见的位置处粘贴包含如下内容或者类似用语的警告标

记、或者附件 DD 中的符号。
“ 只可在海拔不超过 2000m 的位置使用。”
关于在非热带气候地区使用的设备，必须在随时可见的位置处粘贴包含如下内容的警告标记：
附件 DD：有关新安全警告标记的说明。
DD.1 海拔警告标记
标记含义：设备的评估仅基于 2000m 以下的海拔高度，因此设备只适用于该运行条件。如果在海拔超过 2000m 的

位置使用设备，可能会存在某些安全隐患。
DD.2 气候警告标记
标记含义：设备的评估仅基于温带气候条件，因此设备只适用于该运行条件。如果在热带气候地区使用设备，可能
会存在某些安全隐患。

Document Conventions
The following describes the conventions and symbols that this guide uses:
Item Description Description Beschreibung

An example scenario Un scénario d’exemple Ein Beispielszenarium
Example
Possible damage to Endommagement Mögliche Schäden an
equipment, software, or possible de l’équipement, Gerät, Software oder
Caution: data des données ou du Daten
logiciel
Additional information Informations Zusätzliche
complémentaires Informationen
Note:
A statement and Références et Eine Erklärung und
instructions instructions Anweisungen
To
A suggestion or Une suggestion ou Ein Vorschlag oder eine
workaround solution Umgehung
Tip:
Possible physical harm to Blessure possible de Verletzungsgefahr des
the operator l’opérateur Bedieners
Warning:


Table of Contents
TABLE OF CONTENTS
Important Notices .......................................................................................................... 3
Copyright Notices .......................................................................................................... 4
Standard Warranty ...................................................................................................... 10
Limitations on Warranty and Liability ........................................................................... 12
Safety Instructions ....................................................................................................... 13
Electromagnetic-Interference Statements ................................................................... 22
Altitude and Climate Warning ...................................................................................... 26
Document Conventions ............................................................................................... 27
CHAPTER 1 – WEB APPLICATION SECURITY..................................................... 35

Overview .................................................................................................................... 35
Introduction to HTTP ................................................................................................... 36
HTTP Methods ..................................................................................................................... 36
Security Issues, Hackers and Threats ......................................................................... 36
OWASP Top Ten Vulnerabilities Classification ................................................................... 37
WASC Web Security Attack Classification .......................................................................... 39
DoS and DDoS Consideration ..................................................................................... 41
Threat Protection by AppWall ...................................................................................... 41
AppWall WAF Protection ............................................................................................. 44
CHAPTER 2 – ALTEON WEB SECURITY .............................................................. 49

AppWall Overview ....................................................................................................... 49
Authentication Gateway Overview ............................................................................... 49
AppWall and Authentication Provisioning .................................................................... 49
Licensing .............................................................................................................................. 49
Provision AppWall and Authentication on a vADC .............................................................. 50
AppWall and Authentication Management ................................................................. 51
AppWall Management Application ....................................................................................... 51
AppWall Web-Based Management Application .................................................................. 52
Context–Sensitive Help ....................................................................................................... 56
Users and Authorization Status ........................................................................................... 56
CHAPTER 3 – BASIC APPWALL CONFIGURATION ........................................... 59

Initial Configuration ...................................................................................................... 59
Configuration Options .......................................................................................................... 59
Enable AppWall and Authentication Gateway on vADC ...................................................... 61
Configure and Edit Secure Web Applications ...................................................................... 61
Authentication Servers ......................................................................................................... 62

Table of Contents
Managing Web User Roles ................................................................................................. 63

Working with Tunnels .......................................................................................................... 65
Configuring the Publisher .................................................................................................... 78
Out-Of-Path Mode ............................................................................................................... 80
Deploying AppWall with DefensePro ................................................................................... 80
Escalation ............................................................................................................................ 81
APSolute Vision Reporter ........................................................................................... 82
CHAPTER 4 – SECURITY TOOLS .......................................................................... 85

Working with Security Filters ...................................................................................... 85
Security Filter Overview ...................................................................................................... 85
Threats AppWall Protects Against ....................................................................................... 86
Setting Security Filters ........................................................................................................ 87
Activating a Security Filter .................................................................................................. 87
Setting the Security Filter Run Mode .................................................................................. 88
Refining Security Filters ...................................................................................................... 88
Security Filters in Detail .............................................................................................. 89
AllowList Security Filter ....................................................................................................... 90
BruteForce Security Filter .................................................................................................... 94
Database Security Filter ...................................................................................................... 99
FilesUpload Security Filter ................................................................................................ 100
GlobalParameters Security Filter ...................................................................................... 102
HTTPMethods Security Filter ............................................................................................ 106
Logging Security Filter ...................................................................................................... 108
SafeReply Security Filter ................................................................................................... 111
WebServices Security Filter .............................................................................................. 114
XMLSecurity Security Filter ............................................................................................... 117
Parameters Security Filter ................................................................................................. 121
PathBlocking Security Filter .............................................................................................. 126
Session Security Filter ....................................................................................................... 128
Vulnerabilities Security Filter ............................................................................................. 134
Web Application ........................................................................................................ 137
Logical Model .................................................................................................................... 137
Logical Objects .................................................................................................................. 138
Enabling/Disabling a Web Application ............................................................................... 139
Adding Hosts, and Application Paths ................................................................................ 139
Hosts ........................................................................................................................ 140
Authentication Gateway, Single Sign-on and Login Monitoring ........................................ 140
Web User Roles ................................................................................................................ 146
Authentication Gateway Implementations ......................................................................... 146
Security Page .................................................................................................................... 148
Application Path ........................................................................................................ 149
Managing Security Filters at the Application Path Level ................................................... 149
Refining Security Filters Definitions ................................................................................... 150
Host Level Configuration .......................................................................................... 151

Table of Contents
CSRF (Cross Site Request Forgery) Protection ............................................................... 151

Hotlink Protection .............................................................................................................. 152
Directory Listing ................................................................................................................ 152
URL Rewrite ..................................................................................................................... 153
Activity Tracking ................................................................................................................ 153
HSTS/Clickjacking ............................................................................................................ 154
Reply Cookie Flags ........................................................................................................... 155
Redirect Validation ........................................................................................................... 155
AppWall's Redirect Validation scans all parameters in the request (including JSON, URL and
body parameters) and looks for external or internal redirect attempts to include files. ..... 155
Defining Your Security Policy ................................................................................... 155
AppWall Protection ........................................................................................................... 156
Defining Enterprise Requirements .................................................................................... 156
Setting a Security Policy ................................................................................................... 158
User Tracking, Authentication and SSO ........................................................................... 163
Defenses Properties ................................................................................................. 164
Landing Pages .................................................................................................................. 164
Bot List .............................................................................................................................. 165
Search Engine Referer ..................................................................................................... 166
Activity Tracking Global Settings ...................................................................................... 166
Auto Policy Generation ............................................................................................. 166
Known Types of Attack Protection - Rapid Mode ............................................................. 167
Zero Day Attack Blocking - Extended Mode ..................................................................... 167
Working with Auto Policy Traffic Analysis Profiles ............................................................ 168
Security Filter Auto Policy Generation Tools .................................................................... 168
Auto Tunnel Settings Optimization ................................................................................... 173
Auto Policy Generation for Web Roles ............................................................................. 173
Auto Discovery .................................................................................................................. 174
Auto-Policy Analysis Rules ............................................................................................... 176
Site Map List ..................................................................................................................... 176
Auto Policy Generation Properties .................................................................................... 176
CHAPTER 5 – BEST PRACTICES ........................................................................ 179

Policy Changes and Their Effect on Performance .................................................... 179
Working with Events ................................................................................................. 179
Viewing Events in the Forensics View .............................................................................. 180
Hiding Sensitive Content Parameters ....................................................................... 189
Transaction ID .......................................................................................................... 189
Working with the Dashboard .................................................................................... 190
Summary Tab ................................................................................................................... 190
Properties Tab .................................................................................................................. 190
AppWall Activity Tab ......................................................................................................... 191
Tunnels Tab ...................................................................................................................... 192

Table of Contents
CHAPTER 6 – ADDITIONAL CONFIGURATION OPTIONS................................. 195

Distributing an AppWall Tunnel Policy to other AppWalls ........................................ 195
Working with AppWall Services ................................................................................ 196
IP Blocking ............................................................................................................... 196
Support for IPv6 for Web Traffic Processing ..................................................................... 196
Signature Update Service (SUS) .............................................................................. 198
Managing Security and Escalation Events Settings ................................................. 198
Managing the Event Map .................................................................................................. 199
Managing Severity Rules .................................................................................................. 199
Managing Publishing Rules ............................................................................................... 201
Managing Log Files ........................................................................................................... 202
Events ............................................................................................................................... 203
APPENDIX A – TROUBLESHOOTING ................................................................. 205

General Issues ......................................................................................................... 205
How Do I Backup the Auto Discovery Tree? ..................................................................... 205
Filters and Configuration Issues ............................................................................... 205
What is a SafeReply Security Filter? Why do I need it? .................................................... 205
Do I need the SafeReply Filter on every Application Path? .............................................. 206
Where else should I use the Brute Force Filter other than the login page? ...................... 206
How can I read old AppWall events? ................................................................................ 206
APPENDIX B – REGULAR EXPRESSIONS ......................................................... 207

Quick Reference Table ............................................................................................. 207
Escaping RegEx ....................................................................................................... 208
Regular Expression Syntax ...................................................................................... 208
Literals .............................................................................................................................. 209
Wildcard ........................................................................................................................... 209
Repeats ............................................................................................................................ 209
Non-Greedy Repeats ....................................................................................................... 209
Parenthesis ...................................................................................................................... 209
Non-Marking Parenthesis ................................................................................................. 209
Forward Look-Ahead Asserts ........................................................................................... 210
Alternatives ...................................................................................................................... 210
Sets .................................................................................................................................. 210
Character literals ............................................................................................................... 210
Line Anchors .................................................................................................................... 211
Back References .............................................................................................................. 211
Characters by Code ......................................................................................................... 212
Word Operators ................................................................................................................ 212
Buffer Operators ............................................................................................................... 212
Escape Operator .............................................................................................................. 212
Single Character Escape Sequences ............................................................................... 212
Miscellaneous Escape Sequences ................................................................................... 213

Table of Contents
APPENDIX C – CODE PAGES .............................................................................. 215

Code Page Options .................................................................................................. 215
Code Description ...................................................................................................... 216
APPENDIX D – HTTP STATUS CODES................................................................ 219
APPENDIX E – EXTRACTING ORIGINAL SOURCE IP ADDRESS FROM AN HTTP

HEADER ................................................................................................................. 221
Support for IPv6 for Web Traffic Processing ............................................................ 221
RADWARE LTD. END USER LICENSE AGREEMENT ........................................ 223

Table of Contents

CHAPTER 1 – WEB APPLICATION
SECURITY
This user guide is intended for IT professionals responsible for implementing their company’s Web
Application Security policy. It takes you through the steps required for basic initial work with
AppWall up to more advanced AppWall configurations. It is assumed that you are familiar with the
concepts and terms used within the Web Application Security industry.
This chapter provides an overview of Web Application Security including an introduction to the HTTP
protocol, the security risks to Web applications, and a description of the protection given by AppWall.
It includes the following sections:
• Overview, page 35
• Introduction to HTTP, page 36
• Security Issues, Hackers and Threats, page 36
• Threat Protection by AppWall, page 41
• AppWall WAF Protection, page 44
Overview
Strong network-level protection against attacks, such as, firewalls and intrusion detection systems,
is mandatory in all enterprise Web application environments.
However, in many cases, hacking techniques can legitimately access your Web application and
attack the back-end system using transactions that appear to be normal. These “application level”
attack techniques cannot be detected by network firewalls and intrusion detection systems. They
pass through unchecked, enabling access to sensitive information and systems.
In addition, because this activity looks like perfectly legitimate Internet traffic, the network security
team is completely unaware of these attacks until their effects are noticed.
Web Application Security makes use of software and hardware to protect Web applications from
internal and external threats.
As the tools and technology approaches used to create Web Applications change rapidly, developers
tend to spend more time in implementing these tools and technologies, and less time implementing
security in the Application. An application that has been developed with security in mind minimizes
holes and backdoors to the application. Holes and back doors leave the Application vulnerable to
potential hackers.
Security is becoming an increasingly important concern during development as applications become
more frequently accessible over networks and are, as a result, vulnerable to a wide variety of
Application-Layer threats.
Hacking or attacking Web Applications is a field of security that has no limits as to the number of
methods and techniques that can be used to gain illegal access, manipulate information or cause
damage to an enterprise. As these methods and techniques develop it is our aim to develop methods
and techniques through advanced technology to prevent harm to an application.
The following sections provide in-depth information about HTTP, the main protocol used to deliver
files and data across the Internet, as well as information on the known threats, vulnerabilities and
attack types as they are classified today by Security authorities such as the FBI, SANS (SysAdmin,
Audit, Network, Security) Institute, WASC (Web Application Security Consortium) and OWASP (Open
Web Application Security Project).

Web Application Security
Introduction to HTTP
HTTP (Hypertext Transfer Protocol) is perhaps the most significant protocol used on the Internet
today. Web services, network-enabled appliances and the growth of network computing continue to
expand the role of the HTTP protocol beyond user-driven web browsers, while increasing the number
of applications that require HTTP support.
HTTP is the network protocol used to deliver virtually all files and other data (collectively called
resources) on the World Wide Web, including HTML files, image files, query results, or anything else.
A browser, known as an HTTP client, sends requests to an HTTP server (Web server), which then
sends responses back to the client. HTTP usually takes place over TCP connections, usually to port
80, though this can be overridden and another port used.
After a successful connection, the client transmits a request message to the server, which sends a
reply message back. The simplest HTTP message is “GET URL”, to which the server replies by
sending the named document. If the document does not exist, the server will send an HTML-
encoded message stating this.
HTTP is used to transmit resources, not just files. A resource is a chunk of information that can be
identified by a URL. The most common kind of resource is a file, but a resource may also be a
dynamically-generated query result, the output of a CGI script, a document that is available in
several languages, or something else.
HTTP Methods
HTTP defines eight methods (sometimes referred to as “verbs”) indicating the desired action to be
performed on the identified resource.
• HEAD—Asks for the response identical to the one that would correspond to a GET request, but
without the response body. This is useful for retrieving meta-information written in response
headers, without having to transport the entire content.
• GET—Requests a representation of the specified resource. By far the most common method
used on the Web today. Should not be used for operations that cause side-effects (using it for
actions in web applications is a common misuse).
• POST—Submits data to be processed (for example, from an HTML form) to the identified
resource. The data is included in the body of the request. This may result in the creation of a
new resource or the updates of existing resources or both.
• PUT—Uploads a representation of the specified resource.
• DELETE—Deletes the specified resource.
• TRACE—Echoes back the received request, so that a client can see what intermediate servers
are adding or changing in the request.
• OPTIONS—Returns the HTTP methods that the server supports for specified URI. This can be
used to check the functionality of a web server by requesting '*' instead of a specific resource.
• CONNECT—Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate
SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.
Security Issues, Hackers and Threats

This section describes the various security issues, hackers and threats that are regularly monitored
by industry communities such as OWASP (Open Web Application Security Project) and WASC (Web
Application Security Consortium), who produce widely agreed upon best-practice security standards
for the World Wide Web.

OWASP Top Ten Vulnerabilities Classification

The Open Web Application Security Project (OWASP) Top Ten provides a minimum standard for Web
Application security. The OWASP Top Ten represents a broad consensus about the most critical Web
Application security flaws. Project members include a variety of security experts from around the
world who have shared their expertise to produce this list. OWASP urge all companies to adopt the
standard within their organization and start the process of ensuring that their Web Applications do
not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step
towards changing the software development culture within your organization into one that produces
secure code.
There may be many reasons why your Web Application may be vulnerable to one or more of the
OWASP Top Ten Security flaws. For example:
• The Web Application in use by your enterprise may have been created using different types of
technologies and software platforms
• The development personnel in your enterprise might not have had security in mind while
developing the Web Application or may have left back doors to the Application for maintenance.
Furthermore, it is common that the development personnel have changed jobs or have failed to
document the Application structure.
Caution: Your application is not susceptible to attack if it is not vulnerable. Maintaining the
Application constantly and keeping up-to-date with vulnerability information and fixing potential
risks in the application must be considered a priority and not an unpleasant task.
The following table summarizes the Top Ten vulnerabilities in Web Application security as classified
by OWASP.
Table 1: OWASP Top Ten Vulnerabilities
OWASP Description (OWASP) Risk (OWASP)

Vulnerability
A1 Injection flaws, such as SQL, NoSQL, OS, SQL injection attacks allow attackers
-Injection and LDAP injection, occur when untrusted to spoof identity, tamper with existing
data is sent to an interpreter as part of a data, cause repudiation issues such as
command or query. The attacker’s hostile voiding transactions or changing
data can trick the interpreter into balances, allow the complete
executing unintended commands or disclosure of all data on the system,
accessing data without proper destroy the data or make it otherwise
authorization. unavailable, and become
administrators of the database server.
A2 Application functions related to Broken Authentication vulnerability
-Broken authentication and session management allow attackers to compromise
Authentication are often implemented incorrectly, username, password, keys or session
allowing attackers to compromise token spoofing an identity to get
passwords, keys, or session tokens, or to access to confidential information,
exploit other implementation flaws to execute operation, perform system
assume other users’ identities temporarily command….
or permanently
A3 Many web applications and APIs do not Sensitive Data Expose allow attackers
- Sensitive Data properly protect sensitive data, such as to steal or modify “protected” data
Exposure financial, healthcare, and PII that conduct to credit card fraud,
identity theft, or other crimes

Table 1: OWASP Top Ten Vulnerabilities (cont.)

Vulnerability
A4 Older or poorly configured XML processors XXE vulnerability allows attackers to
- XML External evaluate external entity references within disclose access to local server files and
Entities (XXE) XML documents. External entities can be to execute remotely execution of
used to disclose internal files using the file commands. XXE exposes API
URI handler, internal file shares, internal vulnerabilities such as Access
port scanning, remote code execution, violations, Protocol attacks, invalidated
and DoS attacks. redirects, Parameter manipulations
and Irregular JSON/XML expressions.
A5 Restrictions on authenticated users’ Broken Access Control vulnerability
- Broken Access permission are not properly enforced. allow attackers to get access to
Control Attackers can exploit these flaws to access sensitive data information. Sensitive
unauthorized functionality and/or data, data may be compromised without
such as access other users ‘accounts, view extra protection, such as encryption at
sensitive files, modify other users’ data, rest or in transit, and requires special
change access rights, etc precautions when exchanged with the
browser
A6 Security misconfiguration is the most Security Misconfiguration allows
- Security common issue - typically a result of attackers to handle simple and very
Misconfiguration insecure default configurations, common weaknesses to achieve their
incomplete or ad-hoc configurations, open objectives. This problem becomes
cloud storage, misconfigured HTTP more complex when migrating to cloud
headers, and error messages exposing environments, which are not native to
sensitive data. Not only must all operating the application and require more
systems, frameworks, libraries, and knowledge to configure and secure the
applications be securely configured - they whole Cloud environment (network,
must be as well patched and upgraded in systems, services…).
a timely fashion.
A7 XSS flaws occur whenever an application Cross-Site Scripting is a common
- Cross-Site includes untrusted data in a new web technique that allows attackers to
Scripting (XSS) page without proper validation or execute scripts in the victim’s browser
escaping, or updates a web page with to hijack a user session, deface
user-supplied data using a browser API websites, and redirect users to
that can create HTML or JavaScript. malicious sites.
A8 Serialization is the process of turning “Using Components with Known
- Insecure some object into a data format that can Vulnerabilities” open a variety of
Deserialization be restored later. People often serialize additional set of possibilities where
objects in order to save them to storage, they can find more vulnerabilities and
or to transmit in a communication. access to additional resources.
Deserialization is the reverse of that
process - restructuring data stored in
some format into an object. Most popular
formats are XML and JSON.

Table 1: OWASP Top Ten Vulnerabilities (cont.)

Vulnerability
A9 Libraries, frameworks and other modules “Using Components with Known
- Using have similar privileges to the application. Vulnerabilities” open a variety of
Components with When an attacker exploits such a additional set of possibilities where
Known component, It may result in a serious data they can find more vulnerabilities and
Vulnerabilities loss or server takeover. Applications and access to additional resources.
APIs using components with known
vulnerabilities undermine application
defenses and enabling attacks
A10 Insufficient logging and monitoring, “Insufficient Logging & Monitoring”
- Insufficient coupled with missing or ineffective refers to the ability of the
Logging & integration with incident response, allows organizations to quickly detect and
Monitoring attackers to further attack systems, respond to a security incident.
maintain persistence, pivot to more
systems, and tamper, extract, or destroy
data. Most breach studies show time to
detect a breach is over 200 days, typically
detected by external parties rather than
internal processes or monitoring.
WASC Web Security Attack Classification

The Web Security Threat Classification is a cooperative effort to clarify and organize the threats to
the security of a web site. The members of the Web Application Security Consortium (WASC) have
created this project to develop and promote industry standard terminology for describing these
issues. Application developers, security professionals, software vendors, and compliance auditors
will have the ability to access a consistent language for web security related issues.
The WASC Threat Classification is broken-down to the following main classes:
• Authentication—Authentication threats includes attacks against validation methods used by
Web Applications to validate users, services or applications. The threats that target the
authentication process of Web Applications include the following:
— Brute Force Attacks
— Insufficient Authentication
— Weak Password Recovery Validation
• Authorization—Authorization threats includes attacks against the methods used by the Web
Application to determine whether the user, service or application has the required permissions to
perform actions. Potential hackers may attempt to manipulate the Web Application to gain
privileges to restricted areas and to perform illegal actions. These threats include the following:
— Credential/Session Prediction
— Insufficient Authorization
— Insufficient Session Expiration
— Session Fixation
• Client-Side Attacks—Client-Side attacks covers a wide range of Web Application manipulation
and abuse. A potential hacker may attempt to utilize the technology employed when a user
connects to a Web Application to attack the user. These threats include:
— Content Spoofing
— Cross-site scripting

• Command Execution—These threats involve attacks designed to execute remote commands

on the Web Application. These attacks are generally aimed at user supplied information, which
are used to create commands that result in dynamic web content. With the process left insecure,
an attacker could manipulate the command execution. These threats include:
— Buffer Overflow
— Format String Attack
— LDAP Injection
— OS Commanding
— SQL Injection
— SSI Injection
— XPath Injection
• Information Disclosure—Information Disclosure threats cover attacks designed to obtain Web
application specific system information. This information usually includes software distribution,
version numbers, or patch levels. The information may also include names and location of temp
files, backup files and others. This information may be gathered and used by a potential hacker
to locate and exploit a back door or unprotected access point to the Web application. These
threats include:
— Directory Indexing
— Information Leakage
— Path Traversal
— Predictable Resource Location
• Logical Attacks—Logical Attack threats focus on the possible exploitation of Web Application
logic flow, by a potential hacker. Application logic is a term that describes the procedure used by
the application to perform a specific action; for example, account registration, recovering
passwords, or online purchases. A hacker may bypass a specific process required by the
application; hence find a way to damage users or the application. These threats include:
— Abuse of Functionality
— Denial of Service
— Insufficient Anti-Automation
— Insufficient Process Validation
• Unclassified Application Layer Attack Types—The following table highlights attack forms,
which are not classified by any particular organization, yet they exist. These attack forms may
appear as part of any of the above classifications, or may be a result of a different class
completely.
Table 2: Unclassified Application Layer Attack Types
Form of Attack Summary Description

Parameters Tampering Manipulating elements in the URL sent to a Web site to gain illegal
access or unauthorized information. By manipulating the parameters in
the request, a potential hacker can then navigate and modify its
contents
Cookie Poisoning Changes the content of cookies from what was originally set by the
application and can forge a cookie with stolen information
Database Sabotage Injects various SQL commands to input fields or messages that affect
the regular operation of the database.
Web Services Exploiting vulnerabilities inherent in Web Services formats, structure,
Manipulation and operations as well as dictionary, and encoding manipulations
Stealth Commanding Smuggles command-statements in text fields that will be executed
within a given layer of the infrastructure

Table 2: Unclassified Application Layer Attack Types (cont.)
Form of Attack Summary Description

Debug Options Exploits vulnerabilities left open in internally developed code by using
debug constructs
Backdoor Uses the privileged/un-referenced access that applications may provide.
These are points of access to the Web application that were not
intended to be discovered by un-trusted users.
Some backdoors were intended only to be used during the application
development stage but were never removed when the application was
deployed
Manipulation of IT Exploits vulnerabilities in an integrated Internet environment, such as
Infrastructure known patterns and common files and folders
Vulnerabilities
3rd Party Exploits configuration errors in third party components, such as Web
Misconfiguration and database servers
Buffer Overflow Attacks Sends large request messages to the application, attacking either third
party or internally developed code.
Data Encoding Sends requests using different data encoding standards such as
Unicode, UTF-8, and UTF-16.
Targets variations in data encoding to pass and execute commands
within specific layers of the operating environment.
Protocol Piggyback Modifies the application protocol structure to include nested commands.
Targets variations in protocols to pass and execute commands within
specific layers of the operating environment.
Cross-Site Scripting Attacks the end user’s browser to reveal the end user’s session token,
(XSS) attack the local machine or spoof content.
DoS and DDoS Consideration

DoS and DDoS attacks attempt to consume all the critical computer or network resources in order to
make them unavailable for valid use. DDoS attacks are a major risk, because they can easily disrupt
the operations of a business and are relatively simple to conduct. DDoS attacks, which disrupt traffic
to and from targeted websites, have been increasing in both volume and severity. DDos attacks
become more complex and more robust to be mitigated. Most of them use bots. Today, bots are able
to change their own configuration using autonomous scripts making them difficult to be recognized
as a threat rather than a valid web client.
AppWall, as a WAF, provides threat mitigation for the different forms of DoS and DDoS attacks using
activity tracking and Low and Slow protection.
Threat Protection by AppWall

This section describes the protection AppWall provides, namely the security filters, against the
threats/attacks described in the previous sections.

Table 3: AppWall Threat Protection
Filter Description and Threats Protected Against

Activity Tacking for The Activity Tracking module can be set to one of two tracking modes:
DDoS protection • IP-based tracking
• Device Fingerprint-based tracking
While IP-based tracking offers the value of non-intrusive activity tracking
and detection capabilities, device fingerprint-based tracking offers IP-
agnostic source tracking. AppWall can detect bots operating in a dynamic
IP environment and activity behind a sNAT (source NAT), such as an
enterprise network or proxy. Even if the bot dynamically changes its
source IP address, its device fingerprint does not change. AppWall tracks
the device activity and correlates the source security violations across
different sessions over time.
Low and Slow protection AppWall behavioral Low and Slow attack detection (like Slowloris) is
based on:
• TCP Timeouts: to count the number of second when the web client
don't send traffic
• HTTP Timeouts: three timers allow Appwall to offer flexibility and
Layer 7 attack mitigation. The timeouts measure the client idle time
and server idle time
• -Throughput over a predefine timeframe: to measure and protect if
the amount of traffic during a timeframe is too low
Parameters Security This filter evaluates parameters sent in requests against a configured list
Filter of allowed (or not allowed) parameters configured for pre-defined rules
or range.
Threats protected against: Parameters Tampering, Unvalidated Input,
Buffer Overflow, Data Encoding
Global Parameters This filter evaluates request parameter values by applying specified
Security Filter patterns, including regular expressions, to qualifying parameters.
Threats protected against: Parameters Tampering, Unvalidated Input,
Buffer Overflow, Data Encoding
XML Security Filter This filter parses and evaluates the XML body structure of requests as
well as values encapsulated within the XML tags. Parameter names are
created using the full hierarchy of nested tags containing each value. The
created parameters are evaluated by subsequent parameter-related
security filters as defined on the Application Path level.
Threats protected against: Unvalidated Input, Buffer Overflow,
Parameters Tampering
Web Services Security This filter evaluates web service requests and generates an event when
Filter the request violates valid WSDL operations. Valid operations can be
determined by import and examination of the WSDL file.
Threats protected against: Unvalidated Input, Buffer Overflow,
Parameters Tampering, WebServices Manipulation

Table 3: AppWall Threat Protection (cont.)

Session Security Filter This filter prevents remote users from modifying the application
parameter values stored in HTML forms, and to prevent remote users
from manipulating Session state information and submitting it to the
Web Application. This filter also protects cookies, path, query, and form
parameters.
Threats protected against: Broken Access Control, Broken
Authentication and Session Management, Insecure Storage,
Authorization, Cookie Poisoning
AllowList Security Filter This filter evaluates requests based on a configured list of valid page and
method requests. Based on the evaluation it generates an event for any
request not conforming to a configured list of valid requests or stops the
request.
Threats protected against: Broken Access Control, Insecure
Configuration Management, Logical Attacks, 3rd Party Misconfiguration
Path Blocking Security This filter evaluates requests to access files and folders on the
Filter application based on a configured list of relative or specific URLs, and
generates an event when the request does not match the specified URLs.
Threats protected against: Broken Access Control, Insecure
Configuration Management, Logical Attacks
BruteForce Security This filter prevents remote users from attempting to guess the username
Filter and password of an authorized user.
Threats protected against: Broken Authentication and Session
Management, Authentication
Database Security Filter This filter evaluates request parameters for harmful SQL command
syntax, command shell attacks, and cross-site scripting. It generates an
event when the request does not match those specified in a configured
parameters list or stops the request completely.
Threats protected against: Cross Site Scripting (XSS), Injection
Flaws, Client-Side Attacks, Command Execution, Database Sabotage,
Stealth Commanding, Backdoor
Vulnerabilities Security This filter checks requests for known vulnerability patterns based on a
Filter deterministic set of rules and generates an event when a vulnerability
pattern is detected. The user can also create custom patterns to
generate events.
Threats protected against: Cross Site Scripting (XSS), Injection
Flaws, Client-Side Attacks, Command Execution, Logical Attacks, Stealth
Commanding, Debug Options, Backdoor, Manipulation of IT
Infrastructure Vulnerabilities
Safe Reply Security This filter evaluates outbound replies for the presence of sensitive
Filter information such as credit cards and Social Security numbers.
Threats protected against: Improper Error Handling, Information
Disclosure
Note: There are three additional security filters that, although not protecting against specific
threats previously mentioned in this chapter, add an extra dimension to the enterprise security
plan:
FilesUpload Security This filter evaluates uploads and generates an event when the request
Filter does not conform to the configured specification for upload locations, file
extensions, and file retrievals.

Table 3: AppWall Threat Protection (cont.)

HTTPMethods Security This filter evaluates HTTP request methods and generates an event when
Filter the request methods do not conform to the configured list of allowable
methods.
Logging Security Filter This filter provides logging capabilities for both incoming and outgoing
HTTP traffic and specifies log contents, location, size, and other
properties.
AppWall WAF Protection

The following table summarizes the Top Ten vulnerabilities in Web Application security as classified
by OWASP detailing the AppWall WAF protection.
Table 4: AppWall WAF Protection
OWASP Description (OWASP). Risk (OWASP) AppWall WAF Protection

Vulnerability
A1 Injection flaws, such as SQL injection attacks Radware WAF technology
-Injection SQL, NoSQL, OS, and LDAP allow attackers to spoof protects against Injection
injection, occur when identity, tamper with flaws by screening all user
untrusted data is sent to an existing data, cause input for known patterns of
interpreter as part of a repudiation issues such attacks and a large number
command or query. The as voiding transactions of logical rules to tell the
attacker’s hostile data can or changing balances, difference between legitimate
trick the interpreter into allow the complete user input and injection
executing unintended disclosure of all data on flaws. For example, an SQL
commands or accessing the system, destroy the injection contained in an
data without proper data or make it HTTP/S request is detected
authorization. otherwise unavailable, by identifying SQL
and become statements of parts of
administrators of the statements within the
database server. parameter value.
A2 Application functions Broken Authentication Radware WAF reduces the
-Broken related to authentication vulnerability allow attack surface in conjunction
Authentication and session management attackers to with the Software Update
are often implemented compromise username, Service (SUS), protecting
incorrectly, allowing password, keys or against exploitations of
attackers to compromise session token spoofing components with known
passwords, keys, or session an identity to get vulnerabilities by screening
tokens, or to exploit other access to confidential client requests and server
implementation flaws to information, execute responses.
assume other users’ operation, perform
identities temporarily or system command….
permanently

Table 4: AppWall WAF Protection (cont.)

Vulnerability
A3 Many web applications and Sensitive Data Expose Radware WAF combines
- Sensitive Data APIs do not properly allow attackers to steal several mechanisms to
Exposure protect sensitive data, such or modify “protected” prevent data theft.
as financial, healthcare, data that conduct to 1. Encrypt all data in transit
and PII credit card fraud,
identity theft, or other 2. Encode the traffic
crimes 3. Mask server identity
4. Replace server response
code
5. Mask sensitive information
such as credits card numbers
and social security numbers
A4 Older or poorly configured XXE vulnerability allows Radware WAF engine inspects
- XML External XML processors evaluate attackers to disclose protocols and structured
Entities (XXE) external entity references access to local server documents.
within XML documents. files and to execute • Parse HTTP/HTTPS traffic •
External entities can be remotely execution of Enforces security in POST
used to disclose internal commands. XXE requests
files using the file URI exposes API
handler, internal file shares, vulnerabilities such as • Extracts ‘key and values’ of
internal port scanning, Access violations, ‘XML
remote code execution, and Protocol attacks, and JSON’ schemas It auto-
DoS attacks. invalidated redirects, learns legitimate client
Parameter requests to create a positive
manipulations and security model as well as
Irregular JSON/XML signatures of wellknown
expressions. attacks
A5 Restrictions on Broken Access Control Radware WAF offers
- Broken Access authenticated users’ vulnerability allow Authentication Gateway
Control permission are not properly attackers to get access functionality providing single
enforced. Attackers can to sensitive data sign-on, user tracking,
exploit these flaws to information. Sensitive authentication enforcement
access unauthorized data may be and access control to the web
functionality and/or data, compromised without application based on role and
such as access other users extra protection, such profile. It validates the user
‘accounts, view sensitive as encryption at rest or input: screening size, content
files, modify other users’ in transit, and requires and type, preventing possible
data, change access rights, special precautions invalidated redirect attacks
etc when exchanged with such as Remote File Inclusion
the browser resulting in access to a
different resource than
requested.


Vulnerability
A6 Security misconfiguration is Security Radware WAF Auto Policy
- Security the most common issue - Misconfiguration allows Generation module creates
Misconfiguration typically a result of attackers to handle and applies security filters
insecure default simple and very and enforcement rules where
configurations, incomplete common weaknesses to security is misconfigured. For
or ad-hoc configurations, achieve their example: allowing access to
open cloud storage, objectives. This authorized data and
misconfigured HTTP problem becomes more resources while prohibiting
headers, and error complex when access to configuration files
messages exposing migrating to cloud or sensitive data paths
sensitive data. Not only environments, which
must all operating systems, are not native to the
frameworks, libraries, and application and require
applications be securely more knowledge to
configured - they must be configure and secure
as well patched and the whole Cloud
upgraded in a timely environment (network,
fashion. systems, services…).
A7 XSS flaws occur whenever Cross-Site Scripting is a Radware WAF technology
- Cross-Site an application includes common technique that prevents Cross-Site Scripting
Scripting (XSS) untrusted data in a new allows attackers to attempts by identifying
web page without proper execute scripts in the scripting patterns and
validation or escaping, or victim’s browser to blocking the malicious
updates a web page with hijack a user session, request
user-supplied data using a deface websites, and
browser API that can create redirect users to
HTML or JavaScript. malicious sites.
A8 Serialization is the process “Using Components Radware WAF reduces the
- Insecure of turning some object into with Known attack surface in conjunction
Deserialization a data format that can be Vulnerabilities” open a with the Software Update
restored later. People often variety of additional set Service (SUS), protecting
serialize objects in order to of possibilities where against exploitations of
save them to storage, or to they can find more components with known
transmit in a vulnerabilities and vulnerabilities by screening
communication. access to additional client requests and server
Deserialization is the resources. responses
reverse of that process -
restructuring data stored in
some format into an object.
Most popular formats are
XML and JSON.


Vulnerability
A9 Libraries, frameworks and “Using Components Radware WAF reduces the
- Using other modules have similar with Known attack surface in conjunction
Components privileges to the Vulnerabilities” open a with the Software Update
with Known application. When an variety of additional set Service (SUS), protecting
Vulnerabilities attacker exploits such a of possibilities where against exploitations of
component, It may result in they can find more components with known
a serious data loss or vulnerabilities and vulnerabilities by screening
server takeover. access to additional client requests and server
Applications and APIs using resources. responses.
components with known
vulnerabilities undermine
application defenses and
enabling attacks
A10 Insufficient logging and “Insufficient Logging & Radware WAF detailed
- Insufficient monitoring, coupled with Monitoring” refers to logging provides a
Logging & missing or ineffective the ability of the comprehensive visibility into
Monitoring integration with incident organizations to quickly the attack flow, actual HTTP
response, allows attackers detect and respond to a request and response
to further attack systems, security incident. logging, username (if
maintain persistence, pivot available) reference, security
to more systems, and violation etc. Defense
tamper, extract, or destroy Messaging is a unique
data. Most breach studies communication mechanism
show time to detect a with Radware’s DDoS
breach is over 200 days, mitigation platform,
typically detected by DefensePro, allows blocking
external parties rather than attack sources at the
internal processes or perimeter and prevent them
monitoring. from accessing additional
systems and applications.
This integration provides a
common log representation
of the attack. It also
integrates with SIEM
solutions


CHAPTER 2 – ALTEON WEB SECURITY
Alteon Web Application Security is a comprehensive security solution comprising a Web Application
Firewall, an authentication proxy, and a single sign-on solution to support large-scale deployment of
Web Application and Web services security for the distributed enterprise. This chapter introduces
the Web Application Security components and helps guide you to provision and manage them.
AppWall Overview
Web Application Security includes diverse methods and techniques that protect Web applications
from internal and external threats. Alteon Web Application Security capabilities include:
• AppWall—The Alteon integrated AppWall capability secures Web applications and enables PCI
compliance through mitigation of Web application security threats and vulnerabilities. It
prevents data theft, manipulation of sensitive corporate data, and protects customer
information. AppWall incorporates scalable intrusion detection and prevention systems that work
seamlessly to detect threats, generate events, and block both internal and external attacks
against critical corporate data without impacting day-to-day operations.
• Authentication—The integrated Authentication gateway capability reduces operational costs
by providing centralized and simplified identity and access management infrastructure, by
offloading the user authentication process, and by simplifying the identity and access
management infrastructure. The module can be used independently of, or together with, the
AppWall capability to create role-based policies.
Authentication Gateway Overview

The integrated Authentication Gateway capability reduces operational costs by providing centralized
and simplified identity and access management infrastructure, and by offloading the user
authentication process and simplifying the identity and access management infrastructure.
The module can be utilized independent of, and in conjunction with, the AppWall capability to create
role-based policies.
AppWall and Authentication Provisioning

AppWall and Authentication gateway capabilities are supported only on an Alteon platform operating
in virtualized mode (ADC-VX). To provision these capabilities on a virtual ADC instance (vADC), the
following steps are required:
• Ensure appropriate license is installed.
• Allocate AppWall and Authentication gateway resources and capacity units.
Licensing
AppWall and Authentication Gateway capabilities can be used together or separately, thus each
capability requires its own license.
The AppWall license allows for AppWall capability on the entire device.

Alteon Web Security
To view the AppWall license, on the Global Administrator Web UI navigate to Configuration >
System > Licensing and select the Feature Licenses tab.
The Authentication license allows for Authentication capability on the device and limits the number
of concurrent users that can be authenticated on the device.
To view the Authentication license, on the Global Administrator Web UI navigate to Configuration >
System > Licensing and select the Capacity Licenses tab.
To install an AppWall or Authentication license

1. On the Global Administrator Web UI navigate to Configuration > System > Licensing.
2. Enter the new license string and click Submit.
Provision AppWall and Authentication on a vADC

To provision AppWall and/or Authentication Gateway on a vADC you must set the following:
• AppWall Limit (Mbps)—determines the maximum amount of traffic that AppWall can process
on this vADC. The limit must be lower or equal to the vADC Throughput limit. The limit cannot
be set if AppWall license is not installed on the device. If this parameter is 0 (default), AppWall is
not provisioned on this vADC.
• Authentication Limit (Users)—determines the maximum number of users that can be
authenticated on this vADC. The total number of authenticated users allocated to all the device
vADCs cannot exceed licensed Authentication capacity. The limit cannot be set if AppWall license
is not installed on the device. If this parameter is 0 (default), Authentication is not provisioned
on this vADC.
• Capacity Units—for Web Application Security Processing. The following CU numbers can be
allocated: 2, and multiple of 4 (4, 8, and so on). The minimal number of CUs that can be
allocated is determined by the AppWall and Authentication Limit. All CUs allocated for Web
Application Security must be allocated on a single core (in case 2 or 4 CUs are allocated) or
occupy multiple full cores (in case of 8 and on).
Note: For more information regarding core affinity, refer to the Alteon Application Switch
Operating System Application Guide.

Alteon Web Security
To provision Web Application Security

1. On the Global Administrator Web UI, navigate to Configuration > vADC > vADC.
2. In the vADC tab, click the (Add) button to configure a new vADC, or select a vADC and click
the (Edit) button to edit the vADC.

3. In the Add vADC pane, Capacities tab enter the following parameters:
— AppWall Limit
— Authentication Limit
— Number of CUs to be allocated for Web Application Security Processing
AppWall and Authentication Management

AppWall and authentication provisioning is performed using the Alteon management interface.
This entails initial configuration, including AppWall and authentication activation on a specific Web
Application represented by a virtual service.
The security configuration and monitoring is performed using the AppWall management application
which can be launched from the Alteon Web UI.
AppWall Management Application

AppWall management is a pure Web interface.
To launch the AppWall management application, in a Web browser, enter:
https://<AppWall IP>/appwall-webui.
The Web UI runs on modern technology with a React client side and with a back-end REST API layer
based on Node.JS server. The REST APIs generated from the client-side application are
authenticated using JWT (JSON Web Token), properly securing the access to the server side.
The AppWall Management Application enables users to:

Alteon Web Security
• Configure and perform quick-click refinements of security policies.

• Assign security policies to configurable and highly granular segments of the Web Application
layer.
• Obtain and analyze real-time events and reports generated during traffic evaluation. Use
obtained information to refine current security policies. In addition, you can enable the Auto
Policy Generation feature, which gathers traffic and statistical data to determine automatic
refinements to security filters.
• Administrate user provisioning, events distribution, and other AppWall components and services.
With extensible and highly-granular security filters and policy management features, AppWall
Management Application enables users to define acceptable Web Application behavior. Any behavior
that deviates from explicit policy generates an event or triggers specific action to counter an attack.
AppWall supports RESTful API for configuration of specific settings and common flows.
To view the full RESTful API documentation, including a list of supported actions, go to:
https://<AppWall IP>/appwall-api-doc/v2/
AppWall Management Application provides centralized administration, management, reporting, and
forensics for the AppWall module. This information is presented through four views based on the
individual’s role in the organization:
• The Configuration view allows IT and/or security personnel to configure AppWall. They can also
establish and manage user privileges for viewing threat information and policies.
• The Security Policies view is where security rules and filters are defined using a flexible and
powerful interface.
• The Auto Discovery view provides linkage between the Security Policy and the physical view of
the application. This is performed by automatic detection of the entire Web Application structure
and displaying the tunnel, host, folders, files (pages), cookies and parameters related to the
application. The Auto Discovery view is available only in the Java based app.
• The Forensics view provides access to historical information, allowing users to perform detailed
analysis of event logs to identify trends and needed areas of improvement as well as generate
reports based upon the recorded events.
• The Dashboard view offers at-a-glance views of the entire Web Application’s security posture of
the enterprise. Authorized users can view real-time security events, respond to violation events,
and check on the status of servers, gateways, and monitors across the organization.
AppWall Web-Based Management Application

The AppWall Management Application workspace provides a graphical user interface (GUI) to secure
your Web server, Web Applications, and IT infrastructure. Use the AppWall Management Application
to set up initial security policies and to refine them after viewing AppWall logs.
To launch the AppWall Management Application

1. On the vADC Web UI, in the Configuration view, select Security > web Application Services.
2. Do one of the following:
— Click Dashboard, Forensics, Auto Discovery or Basic Configuration to launch the
AppWall Management Application.
— On the vADC Web UI, in the Configuration view Security tree, select Web Application
Services > Secure Web Applications.
3. Select a Secure Web Application and click Edit Security Policies to launch the AppWall
Management Application.

Alteon Web Security
Note: When TACACS is configured in Alteon, authentication to the AppWall management console is
based on the TACACS configuration and the user role (in version 31.0.230.5.5, Admin only). Alteon
send the authentication information to AppWall to allows an open connection to the AppWall
Management Application.
After opening AppWall Application Management, the main window displays.
Figure 19: Main AppWall for Alteon Application Management Window
Application Management Workspace

The AppWall Application Management graphical interface consists of the following main areas:
• Menu Bar and AppWall Management Application Toolbar, page 54
• Primary Navigation Area—View Selection, page 54
• Secondary Navigation Area—Tree View, page 55
• Display Pane—Content Area, page 56
• Status Bar, page 56

Alteon Web Security
Menu Bar and AppWall Management Application Toolbar

The Menu Bar provides basic functionality and is generally available regardless of the active view:
Table 5: AppWall Management Application Toolbar
Main Bar Menu Function

Action menu The Action menu provides a list of actions that may be applied depending on the
(accessed by current view selection. The following is an example of a possible available Action
right-clicking menu:
the device IP) • Properties—Displays Server Group properties.
• Backup/Restore—Permits backing up/restoring of configuration files.
Tools menu Choose an XML editor for editing configuration files when running the system in
Appliance mode (available only in the Configuration view).
? Clicking the ? on the top right of the menu bar displays the AppWall Online Help.
(Online Help)
The AppWall Management Application toolbar provides access to AppWall commands, wizards, and
utilities. Toolbar icons may change as you switch between the different views. The above settings
apply for a server node accessed from Configuration view.
Note: Many toolbar functions are available as right-click menus. Right-click a node to display its
menu.
Figure 20: AppWall Menu Bar and Toolbar
Primary Navigation Area—View Selection

The primary navigation area located at the top of the workspace area, contains buttons to each of
the four management application views. Each view provides a set of functions.
Table 6: Functions of Different Views
Main Bar Function

Configuration Change configuration settings of tunnels, security filters (and enable Auto Policy
generation), logs, and more. Access additional services such as Publisher, and
severity settings.
Security Policies Create and manage security policies for Web applications, modify all Web
applications, configure filters, security logs, and escalation logs, and view
security events pertaining to individual Web applications.
Auto Discovery Automatic detection of the entire Web application structure, displaying the
tunnel, host, folders, files (pages), cookies and parameters related to the
application. Available only in the Java based app.
Forensics Monitor Web application activity by viewing logs and reports of events that occur
in your Web application. Observe changes to AppWall and look out for potential
security problems.
Dashboard An overall view of status and properties of AppWall. It provides a monitoring view
of the AppWall, sets reset intervals and shows the status and properties.

Alteon Web Security
Secondary Navigation Area—Tree View

The secondary navigation area, which provides a tree view for navigating through your AppWall
configuration, is located at the left pane of the AppWall Application Management Console workspace.
Each node represents an object or component of your configuration, such as a Web application, or
security filter.
The top of the tree begins with a node representing the AppWall module.
The tree view differs depending on the selected view. Each view provides access to the features
available in the view. For example, the Security Policies tree displays the current network topology;
this is where you add your Web Applications and refine their security policies. The Configuration tree
lists the configurable tasks, services, and events in the AppWall.
Figure 21: AppWall for Alteon Configuration View

Alteon Web Security
Figure 22: AppWall fro Alteon Security Policies View
Display Pane—Content Area

The right pane, or display area, displays the window associated with the node selected from the
tree.
Status Bar
The Status Bar provides updates on the AppWall .
Figure 23: Status Bar
Context–Sensitive Help
AppWall Management Application has context-sensitive help. Click ? on the top right corner of the
window to access help on any node, toolbar button, dialog box, or window.
The Help contains a Table of Contents, Index, and a full-text search function.
Users and Authorization Status

You can view the users setup and their authorization status through a pop-up window.

Alteon Web Security
To view login user and authorizations (from all views)

1. Click on the server IP in the tree.
2. The following information is displayed:
Table 7: Viewing Login User and Authorization Status
Property Description
Server IP The IP of the server.
Admin Port The admin port number.
Server Type Type of AppWall server: Gateway.
Server Version The software version of the AppWall server, including build number.
Service Last Date and time AppWall was last started.
Started
Last Changes Date and time the last Apply was performed.
Applied
Pending Reports whether changes await an Apply before updating AppWall.
Operating Operating system on which this AppWall server is running. Can be Windows, SUN
System or Linux.
Current Status Current status of AppWall: starting, running, or stopped.
Login Requires Reports whether this login user requires authorization.
Authorization
Logged-in User Login name of user running the AppWall Management Application Console and
the name of the Group to which the user belongs.
Deployed In Type of deployment (for example, Inline, Reverse Proxy).
Initialization Details if initialization ended successfully.
Status
Cluster Manager Member of a cluster: True or false
Member
Auto Discovery On or Off (whether auto-configuration is enabled or disabled).
Status

Alteon Web Security

CHAPTER 3 – BASIC APPWALL
CONFIGURATION
This chapter describes the basic AppWall configuration procedures.
Initial Configuration
To activate AppWall and/or Authentication capabilities on a specific Web Application, the flowing
steps are required:
• Enable AppWall and Authentication on the Alteon vADC.
• Configure a Secure Web Application object and enable for it AppWall and/or Authentication.
• Attach the Secure Web Application to the virtual service that processes the required traffic.
• Edit Security Policy for the Secure Web Application.
Configuration Options
For common AppWall deployment scenarios, the full range of deployment, configuration, and
maintenance options offered may be superfluous, unnecessary, and time consuming. Some
advanced security policy tools may generate false positives and may require manual policy
management, which is prone to human error and requires knowledge of Web application security
and familiarity with secured Web application technologies and structures.
To address these challenges, a simplified mode of delivery is available that
• applies global policies, instead of page-based or application path-based settings. A single
application path "/" is created per application.
• removes the option of low-severity rules that have a high tendency for false positives (for
example, in the Database Security filter).
• provides out-of-the box settings, which reduce human interaction when not required (for
example, when a syslog sever is configured, there are default publishing rules).
This mode of delivery also reduces the complexity of the user interface to shorten the learning curve
and reduce the time required by administrators to review and maintain the security policy.
The two license options available are:
• AppWall for Alteon—Comprises the simplified mode of delivery.
• AppWall+ for Alteon—Offers the full range of all options and features for advanced users.
The differences between the AppWall for Alteon and AppWall+ for Alteon options are detailed for:
• Configuration View, page 59
• Security Policies View, page 60
• Forensics View, page 60
Configuration View
The AppWall for Alteon option includes the following differences from the full AppWall+ for
Alteon version in the Configuration view:
• The Web farm, hosts, filters and TCP tunnels are hidden.
• In the HTTP tunnel, General Properties tab:

Basic AppWall Configuration
— The following options are hidden: Include tunnel in default Web app, Auto tunnel
optimization, Tunnel Thread Count, Ignore Automatic Escalation, Propagation
— Escalation Default Mode change to Operational Mode
• In the HTTP Properties tab, all options are hidden with permissive settings, except the following:
— Only Use Code Page Encoding for URL and parameter
— Allow Message with Parameter value that failed text normalization
— URL Query string delimiter
— Parameter Delimiter
— Session Delimiter
— Code page
— Custom headers: XFF
— Protection Against Slowloris
— Masquerade Server Identity
— Replace http reply message (500)
• The HTTP Message Size options are hidden. The following are set, non-editable, values:
— Start line: 20 KB
— Body: 1024 MB
— Total Headers: 50 KB
— Single Header: 5 KB
— Cookie header:10 KB
— Referer header: 5 KB
• In HTTP Parsing, the following are the differences:
— Exceptions are set for All URIs.
— All properties are hidden with permissive settings, with the exception of JSON parsing
(enable) and parameter parsing (for CDN flood mitigation).
• In Forensics view, the Escalation Log folder is removed.
• In Services > Publishers > Recipients and SMTP are removed.
• Publisher options are Syslog and SNMP.
• In Events, if the syslog sever is configured, a single publishing rule is automatically created for
all events.
Security Policies View

In the Security Policies view, the AppWall for Alteon option includes the following differences from
the full AppWall+ for Alteon version:
• Only the following security filters are supported: Allow List, Brute Force, Database, Files Upload,
HTTP Methods, Path Blocking, Safe Reply, and Vulnerabilities.
• No ICAP support.
• Sitemap is hidden.
• No Application Path (only hidden "/").
Forensics View
In the Forensics view, the AppWall for Alteon option includes the following differences from the
full AppWall+ for Alteon version:
• Only default Forensics views display, with the option for filters.
• No folders display.

Enable AppWall and Authentication Gateway on vADC

You can enable AppWall and an authentication gateway on a vADC.
To enable AppWall and or Authentication Gateway

1. On the vADC Web UI, in the Configuration view Security tree, select Web Application
Services.
2. Ensure that mode is inline.
3. Select Enable AppWall and/or Enable Authentication Gateway.
4. Click Submit and then Apply.
Note: The AppWall and Authentication capabilities must be provisioned on the vADC, before they
are activated.
Configure and Edit Secure Web Applications

You can configure the Secure Web applications and edit their security policies.
To configure a Secure Web Application

1. On the vADC Web UI, in the Configuration view Security tree, select Web Application Services
> Secure Web Applications.
2. Select + to add a new Secure Web Application.
3. Enter Secure Web Application ID and enable it.
4. Select Enable AppWall and/or Enable Authentication Gateway.
After pressing Apply a Tunnel object and a Web Application object are created in the AppWall
module, with the Secure Web Application ID.
Note: The tunnel and Web Application objects are inactive as long as the Secure Web Application is
not enabled and attached to a virtual service.
To edit security policies for a Secured Web Application

1. On the vADC Web UI,
2. Select Security > Web Security > Secured Web Applications
3. Select the required Secure Web Application.
4. Click Edit Security Policy.
The AppWall Management Application is initiated. Continue security configuration using this
interface.

Authentication Servers
When the Authentication Gateway capability is employed it is necessary to configure the external
authentication servers, LDAP or RADIUS.
To configure an LDAP server

1. On the vADC Web UI select Security > Web Security > Authentication Servers > LDAP.
2. Click + to add a new LDAP server.
3. Configure the LDAP server parameters
To configure a RADIUS server

1. On the vADC Web UI select Security > Web Security > Authentication Servers > RADIUS.
2. Click + to add a new RADIUS server.
3. Configure the RADIUS server parameters
Note: There are different types of RADIUS servers.
To choose the type of RADIUS Server:

1. Open the AppWall console; from the vADC Web UI, select Security > Web Security.
2. In the right pane, click Dashboard. The AppWall console opens.
3. In the AppWall console select Configuration > Management > Authentication Servers.
4. In the RADIUS tab, open the previously-created RADIUS server.
5. You can choose the type of RADIUS server: Standard, SMS Passcode, RSA SecurID, or
Azure.
Adding a Two-Factor Authentication Scheme

Use the following procedure to add a two-factor Authentication Scheme.
To add a two-factor authentication scheme

1. In the AppWall console, in the Configuration view, select Management > Authentication
Servers.
2. From the 2 factor Authentication tab, click Add a two-factor authentication scheme.
3. In the Add Two Factor Authentication dialog box, set the 1st Factor and the 2nd Factor
authentication servers.
4. Click OK.

Notes
• Two-factor authentication scheme is used for SSO capabilities.
• The first Factor is a domain controller/LDAP server or a RADIUS Server type Standard, RSA
SecurID or Azure.
• The second Factor is a RADIUS server of type RSA SecureID or SMS Passcode or Azure (only if
the first factor is Azure too).
Managing Web User Roles

AppWall enables defining various types of Web-user roles:
• IP Address and Geo-Location-Based Roles, page 63
• LDAP Roles, page 64
• Combining Radius and IP Address-based Roles, page 64
• Combining LDAP and IP Address-based Roles, page 65
IP Address and Geo-Location-Based Roles

You can create a Web role based on client source IP address. Additionally, a geo-location database is
available to define geo-location-based policies.
For example:
1. You can prohibit access to your operation application to users outside the US.
2. You can allow only internal users (10.*.*.*) to access particular applications.
3. You can allow only addresses from Germany to submit an energy usage report to the secured
application.
If an X-Forwarded-For (XFF) header is provided and configured in AppWall, the original client IP
address will be retrieved from the XFF header.
The IP-based settings can be combined with other user-tracking or authentication mechanisms to
provide a more accurate policy and to address fraud risks.
IP Groups
In order to create an IP-based role, you can create a new IP address group in the Configuration
view, select Management > IP Groups and click on the + icon. The group can be set to included
and excluded IP address ranges or IP address and mask pairs. Additionally, you can include or
exclude countries, based on a geo-location database.

Figure 24: Add Group Window
You can then create an IP Group-based role in the Web user Roles section.
You can also combine IP Group settings with Radius and LDAP settings:
Authenticated Users Based on Successful Login Detection

You can create a Web role of authenticated users based on detection of successful login to the
application, when the actual authentication is handled by the application.
LDAP/RADIUS Authenticate Users

Once you configure a RADIUS or an LDAP server, you will have automatically added
"authenticated@server-name" role where “server-name” is the name of the LDAP/RADIUS server
you have created.
LDAP Roles
For LDAP servers you can add additional roles by mapping AppWall policy role to a group in the LDAP
server. The mapping is performed with an LDAP browser, which will enable you to connect to the
configured LDAP server and select a group in the server.
Once the role is defined, you can select this role under the host in the Security Policy view.
Combining Radius and IP Address-based Roles

With Radius-based authentication you can create separated policies for authenticated and non-
authenticated users. When combining with IP groups you can segregate the authenticated users by
their geo-location to provide more restricted policies.

Combining LDAP and IP Address-based Roles

Additionally, as part of the LDAP role configuration, you can also include IP groups, for the same
LDAP user, which enables configuration of separated policies.
Figure 25: Add Role Window
Examples
A You can limit access to your administrative section of the secured Web application only to users
who are members of the LDAP “Admin” group and to those who access the application internally
(10.*.*.*). Users accessing over VPN will also have an internal address.
B On the other hand, you can create a more restricted policy for users who are members of the
LDAP “Admin” group who access from external addresses in your local geography (with no
privileges to stop the application).
C You can also configure a “monitor only” policy for administrators when accessing from trusted
remote geographies (for example, from the UK).
D You can prohibit access to your application for any user (including LDAP “Admin” users) who is
accessing from a non-trusted location (for example, from North Korea).
Working with Tunnels

This section describes how to manage tunnels through the Configuration view.
This section includes the following:
• Modifying HTTP Tunnel Properties, page 65
• Setting Tunnel Operation Modes, page 77
• Viewing and Changing the Current Operation Mode of a Tunnel, page 77
Modifying HTTP Tunnel Properties

You can change the various properties of a tunnel. This is ideal if IP configurations need to be
updated.
This section provides a summary only of the tunnel properties; for the settings specific to your
Security Policy requirements, refer to the relevant section in Defining Your Security Policy.

To modify tunnel properties

1. In the Configuration view, select Tunnels and select the tunnel to be modified.
2. In the right pane, click each tab and modify the tunnel properties as required.
— General Properties—Modify settings as required, such as the name of the tunnel or enable/
disable Auto Policy Generation.
— Host Name—Modify settings as required, namely the Host (Virtual Host) names which are
name values used in the HTTP Header: Host=HostName
— HTTP Properties—Modify settings as required, such as enabling the support of High-ASCII
Characters (127-255).
— Parsing Properties—Modify settings as required, such as Ignore empty header names.
— HTTP Message Size—Contains Client Request and Server Reply settings where you can
modify the line, the body, headers or a single header.
— Security Bypass—Modify settings as required, such as the file extensions that indicate file
types for which this feature should be applied.
3. Click Submit and Save.
4. On the AppWall Management Application toolbar, click Apply .
General Properties
The following table shows a list of the general Tunnel properties.
Table 8: Tunnel General Properties - General
Parameter Description
External SSL Indicates that before the AppWall device there was performed SSL
Offloading offloading. This means that the client uses HTTPS even though AppWall
sees clear HTTP traffic.
AppWall uses this information to decide on if to add cookies with HTTPS
only attributes for the authentication features and for other purposes.
Auto Tunnel The tunnel object has different settings that require optimization and
Settings modification once AppWall is deployed. When Auto Tunnel Settings
Optimization Optimization is enabled for the tunnel, it instructs the Auto Policy
Generation engine to automatically optimize tunnel level settings,
including message size settings both for the request and the response,
the of adding of new headers with explicit size limitations, and HTTP
parsing properties exceptions. By default, this is enabled.
Note: Note: Auto Discovery must be enabled for the Auto Tunnel
Settings Optimization to function.
Tunnel Thread The number of threads allocated for the configured tunnel.
Count Three possible values can be assigned: High, Medium and Low.
The recommended and default value is Medium. with this value the
maximum number of tunnels which can be configure in the system is 50.
If more tunnels are reacquired on a the AppWall device, configure the
Thread Count to Low, enabling up to 100 tunnels to be configured.

Table 9: Tunnel General Properties ties - Escalation
Escalation
Default Mode Use this field to set the desired default escalation mode of the tunnel.
Options are Active, Bypass, and Passive for the AppWall Gateway.
Passive Message Use this field to set the desired behavior for receipt of a Build Failure
Build Failure message when the tunnel is in passive mode.
Handling
Ignore Automatic By checking this field, the tunnel will remain in the default mode until the
Escalation user changes to a different tunnel mode. When this field is checked, the
tunnel is not affected by escalation rules.
Propagation
These setting determines how AppWall propagates connectivity problems with the Web server
to the load balancer or client, due to the Web server being too heavily loaded or in situations
where the Web server is down. Until now, AppWall continued attempts to connect to the Web
server and accept new connections from clients, even in cases where there is no response from
the Web server.
Automatically This property definition stops the tunnel from accepting new client
Suspend Tunnel connections when the Web server does not accept new connections from
Upon Web Server AppWall due to server failure.
Failure
After __ Connection This defines the number of consecutive attempts to connect to the Web
Attempts server that were refused, which will cause tunnel deactivation. After this
number of attempts, if the "Automatically Suspend Tunnel Upon Web
Server Failure" flag is on, the tunnel will stop accepting new connections
Connections
These settings define the maximum number of pending and active connections.
Maximum Pending Maximum number of incoming requests that the tunnel can queue for an
Connections available session.
Maximum Active Maximum number of active connections (network sessions) at one time.
Connections
X-FORWARDED-FOR Header
This allows the user to add the IP address of the client to the request header.
In order for AppWall to process the original client IP address and not to use the TCP connection
source IP address (in cases there are Reverse Proxies in front of AppWall), AppWall can be
configured to extract the IP address from the X-Forwarded-For header.
AppWall will use the excreted IP address for IP address presentation in security event logs, in
learning and Auto Policy Generation and for Session Security filter IP address enforcement.
X-FORWARDED-FOR Check the box to add the X-FORWARDED-FOR header and delimiter to
Header the requests sent to the server.
Host Name
The Host Name tab provides management of Host Names. These Host (Virtual Host) names are
name values used in the HTTP Header: Host=HostName.
A value of <Any Host> is used for any undefined Host Values or for requests that do not have hosts
specified in the HTTP header. If your Web server does not use virtual hosting, <Any Host> should be
the only value specified.
Wildcards ("*" ) are also supported in the host name, for example, *.micro*.*

HTTP Properties
The following table shows the HTTP properties available.
Table 10: HTTP Properties - General HTTP Properties
Allow High ASCII When enabled, AppWall allows High-ASCII Characters (127-255) in any
Characters part of a request or reply. The Unicode representation of the identified
high-ASCII characters is based on the selected codepage for this tunnel.
When disabled, High-ASCII characters are not allowed.
Enable/Disable from the drop-down menu or double-click and check/
uncheck box.
Only Use Codepage When selected, AppWall performs text-normalization using the tunnel
Encoding for URL codepage instead of UTF-8. Enable this setting when an HTTP request
and Parameter includes codepage-encoded characters that may be mistaken for UTF-8.
Screening When disabled, UTF-8 translation is used for text-normalization to
Unicode. For details, see Codepage Encoding.
uncheck box.
Disable Persistent When enabled, disables persistent HTTP connections by including a
HTTP Connections “Connection: close” header in the request messages sent to the Web
Application
uncheck box.
Allow Messages with When enabled, AppWall allows messages containing parameter values
Parameter Values that cannot be fully-normalized to Unicode to pass unchanged in value
that Failed Text- and treats them as a stream of bytes when evaluated. This occurs if
Normalization there is a failure with UTF-8, Codepage, Unescaping %HH Characters, or
Folding.
The failure to translate may be due to improper codepage usage,
improperly escaped characters or incorrect tunnel settings for
unescaping. For more information, see Codepage Encoding.
uncheck box.
Support Quick-Click When enabled, AppWall allows Quick-Click Refinements on events
Refinement for generated for requests that cannot be matched to an enabled Application
Adding New Path.
Application Paths Enable/Disable from the drop-down menu or double-click and check/
uncheck box.
Session Delimiter The Session Delimiter is the character that separates the request URL
from the Session Token. The character is inserted twice into the request.
The Session Token is attached to the URL by the Session Security Filter.
uncheck box Enter the character to be used as a delimiter.
Note: The / character cannot be used.

Table 11: HTTP Properties - Request Message
URL Query String Specifies the character used in query strings to delimit the beginning of
Delimiter query parameters.
Parameters Character that separates the parameters in the URL. This character is
Delimiter used as a delimiter for parsing the parameters in a multi-parameter
string.
Double-click the text field and enter the delimiter.
Codepage Encoding Specifies the type of special characters (languages) your Web Application
Scheme client uses in its requests. This setting should be changed for Web
Applications that use characters other than Microsoft Windows 1252
(ANSI). For more information on encoding, see Codepage Encoding.
Select the Codepage Encoding scheme from the drop-down menu or
double-click and select from menu.
Support parsing to By default, query parameters are expected to conform to the
NULL_PARAMETER conventional parameter_name=parameter_value. By default,
_NAME of values instances with a parameter_value and no parameter_name are failed.
when query
When enabled, this request allows the above type of request to pass by
parameter names
assigning NULL_PARAMETER_NAME to parameter_name in all such
are null
instances.
uncheck box.
Allow Double-Slash Allows HTTP request message to include a double-slash (/ /) in the URL.
in URL Using this setting, AppWall converts the double-slash (//) into a single
slash (/) prior to analyzing the message.
When disabled, the double-slash URL would raise an event as an invalid
URL. If the request message includes the http://expression, the double
slash is not converted.
uncheck box.
Purge Multiple When enabled, all multiple slashes will be changed to a single slash
Slashes Enable/Disable from the drop-down menu or double-click and check/
uncheck box.
Analyze Path Enables the tunnel to send path parameters to the parameter-related
Parameters security filters for analysis whenever possible. Path Parameters are
embedded parameters in the request message URL (for example, http://
www.site.com/ docs; PathParameterName=PathParameterValue/
register.jsp?id=3).
uncheck box.
Analyze Cookies as When enabled, the tunnel can send cookies as parameters to parameter
Parameters related security filters. This feature allows security filters, such as the
“Parameters” security filter, to check the submitted values in each
cookie.
uncheck box.

Table 11: HTTP Properties - Request Message (cont.)
Allow Non-RFC When enabled, AppWall does not enforce the RFC requirements as stated
Compliant HTTP in the latest HTTP RFC (rfc2616).
Methods When disabled, any message containing an RFC-compliant method raises
an event. RFC documents are available from the World Wide Web
Consortium (W3C http://www.w3c.org/).
uncheck box.
Parse Multi-Part When selected, the process that unescapes parameter values using the
without Unescaping %HH convention will not be used for multipart-post request-body-
(%HH) Values parameters. Instead, the “%” character is treated as a language
character (ASCII 37) in text-normalization.
Note: If this setting is disabled and unescaping fails, the message will
be considered invalid and may be rejected. To prevent this, enable
Allow Messages with Parameter Values that Failed Text-
Normalization.
uncheck box.
Allow Trailing “%” When enabled, “%” at the end of a parameter value will be treated as a
Character in language character (ASCII 37), and not an escape code.
Parameter Values
Note: If this setting is disabled and unescaping fails, the message will
be considered invalid and may be rejected.
uncheck box.
Use IIS Extended When enabled, URLs containing extended Unicode characters in the path
Unicode Measures name raise an event. This property enables an extra level of processes to
secure extended Unicode code points (character representations) that
are converted by AppWall or target application.
For example, the code points U+0041, U+0100, U+0102, U+0104,
U+01CD, U+01DE, U+8721 are recognized as Unicode A. For more
information on encoding, see Using IIS Extended Unicode Measures.
uncheck box.

Custom Headers You can add any headers you wish to the incoming request using this
field.
After you have added headers, you can edit or remove a header by
selecting the header and clicking Edit or Remove.
To add a header:
1. Select Enable
2. Click the (Add) button.

3. Enter the Header Name, Delimiter (typically “:”), and initial free
text for the header.
You can have any of the following added to the header by leaving the
checkbox for this item checked: Session Date Time, Message
Date Time, Client Port, Client IP, Forwarding Port, and
Forwarding IP.
4. Click OK.
Note: A complete document explaining the X-FORWARDED-FOR

Custom Header is located in the AppWall Support folder.

Signature When enabled, this feature allows you to select various parts of the
request message and include them in a Signature that will be sent in the
request. This allows the Web server to verify the message source and
authenticity.
To enable:
1. Select Enable
2. Select whether the signature should be added for each Session or
each Message.
3. Enter the Header Name for the signature.
4. Select a mode for the signature: Pass & Sign Incomplete, Pass
Incomplete Unsigned, Fail Incomplete (disconnect).
5. You can select a Private Key by clicking Select and selecting a
certificate.
6. You can also include: URL, Forwarding IP, Forwarding Port, Date Time
(and if so, a Time To Live, in seconds), and/or one or more selected
headers, either from the message or from the custom headers you
created in Custom Headers.
7. Click OK when you are finished.
Slowloris protection For a mitigation with TCP Timeout:
This setting enforces protection against slowloris attacks that consume
web server resources by opening a TCP connection without sending data
or sending data very slowly.
The protection has two settings:
• Time Gap Between Checks: The time span during which the AppWall
is counting the traffic rate on the inspected connection.
• The minimal traffic volume threshold to trigger the protection.
The inspection is enabled during the first 60 seconds (Idle Session
Timeout) and the protection is applied during the next coming 30
seconds (Time Gap Between Checks).
Allow Extra Space The HTTP request line specifies the type of document requested, the
Padding in the HTTP method that must be applied, and the version of the protocol used. The
Request Line line is made up of the three elements separated by a space.
This property allows up to four extra spaces before or up to three extra
spaces after the protocol version but not before the URI.
uncheck box.
Fast upload Fast Upload is a mechanism, if activated, where AppWall will send data to
threshold (in KB) the web server before AppWall will receive all the HTTP request. This
parameter is a general threshold for the URI configured in the tunnel to
bypass the Fast Upload feature if the HTTP request size is more than the
threshold. By default this parameter is not activated. To configure it, you
must enable it from the "HTTP Properties" screen adding at least one URI
with the parameter "Fast Upload for large HTTP requests" checked.

Table 12: HTTP Properties - Reply Message
Compressed Replies The Compression configuration allows compressed content (gzip and
Settings deflate) to be sent as long as the request contains the “Accept-Encoding”
header. This setting determines how the HTTP header is to be handled.
When a reply contains a compressed content it must include the
“Content-Encoding:” header. Every security filter that is configured to
examine the reply body decompresses the message body in the event
the body is compressed; therefore, only inspected replies are
decompressed. If the reply body is modified by one security filter it can
than be examined by other security filters.
If Compression is disabled, the “Accept-Encoding” header is set to
"identity".
If "Force recompress" is selected, the modified reply body is then re-
compressed and sent to the client. If the reply was not modified, the
original buffer is sent to client.
Note: Encoded (compressed) content prohibits text-normalization and
greatly restricts security capabilities for analyzing outgoing reply
messages.
uncheck box.
Terminate 100 When enabled, the appliance acts as a successful termination point for
Continue Replies HTTP 100 Continue requests, without forwarding these requests to the
Web servers.
uncheck box.
Allow Client Cache When enabled, caching of POST data is permitted when Back is clicked
Control in the client’s browser.
uncheck box.
Replace the HTTP Allows you to remove or replace the standard HTTP reply messages with
Reply Messages custom messages of your choice. You can change the replies according to
with Custom one or more ranges of status numbers. If replacing the message, place
Messages the new message into a file and include the file using the interface.
To enable:
1. Double-click the property and click the (Add) button in the

displayed dialog.
2. Enter the TO and FROM range for HTTP Status Codes.
3. Select the Message Body.
4. If File has been selected, click File List.
5. In the File List dialog you can add, edit or remove files from the list.
6. Select the file to use and click Assign.
Masquerade Server Many Web servers broadcast their server type in the HTTP header
Identity returned to the client. This represents an unnecessary security risk.
When enabled, this setting allows you to replace the server identity with
a string of your choice, or to remove the server identity altogether.
uncheck box.

Parsing Properties
The HTTP Parsing Properties Configuration tab under the tunnel configuration enables you to exclude
any of the 33 HTTP parsing settings which used to be enforced.
Note: If Parsing URI is configured as /xxx/bbb, then:

• Client access to www.domain.com/xxx/bbb/ matches the parsing URI entry and acts according
to the policy bound to it.
• Client access to www.domain.com/qqq/xxx/bbb/ does not match the parsing URI entry.
• Client access to www.domain.com/xxx/bbbccc/ matches the parsing URI entry and acts
according to the policy bound to it.
1. On the URL window, click New to add any URL or name a specific URL for parsing criteria to be
applied.
2. To update an existing list, click Edit or Delete as appropriate.
3. Once you open the URL Properties pane, mark in the value boxes which properties you wish to
apply to the URL.
Table 13: Parsing Properties
Property Allows parsing criteria.
Value Mark as appropriate for parsing.
4. Click to add values and then OK to exit. Your values are saved.

5. You can set the configuration for all the URLs in a tunnel or per specific URL.
6. When you have finished, the Parsing Properties pane should look like the following example.

7. By selecting the Parsing properties name, you can view more detail and edit if required.
8. Click Submit and Save to save your changes or Revert to discard them and revert to your
previous settings.
HTTP Message Size

The following table shows the HTTP Message Size parameters, maximum allowed length (in Bytes)
for both client request and server reply.
Table 14: HTTP Message Size Parameters
Start Line Maximum length allowed for a request (URL) line. This accounts for path
and query parameters.
Body Maximum length of the entire body of a request message. Because Files
> Upload places the files in the Body you may need to increase this to
accommodate file sizes. This total should also include addition bytes for
the body HTTP protocol.
Total Headers Maximum length of the entire HTTP Header of a request. This value
should be larger than the total of the sizes of the expected Header values
included in any given request plus additional bytes for the header HTTP
protocol. This value cannot be less than the Single Header setting.

Table 14: HTTP Message Size Parameters (cont.)
Single Header Maximum length of a single Header entry. This entry must be greater
than or equal to the largest value in the Header table below.
The Header table lists all the headers by names and maximum size for each Header Name
added to the list.
Click the (Add) button to add a header name and maximum size (in Bytes) to the Header
table, or select an entry and click the (Edit) button to edit the header name and/or
maximum size of that header.
The maximum size should be less than or equal to the Single Header entry and should be the
total bytes for the Header Name and Header Value statement (that is, Header Name length +
Header Value length + 1). For example, the HTTP Header:Cookie=123456789 is 16 characters
total.
Security Bypass
The Security Bypass feature allows you to indicate file types and parameters that can be requested
without additional validation.
There are many file types and parameters that pose little or no threat in an HTTP or HTTPS
request, such as images and video. By not subjecting these requests to further processing, you can
reduce resource usage and increase speed.
For any of the listed file types, select the file extensions for which the Security Bypass feature should
be applied. Deselect the file extension to remove the Security Bypass feature from that file type.
Similarly, for any of the listed parameters, select the parameter for which the Security Bypass
feature should be applied and deselect it to remove the Security Bypass feature.
To add a file type or parameter to the list, click for either the file type or parameter, enter the
extension or parameter, respectively, and click OK.
Setting Tunnel Operation Modes

AppWall can run in different modes of operation as shown in the following table:
Table 15: Tunnel Operation Modes
Mode Server Types Description

Active Gateway Full intrusion detection and interception.
Passive Gateway Full intrusion detection.
Bypass Gateway Running, but no intrusion detection or interception.
Using AppWall Management Application, you can view and change the operation mode of each
defined AppWall.
Viewing and Changing the Current Operation Mode of a Tunnel

Use this procedure to view or change the current operation mode of a tunnel.

To view current Operation mode

1. The current operation mode of the tunnel displays in the General Properties tab of the tunnel.
2. In the Configuration view, select Tunnels > Tunnel Name.
3. Select the tunnel name. A list of properties tabs appear for the tunnel.
4. Click the General Properties tab to display general properties for the selected tunnel. You can
also determine the operation mode of the tunnel by the icon displayed for each tunnel in the
Configuration view.
To globally change Tunnel Operation modes

1. Right-click the server node, select Escalation Settings.
2. Select Set Mode to [new mode].
Configuring the Publisher

This section describes how to configure the AppWall Publisher and includes the following:
• Managing Publisher Connections to AppWall Servers, page 78
Managing Publisher Connections to AppWall Servers

Publisher is pre-configured to collect data from local AppWall server logs. Use this procedure if you
want to set up a connection between Publisher and other AppWall servers to aggregate their logs.
To manage Publisher connections

1. Make sure the AppWall Publisher service is running.
2. In the Configuration view, open Services and select Publisher.
3. In the right pane, complete the fields as described below.
Table 16: Publisher Connection Parameters - AppWall Publisher Connection
Enable Enables/Disables the Publisher.
Publisher Server IP The IP address of the server where the Publisher resides.
TCP Port The port number for the machine on which the Publisher resides.

Table 17: Publisher Connection Parameters - Listener Configuration
Accept Connections Use Add, Edit, or Remove to enable connections. You can enter an
from IPs unlimited number of IP addresses to the Publisher.
To specify multiple IPs, use two asterisks in an IP subnet mask. The
wildcard characters can hold one placeholder in the IP format and
represent a range of 0-255.
The following table shows correct and incorrect use of the asterisk
wildcard for specifying an IP subnet mask:
Correct Incorrect
255.*.*.1 10.*2.*.188
10.6.204.* 145.*.*.*
*.*.10.93* .1.*.*
Deny Connections Use Add, Edit, or Remove to deny connections. This list refines the Deny
from IPs Connections From list. By itself, the Deny Connections From field has no
affect because all IPs are automatically blocked unless listed in the
Accept Connections From field.
Maximum The maximum number of concurrent connections permissible.
Connections Limit
5. On the AppWall Management Application toolbar click Apply .
Notes
• Many of the settings in the Events node affect the Publisher’s functionality for the various levels
of events.
• The ability to use a centralized publisher for multiple AppWall servers allows you to specify which
Publisher handles certain AppWall servers. This raises certain sharing issues, which should be
understood.
• Adding the Deny Connections from IP settings effectively disconnects publishing for the specified
AppWall servers, including AppWall servers configured in other Consoles.
Configuring SysLog Notifications

Use this procedure to configure where Publisher sends SysLog notifications.
To set Publisher SysLog Notifications

1. Make sure the AppWall Publisher service is running.
2. In the Configuration view, open Services > Publisher and select Recipients.
3. In the right pane, click the SysLog tab and complete the following fields.

Table 18: Publisher SysLog Notifications Parameters
Enable Clear to disable feature. Select to enable an event to send a syslog
notification and fill in remaining fields to specify where to send the trap.
Forwarding Address IP address sending the trap.
Destination/Port IP address and port number where the syslog notification is sent. Use
Add, Edit, or Remove to manage this setting.
4. Click Test Settings to check the settings.
5. Click Submit and Save. The Publisher automatically restarts when the configuration is saved.
Out-Of-Path Mode
AppWall for Alteon supports out-of-path deployment mode. In this mode, ingress and egress traffic
is duplicated for inspection by AppWall resulting in a risk-free WAF deployment. AppWall inspects the
incoming and outgoing traffic without any impact, delay, or risk on the inline traffic.
This mode is ideal for performance sizing, fine tuning the security policies, and easy turnover to
inline active mode once configuration is set.
Both HTTP and HTTPS traffic are supported.
Out-of-path mode enables simple deployment for the purpose of application traffic analysis and
security visibility. Policy can be automatically generated similarly to the inline gateway with no
impact of client traffic performance or risk.
Note: This deployment option is relevant for WAF functionality only. Authentication and SSO are not
supported in this mode.
Deploying AppWall with DefensePro

AppWall can extract the attack source IP address from either the Layer 3 IP header or from the HTTP
headers (such as, X-Forwarded-For and True-Client-IP). Once an attack source is detected, AppWall
signals the attack source IP address to DefensePro, either by adding the source to the DefensePro
black list or by generating a signature of the attack source IP address to be matched in the HTTP
headers. When a client NAT is applied in front of AppWall, it detects the attack source in the HTTP
headers but it needs to signal the source IP address to DefensePro that is processing the traffic
before the client NAT.
The AppWall signaling mechanism to DefensePro is based on AppWall’s IP blocking system. When
enabled, depending on the defined penalty scores of each security filter, once a security score is
reached, AppWall locally blocks the source (based on either the source IP address or HTTP header)
and signals DefensePro to block the source for a configurable time frame.
For more information, refer to IP Blocking, page 196
AppWall can be deployed either in inline mode or out-of-path mode. When deployed in out-of-path
mode, it passively detects attacks. With inline mode, using singling, DefensePro serves as the
enforcement point at the perimeter, and where AppWall deeply parses the HTTP protocol in the data
center and allows detection of Web-based attacks with higher granularity.
When multiple AppWall platforms are deployed in a clustered array, the Cluster Manager
synchronizes the violation scores of all the cluster nodes and sends the signals to DefensePro. (The
nodes so not signal DefensePro).

To configure DefensePro signaling

1. If you need to signal the signatures of the HTTP header IP address you must add a Destination
Networks: In the Configuration view, select Services > IP Blocking > DefensePro Signaling,
and add a new Destination Network to the list.
This list is defined based on the destination IP addresses that the DefensePro device will be
processing. For example, when an ADC platform is deployed at the data center, the DefensePro
protected networks will usually be the VIP addresses in the ADC.
2. In the Configuration view, select Services > IP Blocking > DefensePro Signaling, select
Enable, and add the list of DefensePro devices that you want AppWall to signal to. For each
DefensePro device, you will be asked to provide:
— management IP address and port
— username and password
If you need to signal the signatures of the HTTP header IP address, add the previously configured
Destination Networks. Depending if there is a client NAT between AppWall and DefensePro, check
whether to signal the Layer 3 source IP addresses or the HTTP signatures.
Note: For DefensePro x420 devices, you must manually add the AppWall Profile (AppWallAttack)
to the network policy of the relevant destination network.
Escalation
AppWall Gateways are deployed in-line for intrusion prevention. They offer multiple modes of
operation:
• In Bypass Mode—AppWall Gateways allow traffic to pass through with zero performance
impact
• In Passive Mode—They examine inbound and outbound traffic to detect security violations
• In Active Mode—AppWall Gateways provide full intrusion prevention to immediately detect
threats, generate alerts, and block attacks
Radware’s Intelligent Escalation technology grants superior control over Web application security. It
allows policy establishment that trigger the escalation of AppWall Gateways across the enterprise.
For example, an organization could deploy AppWall Gateways in Bypass or Passive Modes to
optimize operational performance and capacity until there is reason to believe the enterprise is
under attack.
Upon detection of a suspected attack attempt, the tunnel automatically escalates the security
posture proportionally to the estimated level of risk, promoting the mode AppWall Gateways into
Bypass or Active Mode. Escalation of the tunnel is configured according to Escalation Rules.
To change escalation mode for a specific tunnel

1. Select the tunnel whose Operational mode you wish to change (Escalation settings).
2. Right-click the tunnel and from the menu select Set Mode to Bypass/Active/Passive for AppWall
Gateways.
3. Click Yes to change the tunnel operational mode.

To change escalation mode for all tunnels

1. Select the AppWall whose tunnels’ operational mode you wish to change (Escalation settings).
2. Right-click the AppWall and from the menu select Escalation Settings > Set Mode to
Bypass/Active/Passive for AppWall Gateways.
3. Click Yes to change the tunnel operational mode.
APSolute Vision Reporter

APSolute Vision is Radware’s closed Security Event Management (SEM) system used for AppWall
logging and reporting. AppWall can send all generated events to this external SEM for central logging
from multiple AppWall devices and detailed security and compliance reporting. This SEM can reside
either on a APSolute Vision Server or can be delivered as a standalone SEM Virtual Appliance.
The events are sent to the Vision Reporter in syslog messages over TCP or UDP protocol. You can
configure the underlying protocol for different types of messages. PCI Reports, should be TCP based
as these messages are large and might not be received successfully at the destination.
The default port is 2214 for both TCP and UDP based messages.
APSolute Vision Reporter can run on an APSolute Vision server or as a standalone reporter. The
standalone APSolute Vision Reporter is intended for demonstration purposes only.
Vision Reporter provides you with the following features:
• Dashboard—Dashboards deliver near real-time monitoring and reporting metrics so that you
can track the state of security throughout the network.
• Alerts—The Alerts feature of APSolute Vision Reporter provides warning based on pre-defined
and configurable event correlation rules.
• Profiles—A profile is a set of instructions defining the method followed to analyze data
customization of reports and more.
• Forensics—Forensics analysis involves recording and analyzing security events to discover the
source of the attack, attack trends, and analyzing the risk associated with each incident.
• Reports—The Reports portal is the platform where you can create and generate a report to view
a single query on the fly without creating a profile.
• Monitors—The Monitors portal enables you to view the security and network traffic events.
• Setup—This portal enables you to configure the basic settings for the APSolute Vision Reporter
to be able to analyze and report on the activity in the network security infrastructure.
• Help—Extensive online help is available for all the modules by clicking Help button on the top
right-hand corner of each window.
For further details see the APSolute Vision Reporter User Guide.
To configure the APSolute Vision Reporter

1. On the Alteon vADC Web UI, in the Configuration view Security tree, select Web Application
Services > Vision Reporter.
2. Enter APSolute Vision IP address and port (default is 2214).
3. Enable to Send events to Vision Reporter.
4. Select the protocol that you will be using for: PCI, Security, Audit and Others.

6. Click Apply.
7. Click the Vision Reporter button located at the top of the AppWall Management Application
window. You are taken to the Security Certificate window for the APSolute Vision address that
you specified in setup.
8. Follow the on-screen instructions including user/password authentication where appropriate.
The Vision Reporter window now displays.


CHAPTER 4 – SECURITY TOOLS
This section describes the various security tools and security features available in AppWall.
• Working with Security Filters, page 85—describes how to work with the AppWall security filters,
and includes a description of each of the filters.
• Security Filters in Detail, page 89—gives a general overview of each of the security filters.
• Web Application, page 137—describes how to work with a Web Application, the logical model for
defining your Security Policy.
• Hosts, page 140—describes how to work with Hosts
• Application Path, page 149—describes how to work with Application Paths
• Defining Your Security Policy, page 155—describes the main scenarios in which AppWall is used
to implement an Enterprise’s Security Policy.
• Auto Policy Generation, page 166—describes how to work with the Auto Policy Generation
feature.
Working with Security Filters

This section describes the out-of-the-box security filters supplied when AppWall is installed. It
describes both the threats that the Filters window and protect against, as well as how each security
filter works, and its default running status.
• Security Filter Overview, page 85
• Threats AppWall Protects Against, page 86
• Setting Security Filters, page 87
• Activating a Security Filter, page 87
• Setting the Security Filter Run Mode, page 88
Security Filter Overview

A security filter is a security component that protects against specific types of Application-layer
threats. Some security filters are active, by default, after the AppWall initial installation. The security
filters node in the Configuration view allows you to establish global configuration settings for
security filters that the AppWall can use when these security filters are assigned to an application
path.
When a request does not conform to a security filter definition, AppWall generates an event. By
configuring and assigning security filter definitions to various application segments, or paths,
AppWall provides you with the information needed to secure applications against invalid requests,
buffer overflows, parameter tampering, database intrusions, and other threats. In addition, the Auto
Policy Generation feature collects traffic and statistical data and, according to the data gathered, can
determine which security filters should be activated or disabled, according to the automation level
you set. As a result, this eliminates the need to devote time to manually configure the system or
review endless event lists.
For further details about each security filter, see Setting Security Filters, page 87.

Security Tools
Threats AppWall Protects Against

AppWall Management Application provides out-of-the-box and configurable security filters, capable
of detecting a wide range of security threats used by hackers to exploit popular enterprise, custom
and third-party Web applications. The following is a partial list of security threats against which
AppWall mitigates.
Table 19: Examples of Security Threats
Threat Description
Parameters Tampering Sends false input to the application using contrived parameters and
parameter values that bypass simple security mechanisms.
Cookie Poisoning Changes the content of cookies from what was originally set by the
application and can forge a cookie with stolen information.
SQL Injection Uses the Web Application’s database access to execute unauthorized
commands using SQL commands.
Session Hijacking Attempts to take over TCP sessions to seize control of a legitimate
user’s Web application session while that session is still in progress.
Web Services Exploits vulnerabilities inherent in web services formats, structure, and
Manipulation operations as well as dictionary and encoding manipulations.
Stealth Commands Smuggles command statements in text fields that will be executed
within a given layer of the infrastructure.
Debug Options Exploits vulnerabilities left open in internally developed code by using
debug constructs.
Backdoor Uses privileged or hidden access that applications may expose
unintentionally.
Manipulation of IT Exploits vulnerabilities in an integrated Internet environment, such as
Infrastructure known patterns and common fields/folders.
Vulnerabilities
3rd Party Misconfiguration Exploits configuration errors in third party components, such as web
and database servers.
Buffer Overflow Attacks Sends large request messages to the application attacking either 3rd
party or internally developed code.
Data Encoding Sends requests using different data encoding standards (for example,
Unicode, UTF-8, or UTF-16). These requests include code points
(character representations) used in Extended Unicode. Targets
variations in data encoding to pass and execute commands within
specific layers of the operating environment.
Protocol Piggyback Modifies the application protocol structure to include nested
commands, targeting variations in protocols to pass and execute
commands within specific layers of the operating environment.
Cross-Site Scripting (XSS) An XSS attack is a hacking technique that leverages vulnerabilities in
the code of a web application to bypass access controls such as the
same origin policy and inject client-side script (malicious content) into
Web pages viewed by other users. It may also collect some type of
data from the victim.
Brute Force Attacks Attempts to guess the Username and/or Password of an authorized
user by employing various automated tools.
OS Command Injection OS command injection can allow attackers to execute unexpected,
dangerous commands directly on the operating system. This weakness
can lead to a vulnerability in environments in which the attacker does
not have direct access to the operating system, such as in web
applications.

Security Tools
Table 19: Examples of Security Threats (cont.)
Threat Description
Cross Site Request A CSRF attack forces a logged-on victim’s browser to send a forged
Forgery (CSRF) HTTP request, including the victim’s session cookie and any other
automatically included authentication information, to a vulnerable web
application. This allows the attacker to force the victim’s browser to
generate requests the vulnerable application thinks are legitimate
requests from the victim.
Hot Link Hot-linking is the act of one site embedding content (such as images,
audio files, and videos) hosted on another site. This uses up the
‘bandwidth’ (data transfer allowance) of the site hosting the file, which
can be very expensive for webmasters who pay for hosting by the
amount of data transferred. Usually, this type of attack is performed
using a GET method on static pages or resources (for example,
images).
Information Leakage Different types of sensitive information such as (CCN), social security
numbers (SSN) and other custom patterns that you define as sensitive
are often provided to web application and thus might potentially be
accessed in a backend database storing this information.
Path (directory) Traversal This type of an attack can enable the attacker to access the file system
of the operating system running the web server.
Predefined resource This is an attack technique used to uncover hidden web site content
location and functionality. By making educated guesses using brute force an
attacker can guess file and directory names not intended for public
viewing. Brute forcing filenames is easy because files/paths often have
common naming conventions and reside in standard locations. These
can include temporary files, backup files, logs, administrative site
sections, configuration files, demo applications, and sample files.
Malicious file upload Uploading a malicious file, a script or an application to the web
application can enable in a second phase, activation of the uploaded
file and result in a lethal attack.
Directory Listing This is a fingerprint attack that exposes the structure and content of
the application, enabling the attacker to properly target his attacks. To
prevent a Directory Listing attack use AppWall to identify suspicious
GET requests with “/” at the end of the URI. The replies for these
requests are inspected to validate that there is no Directory Listing
information contained.
Parameter Pollution (HPP) An HTTP Parameter Pollution attack is a scenario where two
parameters with the same name but with different values are sent to
the Web server.
Setting Security Filters

This section provides an overview of how to activate and set AppWall security filters to monitor and
protect network traffic.
Through AppWall Management Application you can set up security policies for each Application Path
you define, using the security filters to provide fine-grain control over your security environment.
You can define AppWall to automatically apply the relevant security filters for each Application Path.
Activating a Security Filter

This section describes how to globally activate a Security Filter.

Security Tools
To activate a Security Filter

1. In the Configuration view, select Filters and select the required Security Filter.
2. Select or clear the required checkboxes. Where relevant, ensure that Enable Log, Quick-Click
Refinement, and Manage Refinement Usage Frequency are selected.
3. In the Security Policies view, select Application Path and select the Settings tab. Set the
Security Filter mode (as described in the following section).
See Auto Policy Generation, page 166 for information on how to determine the level of
automation.
4. Click Submit and Save, and on the AppWall Management Application toolbar click Apply.
Setting the Security Filter Run Mode

You can enable or disable different Security Filters within the Security Policy by setting the Security
Filter mode:
• Active mode—enables the stopping of traffic triggered by the Security Filters.
• Passive mode—enables full intrusion detection without stopping traffic (unless it is set to
escalate to Active).
• Patch mode—enables full intrusion detection, while stopping traffic only where there is a patch.
(Patch mode is only available for Database and Vulnerabilities Security Filters.)
• Disable mode—disables the Security Filter, allowing all traffic to go through.
You can run a full automatic configuration of your Security Filters by selecting the Full Auto option.
This ensures that the relevant Security Filters are automatically set with the required mode,
according to AppWall.
For further information, see Auto Policy Generation, page 166.
You can also work with Auto Refinements enabled (for the relevant Filters) to ensure that
refinements are still generated automatically, whatever the mode selected. See also Security Filters
in Detail, page 89 for information on working with Auto Policy Generation profiles, which provide a
pre-defined configuration.
To set the Security Filter Mode

1. In the Security Policies view, select Web Application > Host and select the specific Application
Path for which you want to set the Security Filter modes.
2. In the right pane, click the Settings tab. Select Active, Patch, Passive, or Disable in the Mode
column according to the requirements of your Web Application. (This action is only available if
the Full Auto option is not selected.)
3. Click Submit and Save, and on the AppWall Management Application toolbar, click Apply .
Refining Security Filters

There are various ways to define Security Filter refinements in AppWall Management Application:
• Quick-Click Refinements—When reviewing a Security Log, you may see some necessary
events, or “false positives.” You can prevent AppWall from continuing to issue events of this type
with the Quick-Click Refinement feature. This feature is available on most Security Filters. See
the procedure below.

Security Tools
• Refinements tab—Most Security Filters provide a Refinements tab to allow you to manually
control events issued by AppWall. See the procedure below.
• Auto Policy Generation—Define a Security Filter’s automation level which will gather traffic
and statistical data to determine whether to change the filter mode automatically or add
refinements. For further details, see Auto Policy Generation, page 166.
To enable Quick-Click Refinements

1. In the Configuration view, select Filters and select the specific Security Filter to display in the
right pane.
2. In the right pane, select Enable Log and Quick-Click Refinements.
3. Click Submit and Save and Apply .
4. In the Forensics view, select a log or report and select the view.
5. In the Event window, select the event that you no longer want reported and click Refine.
6. Click Apply in the AppWall Management Application toolbar.
Notes
• In an event view, an event can be refined using Quick-Click Refinement if a quick-click icon
displays to the left of the event in the event list.
• Quick-Click Refinements are added to the Security Filter’s Refinements page.
To manually add refinements to a Security Filter

1. In the Security Policies view, select Filters and select the specific Security Filter.
2. Click the Refinements tab.
3. On the Refinements tab, complete the fields, specifying the Application Path where the
refinement will be used.
4. Click the (Edit) button.

5. On the dialog box that displays, modify the properties and click OK.
6. Click the (Add) button.

7. Click Submit and Save on the right pane.
8. Click Submit and Save, and on the AppWall Management Application toolbar, click Apply .
Note: For refinements to function, when you create the Application Path you must enable the filter
on the Application Path level.
Security Filters in Detail

This section provides a general overview of each of the Security Filters.
• AllowList Security Filter, page 90

Security Tools
• BruteForce Security Filter, page 94

• Database Security Filter Rule ID, page 99
• FilesUpload Security Filter, page 100
• GlobalParameters Security Filter, page 102
• HTTPMethods Security Filter, page 106
• Logging Security Filter, page 108
• SafeReply Security Filter, page 111
• WebServices Security Filter, page 114
• XMLSecurity Security Filter, page 117
• Parameters Security Filter, page 121
• PathBlocking Security Filter, page 126
• Session Security Filter, page 128
• Vulnerabilities Security Filter, page 134
AllowList Security Filter

The AllowList Security Filter evaluates requests and generates an event when a request does not
match the defined paths or expression. The Security Filter configuration can consist of global
definitions that apply to all Application Paths under a host, Refinements that apply to a specific
Application Path, or both.
Enable the Auto Refinements option (as described in Setting the Security Filter Run Mode,
page 88) to enable refinements to be automatically added to the AllowList Security Filter.
Refer to AllowList Auto Policy Generation Refinements, page 93 for information on how to add or
remove (lock) refinements to/from the filter.
Default Status
The default status of the AllowList Security Filter is not enabled. Be sure to configure this Security
Filter before enabling it. If the Security Filter is enabled without configurations, all requests received
on the Application Path are automatically evaluated as invalid and will generate an event.
Example of Use
For this example, assume the AllowList Security Filter is enabled and configured with the following
list of paths (allowing path requests by remote users).
Table 20: AllowList Security Filter
# Method URL Location

1 GET /default. htm Global
2 GET / Refinements– Non recurse
3 GET /*.htm Refinements– Recurse
4 GET /*.mpeg Refinements– Non recurse
5 GET /demo/demo.cgi Refinements– Non recurse
6 GET /SecurityPages/ Invalid.htm Refinements– Non recurse
7 POST /portfolio/company.cgi Refinements– Non recurse
8 GET /Archive/Documents/ Marcom.pdf Refinements– Non recurse
9 PUT /PostDestination/ \w*\.\w{1,4} Refinements– Non recurse - Regex
10 POST /PostAcceptor/Upload.asp Refinements– Non recurse - Regex

Security Tools
Table 20: AllowList Security Filter (cont.)
# Method URL Location

11 GET /*.gif Global - automatically recursive
12 GET /*.jpeg Global - automatically recursive
If a remote user requests the default.htm page, the HTTP message sent to the Web server is
equivalent to:
GET /default.htm HTTP/1.1
This request exactly matches record #1, therefore no event is generated. Note that this definition is
Global so that any GET request for a default.html, regardless of the Application Path under the host,
is evaluated as valid, as long as the Security Filter is enabled on each Application Path.
If a request is submitted for admin.asp in a directory named administrator, the HTTP message sent
to the Web server is equivalent to:
GET /administrator/admin.asp HTTP/1.1
In this case, there is no match for such a request and an event is generated.
Some examples of permitted requests:
GET /trashfire.mpeg HTTP/1.1
GET /images/image01.gif HTTP/1.1
GET /images/webhelp/15267.jpeg HTTP/1.1
PUT /PostDestination/MyFile.txt HTTP/1.1
GET /NewPages/specialoffers.htm HTTP/1.1
HEAD /BackUpPages/JANold/admin.htm HTTP/1.1
PUT PostDestination/banner.png HTTP/1.1
Some examples of prohibited requests:
PUT /images/innocent.exe HTTP/1.1
GET multimedia/news real/trashfire.mpeg HTTP/1.1
OPTIONS /NewPages/ HTTP/1.1
POST /Portfolio/Orders.asp HTTP/1.1
GET /DB/students.dbf HTTP/1.1
Configuring the AllowList Security Filter

Use this procedure to configure the AllowList security filter.
To configure the AllowList Security Filter

1. Set global parameters for the Security Filter
2. Setting global definitions to use for all application paths under a host
3. Setting Refinements to use on specific Application Paths
AllowList Security Filter Configuration

Use this procedure to set up the AllowList security filter configuration.
To configure the AllowList Security Filter

1. In the Configuration view, select Filters > AllowList.
2. Ensure that Enable Log and Quick-Click Refinement are selected.

Security Tools
3. Select Manage Refinement Usage Frequency.

AllowList Security Filter—Global Settings and Refinements

Use this procedure to set up the AllowList security filter global settings and refinements.
To set the AllowList Security Filter Global Settings and Refinements

1. In the Security Policies view, select Filters > AllowList.
2. Click the (Add) button, or select an existing entry and click the (Edit) button to
modify.
3. Complete the fields using the table below, and click OK.
Note: All refinements added to the list are entered with the exact date and time it was last
matched by a request. This provides useful information when viewing the refinements by date.
Table 21: AllowList Options
Field Description
Application Path Level Select whether to apply only to a single Application Path or to all
Refinement/ Global Application Paths.
Refinement
Web Application Web Application containing the host.
Tunnel Tunnel containing the host.
Host Host containing the Application Paths where the Security Filter should be
used.
Application Path Application Path where the Security Filter should be used.
HTTP Method HTTP method to be screened by this definition.
Page Allowed relative path/page below the host. Allows entry of extensions
using the asterisk character followed by the period and extension, for
example: *.xxx The entry must end with either an extension or a forward
slash.
Use Regular Select to enable use of a regular expression in the Page definition. You
Expression must add a valid regular expression and escape all necessary characters.
Recurse to Sub Allows requests below the path specified. When disabled, only the pages
Directories and files in the immediate folder are allowed.
Pathname Auto-generated field.
Notes
• You should include all security pages, redirected pages, multimedia, and other supporting files
on the Application Path into the AllowList specifications list. This includes files that reside in the
Application Path that are called by pages inside and outside of the Application Path.
• Any unlisted Path and Method combination will be considered invalid.

Security Tools
• If you remove an AllowList specification without providing another entry to cover the page,
requests for that page are treated as invalid. If you remove all specifications, all requests are
invalid.
• Any broken links leading to a specified page should be corrected in order to avoid unnecessary
events.
• If the AllowList Security Filter is enabled, the Security page must be in the list.
AllowList Auto Policy Generation Refinements

This topic describes how to work with the refinements generated for the AllowList Security Filter.
You should also note that when Auto Refinements is enabled, it may add refinements that you want
to manually control. If you delete one of these refinements, the next time Auto Policy Generation
encounters the same refinement it will be added again. In order to prevent this, you can Lock a
refinement, which ensures that the refinement is not added again by Auto Policy Generation.
Refinements can be easily added or locked to/from the AllowList Filter, as described in the following
procedure.
To accept or lock refinements to/from the AllowList Security Filter

1. In the Security Policies view, select Filters > AllowList. A list of A list of Methods, Application
Paths, Pages and Expressions currently permitted displays in the Allow List tab.
2. To move a refinement to the Locked list, right-click on the refinement and select Locked. The
file is moved to the Locked list and can no longer be accessed by users (after clicking Submit
and Save and Apply ). The refinement will not be added again by Auto Policy Generation.
3. To move a locked refinement to the AllowList, click Auto Configuration Locked. Then right-
click on the refinement and select Add As Refinement. The file is moved to the AllowList tab
and is now permitted for access by users (after clicking Submit and Save and Apply ).
AllowList Security Filter Quick-Click Refinements

An event generated by the AllowList Security Filter indicates that no specification has been defined
for its HTTP method/path combination. This can be added using Quick-Clicks. The AllowList Quick-
Click contains a complete specification that matches the request, including URL and HTTP Method,
and can be accepted “as is”.
The AllowList Quick-Click entry can be edited during configuration when needed. Because the Quick-
Click Refinement comes from a specific Application Path, it is automatically attached to the correct
Web Application, Tunnel, Host, and Application Path.
In order to use the Quick-Click functionality, both Logging and Quick-Click functionality must be
enabled on the filter level.
Refinement Usage Frequency Management

The AllowList refinements list contains all accessible resources. In certain cases where, for example,
pages from the application have been removed, requests from clients to these pages will still be
processed by the AllowList Security Filter and will be blocked/forwarded to non-existing resources.
For easier maintenance and better performance a time indication has been added, which provides
information as to the last time a match between a client request and an AllowList Refinement was
made. This way the user will be able to see what resources were lately accessed and what resources
are no longer accessed by user and can be removed from the Refinements list.
By default this feature is disabled.

Security Tools
To enable the feature

1. In the Configuration view, select Filters.
2. Select the AllowList Security Filter and check the Manage Refinement Usage Frequency
checkbox.
BruteForce Security Filter

The BruteForce Security Filter prevents remote users from attempting to guess the username and
password of an authorized user. A potential hacker will use an automated process of trial and error
to guess protected names, passwords, credit card numbers and cryptographic keys.
Many authentication systems allow users to use weak passwords and cryptographic keys. Users will
often use easy-to-remember, common passwords and even passwords that are identical to their
username. A potential hacker will attempt to generate thousands of passwords by using a common
dictionary. The hacker will use this list to search for a valid password.
A successful Brute Force attack occurs when a hacker succeeds in guessing the password and is
granted access to the system.
Automated tools will attempt to gain access to a system by running a BruteForce attack using
millions of password against a single user name, or a single password against millions of user
names. This is a task that cannot run manually as it may take anywhere between a couple of hours
to several years to succeed.
The BruteForce Filter has been designed to detect these attempts at hacking the system, and to
prevent them by blocking the IP of a potential hacker. This type of blocking method will prevent the
hacker from using automated tools to carry-out an attack.
The BruteForce security filter checks the replies sent from the Web server for bad/OK replies.
Based on these replies, in the event of a Brute Force attack, the number of Bad replies from the Web
server (for example, due to bad username or incorrect password) triggers the BruteForce Security
Filter to monitor and take action against the attacker.
All users connected through the same proxy server (for example, AOL) will have the same IP
address. To prevent blocking these IPs from authorized users, the BruteForce Security Filter
identifies these IP addresses and classifies them as Shared IPs.
Default Status
The default status of the BruteForce Security Filter is disabled. Applying this Security Filter requires
configuration. Note that the Auto Policy Generation Full Auto mode is not available for this Security
Filter.
Example of Use
Consider a potential hacker attempting to execute a Brute Force attack against your Web server,
using an automatic tool. The hacker has acquired the username of an authenticated user, however,
has not managed to acquire the user’s password to login to the system.
The hacker applies the use of an automatic tool to guess the password of the user. The hacker then
sends requests to the login page with the user name and passwords generated by the automatic
tool. The hacker sends these requests at a rate of 50 requests per minute.
The BruteForce Security Filter, which has been configured to allow 5 login attempts per IP over a
time frame of 120 seconds, detects that hacker’s IP as a potential attack and blocks the IP for as
long as you have defined. After the IP is released from the block, it is monitored for an additional 10
minutes (to rule out cases where a legal user has forgotten his user name or password). If more
login attempts have been made by the same IP, the BruteForce Security Filter blocks the IP again.

Security Tools
The Time Frame field in the Settings tab, as shown above, enables you to define the amount of time
(in seconds) for periodical monitoring of Brute Force attacks. You can also define the amount of Min
OK Replies to Declare Shared IP and whether or not to automatically detect Shared IP addresses. In
addition, you can define Profiles which allow the user to configure thresholds for determining
whether certain IPs present a risk of attempting to carry out a Brute Force attack. The Profiles are
also used to define the threshold to deal with Shared IPs. The Refinements tab allows the user to
define the rules and patterns to apply to a specific page in a Web Application, Tunnel, Host, or
Application Path.
BruteForce Security Filter Global Settings

Configuring the BruteForce Security Filter includes General settings and configuration management
for Shared IPs, Ignored IPs, and Profiles for triggering actions in cases of Brute Force Attacks.
The following tables provide an explanation of the Settings Tab of the BruteForce Security Filter
Table 22: BruteForce Security Filter Global Settings
Field Description
Time Frame The amount of time (in seconds) used to measure Brute Force attacks.
Min OK Replies The minimum number of OK replies in order to declare the IP as a Shared IP.
to declare
Shared IP
Shared IP Auto Check this box if you wish for the filter to automatically detect Shared IPs.
Detect
Show Auto Use this setting in order for IP addresses detected as Shared IPs to be displayed
Detected in the Shared IP list. This can be used if the user wishes to treat all IP addresses
Shared IPs as regular IPs.
Shared IPs Lists all IPs that have been detected, declared, and added as Shared IPs (a
Shared IP means that one server with one IP address holds multiple domain
names, therefore, all users connected through the same HTTP proxy server will
have the same IP address). IP addresses that have been detected as Shared IP
addresses (an icon displays in the Tips column of the list) require that the user
Accept them as such. Upon accepting the IP address, the icon is removed, and
the IP is set to the Shared IPs list.
Ignored IPs Lists all IPs that the user wishes the BruteForce Security Filter to bypass without
checking. All IP addresses in the Ignored IPs list will not be checked for
BruteForce attacks (entries in this list should be only those from trusted IPs,
such as administrators or scanners).
You can also add IP address ranges using the * wildcard.
Note: IP address ranges must match the following format:
-- Allowed: 1.2.3.* or 1.2.*.* (wildcard must be followed by another wildcard)
-- Prohibited: *.2.3.4 or 1.2.*.4 (initial wildcard or followed by a number)
Profiles Profiles are created to determine the rules and actions to be executed upon
detection of a Brute Force attack.
<> Use the arrow buttons to move IP addresses to and from the Shared IPs and
Ignored IPs lists. Recommended, for example, for moving an IP address of your
QA department declared as a Shared IP to the Ignored IPs list.

Security Tools
To configure the BruteForce Security Filter

1. In the Configuration view, select Filters > BruteForce.
2. Ensure that Enable Log and Quick-Click Refinement are selected. If not, select these fields and
click Submit and Save and Apply .
3. In the Security Policies view, select Filters > BruteForce.
4. In the right pane, select the Settings tab.
5. Select the Time Frame field in order to define the amount of time (in seconds) for periodical
monitoring of Brute Force attacks.
6. Select the amount of Min OK Replies to Declare Shared IP.
7. Mark the Shared IP Auto Detection checkbox if you want the filter to automatically detect Shared
IP addresses.
8. In the Shared IPs pane, click the (Add) button to manually add Shared IPs to the list (this
list will display the manually added IPs as well as the IPs detected by the Security Filter and
declared as Shared IPs).
9. In the Ignored IPs pane, you can add, edit or delete IP addresses that the Security Filter will not
check for Brute Force attacks (use this for known IPs, such as administrators or scanners).
10. Select the Profile to use to define thresholds for potential Brute Force attacks.
To Manually add an IP to the Shared IP list
1. Click the (Add) button in the Shared IPs pane.

2. Follow the settings as described in the table below.
Table 23: Shared IP settings
Field Description
IP Enter the address of the Shared IP.
Description Enter a description for the Shared IP.
To add an IP to the Ignored IP list
1. Click the (Add) button in the Ignored IPs pane.

Table 24: Ignored IP settings
Field Description
IP Enter the address of the Ignored IP.
Description Enter a description for the Ignored IP.

Security Tools
Configuring the BruteForce Profiles

The Profile settings for the BruteForce Security Filter allow the user to configure thresholds for
determining whether certain IPs present a risk of attempting to carry out a Brute Force attack. The
Profiles are also used to define the threshold to deal with Shared IPs.
To configure the Profile
1. Click the (Add) button in the Profiles pane.

Table 25: BruteForce Profile Parameters
Field Description
Name Enter the unique name of the profile.
Description Enter a description for the profile.
Action Enter the action to perform upon profile activation and time frame for the action.
Options for the Profile Actions are:
• Log Once – The defined threshold has been met and logged once in the
Security Event Logs (in the event of an attack, this is useful to refrain from
multiple log entries).
• Log Event Only – The defined threshold has been met and logged in the
Security Event Logs (each request is logged as a separate event).
• Block and Log Event – the IP has been blocked and an event has been
logged.
Minimum The minimum number of hits before threshold is reached and events are logged.
Threshold Hits
per IP
Minimum Bad The minimum number of bad replies logged after threshold is reached.
Replies after
Threshold
Minimum Bad The minimum number of bad replies for Shared IPs as set within a configured
Replies for time frame.
Shared IPs
within
configured time
frame (%)
….for The amount of time (in seconds) for the action:
• Log Once – the event will be logged once. In the event that the IP has
reached the defined threshold after the set time period, it will be logged
again.
• Log Event Only – Events will be logged for the set time only.
• Block and Log Event – The IP will be blocked for the set time and each
request will be logged as a separate event during that time.
BruteForce Security Filter Refinements

BruteForce Security Filter refinements allow defining rules on the Application Path level. The
Refinements tab allows the user to define the rules and patterns to apply to a specific page in a Web
Application, Tunnel, Host, or Application Path.

Security Tools
To configure the BruteForce Security Filter Refinements

1. In the Security Policies view, select Filters > BruteForce Security Filter.
2. Select the Refinements tab and click the (Add) button.

3. Complete the fields using the table below and click OK.
Table 26: BruteForce Security Filter Refinements
Field Description
Web Application Web application containing the tunnel.
Host Host containing the Application Paths where the security filter will be applied.
Application Path Application Path where the security filter will be applied.
Page Allowed relative path/page below the host.
If no Pattern is In the event that a request from an IP does not match any Pattern (see below),
Detected, treat the user can decide whether or not to treat the reply as a Good Reply or Bad
Reply as: Reply.
• Good Reply—The request from the IP was not supposed to match any of the
patterns defined to intercept Brute Force attacks, therefore, this is a good
reply.
• Bad Reply—The request from the IP should have matched any of the
patterns defined to intercept Brute Force attacks, therefore, this is a bad
reply.
Use Profile Select the Profile to use from the drop-down menu. The selected Profile rules will
be applied to the defined page.
You can use the button to add a Profile from this location.
To add a pattern
1. In the Patterns pane click the (Add) button.

2. Select the Pattern Type from either Good Reply or Bad Reply.
3. Enter the Body Pattern or Status Code (see HTTP Error Number Reference for further
information on Status Codes).
Note: Patterns are checked according to the order they appear in the table. You can use the Up/
Down arrows to move patterns up or down in the list.

Security Tools
Database Security Filter

The Database Security Filter screens request parameters for a number of threats, including
embedded harmful SQL commands. It receives parameters and validates the values to assure the
content conforms to standard inputs and do not generate database related problems.
Enable the Auto Refinements option (as described in Setting the Security Filter Run Mode,
page 88) to enable refinements to be automatically added to the Database Security Filter.
The Database Security Filter algorithm provides decision-making with imprecise data inputs,
applying a form of artificial intelligence validation. It uses a Database Query Parser Engine to locate
well-formed and partial SQL command that hackers might employ to perform data manipulation. It
will generate events for requests that can cause database damage and can reveal application bugs
that might be used for back-door database entry.
The internal engine implements ANSI SQL and leading database dictionaries such as MSSQL and
ORACLE.
HTTP parameters can be, in some cases, Base64 encoded. If the parameter value is not decoded,
policy inspection of the encoded value will not enable attack detection.
AppWall applies multiple heuristics on parameter values to detect Base64-encoded values. The
encoded parameters will be decoded before policy enforcement and rule inspection is applied.
By default this functionality will be enabled.
Default Status
By default, the Database Security Filter is enabled and does not require specifications to be applied.
If the Security Filter is used in conjunction with the WebServices, XML or Parameters Security
Filters, those Security Filters must be sequenced before the Database Security Filter.
At the filter level, you can define global Database Security refinements.
Database Security Filter Rule ID

The Database Security Filter is comprised of a variety of security validations. Each validation is
assigned a Rule ID.
With the Quick-Click refinement functionality, ready-to-use specifications are generated that identify
the rule that trigger the generation of an event. Information about the Rule ID can be found in the
Event Log Properties dialog box of the Security Log, which is accessed by double-clicking the log
entry.
By accepting the Quick-Click refinement, the parameter will only be exempt under the individual
Rule IDs. To make the parameter exempt from all Rule IDs, click Discard All Rules.
Configuring the Database Security Filter

Use this procedure to configure the database security filter.
To configure the Database Security Filter

1. Defining parameters that will not be screened by the Security Filter.
2. Defining rules that will not be screened in the Global filter level.
3. Defining rules that will not be screened in the Application Path level.

Security Tools
To configure the Database Security Filter

1. In the Configuration view, select Filters > Database.
Click Submit and Save and Apply .
3. In the Security Policies view, select Filters > Database.
4. In the Settings tab, click the (Add) button to add a rule ID to the Unscreened Rules List at
the Global Level, or select an existing entry and click the (Edit) button to modify.
5. Select the Refinements tab.
modify.
7. Select either Excluded Parameters or Excluded Rules.
8. Complete the fields as described in the table below.
Table 27: Database Security Filter settings
Field Description
Web Application Web application containing the host.
Host Host containing the Application Paths where the Security Filter should be used.
Apply to Other When selected, the Security Filter will evaluate requests to undefined pages
Pages under the Application Path.
Page Allowed relative path/page below the host. Allows entry of extensions using the
asterisk character followed by the period and extension, for example: *.xxx The
entry must end with either an extension or a forward slash.
Unscreened Use Add, Edit, Accept, and Delete to specify parameters that should not be
Parameters List screened. Clicking Add or Edit opens a dialog that allows adding or editing refined
parameters by Parameter Name. In the dialog, select the Regular Expression
checkbox if you are adding or editing a regular expression rather than a single
parameter.
For basic steps to use Quick-Click Refinements, see Refining Security Filters, page 88.
FilesUpload Security Filter

The FilesUpload Security Filter monitors the files upload behavior of Web Applications. By default,
the Security Filter generates an event when any file is uploaded. Configuring the Security Filter
allows you to determine the conditions under which a file upload will generate an event.
Configuration can be based on:
• Application Path—Specifies destinations where uploads are permitted.
• Extension—Determines what file extensions are permitted for uploads.

Security Tools
• HTTP Method—Specifies PUT or POST as the acceptable upload type.

• Retrieval Permission—Determines if it is acceptable for users to retrieve files from the upload
destination.
Notes
• When using the HTTPMethods Security Filter, be certain to allow the method (Put or Post) that
you are using.
• The specification in the HTTPMethods Security Filter should be made on the appropriate
Application Paths and not necessarily the Application Path where the PUT or POST is first
enabled.
• If you are using the POST method, the Target URL is automatically configured with FilesUpload
and is enabled to evaluate as valid all upload of files using the POST HTTP method.
• The FilesUpload Security Filter evaluates all configured requests irrespective of whether or not
the server is able to process the HTTP method used in the request.
Note:
For this example, assume the FilesUpload Security Filter is set to evaluate requests to upload picture
files (gif, jpg, jpeg, bmp) to a specific application. An event is generated and the request is blocked
when a user uploads a DOC file to the specified Application Path.
In addition, if the Security Filter’s Prevent File Retrieval From the Upload Destination property is
enabled, another event is generated if the user accesses the file once it is uploaded.
Note: The Full Auto Policy Generation mode is not available for this Security Filter.
Configuring the FilesUpload Security Filter

Use this procedure to configure the FilesUpload security filter.
To configure the FilesUpload Security Filter

1. In the Configuration view, select Filters > FilesUpload.
2. Ensure that Enable Log is selected. If not, select this field and Click Submit and Save and
Apply .
3. In the Security Policies view, select Filters > FilesUpload.
4. In the Settings tab, click the (Add) button. Enter and extension and click Add or OK.
5. In the Refinements tab, click the (Add) button.

6. Select Enable POST or Enable PUT Upload Type to specify the valid upload type for this
definition.
7. In the General tab, complete the fields using the table below. Note that the options change
whether Enable POST or Enable PUT was selected.
8. In the Extensions List tab, select which extensions you wish by check marking Allow or Block
boxes respectively by moving extensions from the all selected pane to the selected pane.

Security Tools

11. On the AppWall Management Application toolbar, click Apply.
Table 28: FilesUpload Security Filter options - Enable POST Upload Type
Field Description
Post Acceptor
Reported on Web Application containing the directory where the file is uploaded.
Tunnel Tunnel used to monitor the script where the action is submitted.
Host Host that containing the directory where the action is submitted.
Role Select the role for the role-based security policy.
Application Path The path of the acceptor of the Post action, usually the CGI or script.
Post Destination
Reported on Web Application that contains the script where the action is submitted.
Tunnel Tunnel used to monitor the upload destination.
Host Host used to monitor the destination where the action is submitted.
Application Path Application Path used to monitor the upload destination.
Parameter Name POST parameter used in the file upload.
Prevent File When selected, generates events when requests access uploaded files.
Retrieval from the
Upload Destination
Prevent Addition When selected, generates events about configurations that may pose a
FilesUpload security risk when giving Post Acceptor permission on the same directory as a
Configuration on Post Destination. It is recommended that this setting be enabled.
Post Destination
Table 29: FilesUpload Security Filter options- Enable PUT Upload Typ
Field Description
Using PUT
Reported on Web Application containing the directory where the file is uploaded.
Tunnel Tunnel used to monitor the script where the action is submitted.
Host Host that containing the directory where the action is submitted.
Application Path The path of the acceptor of the Post action, usually the CGI or script.
Prevent File When selected, events are generated by requests to access uploaded files.
Retrieval from the
Upload Destination
Note the FilesUpload Security Filter is automatically enabled on the Post Destination directory. The
FilesUpload Security Filter will appear on two paths if the configuration spans two application paths,
Post Acceptor and Post Destination.
GlobalParameters Security Filter

The GlobalParameters Security Filter evaluates parameter values and can be used to evaluate
parameters defined in other parameter-related Security Filters. As with most Security Filters, the
GlobalParameters can be configured globally or for specific Application Paths.

Security Tools
GlobalParameters validation is supported for URL, Path, XML, WebServices and Cookie Parameters
providing the proper settings are enabled on those Security Filters. When used in conjunction with
these Security Filters, the Security Filter sequence should be XMLSecurity, WebServices,
GlobalParameters, Parameters, Vulnerabilities, and then Database. Note that parameter checks
cannot be applied to overlap one another.
The GlobalParameters Security Filter provides a two part screening process in the following
sequence:
1. Default Expressions iterative screening for each listed expression.
2. Refinements applied to Application Path requests still deemed valid.
3. The GlobalParameters Security Filter supports use of the Bypass Flag. For information about the
Bypass Flag, see Setting the ByPass Flag and Operating Mode, page 123.
Default Status
Because the GlobalParameters Security Filter is not enabled by default, it must be enabled on the
Application Path using the Security Policies view.
Note:
For example, assume that corporate databases located on server-1 (10.0.0.155) process requests
from Web applications residing on remote servers. Requests may be for different databases in
separate directories. The databases contain an array of fields.
If characters that are not valid for database field values are detected, the requests that contain
them are stopped from reaching the server.
The Security Filter can be configured as follows:
• To restrict parameters to a length of 256 characters and to only allow alphanumeric characters,
periods (.), commas (,), characters (@), and white spaces.
• Refinements setting for the Application Path specify that percent (%) characters should generate
an event.
Assume the following request is submitted:

http://10.0.0.15/home/authors/address.asp?Name=”Mr. And
Mrs.Adams”&Address=”%5c%2e%2e%5cwinnt%5cwin.ini”
This request is first checked if it is valid according to the defined allowed expression. It is then
checked at the Application Path Refinement level. Because the “%” character is not one of the
characters allowed, the request is stopped and a security page is returned.
Note: The GlobalParameters Security Filter supports Validation Bypass for Parameters. A parameter
bypass is a filter-to-filter communication system of validation credentials. In turn, these credentials,
carried by a parameter, can be honored by future Security Filters as a free exemption from
validations.
Parameter Value Types

The table below lists parameter types the GlobalParameters Security Filter can evaluate:

Security Tools
Table 30: Parameter Types for GlobalParameters Security Filter
Type Description
Long A value range where Max/Min values +/-2,147,483,648
Float Double precision float 15 decimal-digits for mantissa and range of:
+/-308 for exponent
Number range is +/-1.7976931348623157E 308
Smallest positive number is: 2.2250738585072014 E -308
Numeric Numeric range value (digits 0-9)
Alpha Alpha length. Values limited to characters a-z and A-Z.
AlphaNum Alpha-numeric length. Values limited to: a-z and A-Z.
Expression Valid regular expressions with limits dissected by the regular expression
which can be either value length or range.
String String length. Characters that may pass depend on the tunnel properties
(by default, only chars that pass text-normalization (codepage and UTF8
normalization).
To prevent buffer overflows without preventing sizable inputs in
parameters, enter the maximum size in kilobytes. For example, if a buffer
overflow error occurs at 10MB (10240 KB), specify a maximum that is
slightly less than this value (10235).
Null Parameter Only empty values permitted (no greater than zero length).
This setting should not be confused with the Allow a Null Value setting
that is supported with other parameter types and allows Null as an
alternate value.
Enabling Parameter Validation

If other Security Filters are enabled to validate parameters and you want the Global-Parameters
Security Filter to validate these parameters, you must enable parameter validation.
To enable parameter validation,

1. In the Security Policies view, select Filters > GlobalParameters.
2. In the right pane, select Analyze All Participating Parameters.
Once this is accomplished, the following parameter types can be validated when the associated
Security Filters are enabled:
• Path Parameters
• Cookie Parameters
• XML Parameters
• Web Services parameters
Configuring the GlobalParameters Security Filter

The GlobalParameters Security Filter is configured on two levels:
• Global Settings used to evaluate all request parameters passed to the server.
• Refinements used to evaluate request parameters passed to the Application Path.

Security Tools
To validate parameters passed to the server

1. In the Configuration view, select Filters > GlobalParameters.
2. Ensure that Enable Log is selected. If not, select this field and click Submit and Save and
Apply .
3. In the Security Policies view, select Filters > GlobalParameters.
4. Select the Analyze All Participating Parameters check box to validate every parameter passed
through the GlobalParameters Security Filter.
5. Select the Force Additional Security Validation by GlobalParameters Filter to assign the
parameter a Bypass Flag.
6. Click the Settings tab.
modify.
8. Complete the fields using the table below.
9. Click the Refinements tab to open the Configure Page Settings dialog box.
Table 31: GlobalParameters Security Filter options
Field Description
Value Type Select the expression type.
Minimum Length Enter the lower bound range value or minimum string length.
Not applicable for Expression type parameters.
Maximum Enter the upper bound range value or maximum string length.
Length Not applicable for Expression type parameters.
Allow a Null Select to allow parameters with Null values, for example, “SearchString=” where
Value the second part of the expression is empty.
When disabled, parameters with Null values are considered invalid.
Apply to Listed Select to validate only parameters in Parameters List. When selected, a
Parameters Parameter List area opens for you to build the parameter list.
Apply to All Select to validate every parameter passed through the Security Filter.
Parameters
Always Check Select to always check all parameters and ignore Bypass credentials.
All Parameters
and Ignore
Validation
Bypass
Note: The tunnel’s HTTP Message Size properties will set limits on valid HTTP request and reply
sizes. This includes the URL, HTTP headers, and HTTP body sizes. If the defined parameter values
are sizable, you may need to adjust the associated settings to accommodate special requirements.

Security Tools
HTTPMethods Security Filter

The HTTPMethods Security Filter evaluates requests based on the HTTP Methods used in requests. It
determines if the HTTP Method used in the request is supported for the specified page or path. It
allows configurations to be set globally or by the Application Path. When this Security Filter is
enabled, requests are blocked and events are generated by requests containing methods that are
not defined in the Security Filter’s configuration.
The HTTPMethods Security Filter evaluates requests as follows:
If the Security Filter is enabled on the Application Path and the Security Filter’s Refinements tab
contains rules for that Application Path, those rules are used.
If the Security Filter is enabled on the Application Path and not covered by rules on the Refinements
tab, the Security Filter uses the rules defined on its Settings tab.
Default Status
The HTTPMethods Security Filter is enabled by default for all Application Paths under AppWall.
Initially, only GET and POST methods are defined as valid. Any request containing another HTTP
method results in an event and blocks the request.
Note:
For this example, assume that the HTTPMethods Security Filter has been configured to generate
events for requests using methods other than GET or POST and the following request is received.
DELETE /Database/Accounts.dbf HTTP/1.1
If-Modified-Since: Mon, 22 May 1970 12:00:00 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: Southern
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache
Because the request uses the DELETE method, an event is generated when the request is received.
Note: The HTTPMethods Security Filter has no relationship to the Web server’s support or lack of
support for HTTP methods. It generates events based on its configuration, not on whether the Web
server is capable of processing the request method.
Configuring the HTTPMethods Security Filter

Use this procedure to configure the HTTPMethods security filter.
To configure a Security Filter

1. Set basic configurations in the Configuration view.
2. Specify default methods in the Settings tab.
3. Specify methods for specific Application Paths using the Refinements tab.
HTTPMethods Security Filter Default Methods

Use this procedure to set up the HTTPMethods security filter default methods.

Security Tools
To set the HTTPMethods Security Filter defaults

1. In the Configuration view, select Filters > HTTPMethods.
Click Submit and Save and Apply .
3. In the Security Policies view, select Filters > HTTPMethods.
5. Use Add, Edit, or Delete to specify the default methods.
HTTPMethods Security Filter Refinements

Use this procedure to set up HTTPMethod security filter refinements.
To set the HTTPMethods Security Filter refinements

1. In the Security Policies view, select Filters > HTTPMethods Security Filter.
2. Click the Refinements page. Note that the Tips column shows any definitions generated by
learned refinements.
3. To add a method, click the (Add) button, or click the (Edit) button to modify a
method.
4. On the Configure Page Settings dialog box complete the fields using the table below and click
OK.
— Header—Description
— Web Application—Web Application containing the host.
— Tunnel—Tunnel containing the host.
— Host—Host containing the Application Paths where the Security Filter should be used.
— Application Path—Application Path where the Security Filter should be used.
— Role — Role for the role-based security policy
— Page—Allowed relative path/page below the host. Allows entry of extensions using the
asterisk character followed by the period and extension, for example: *.xxx
The entry must end with either an extension or a forward slash.
— Pathname—Auto-generated field.
— Apply Default Methods—Select to include the default HTTP methods.
— Additional Permitted Methods—Use Add, Edit, Accept, or Delete to build the list.
Notes
• Routing on specifications works in the same manner as the routing for Application Paths.
• Specifications with the greatest number of matching path segments will be given the request.
For example, assuming the following structure on the Web server:

Security Tools
If HTTPMethods is configured so that:

WebPages has the HTTPMethods Security Filter enabled using the default
methods.
/Main and its sub-directories allow only GET.
/Main/Public/JJ/ allows GET, DELETE, COPY, and PUT.
/Main/Public/JJ/upload.asp allows only POST.
The configuration would be:
Table 32: HTTPMethods example
Path HTTP Methods Definition

WebPages/Data Default only Application Path
WebPages/Main/Private GET only Main
WebPages/Main/Public/RC GET only Main
WebPages/Main/Public/JJ/ GET, DELETE, COPY, /Main/Public/JJ/
PUT
WebPages/Main/Public/JJ/ upload.asp POST only /Main/Public/JJ/upload.asp
Logging Security Filter

The Logging Security Filter allows you to log request and reply messages and can be used for
troubleshooting and monitoring/documenting invalid requests. It allows you to specify the following
properties by request or reply stream:
• Name of the log file
• Maximum log file size
• Log all request or reply headers
• Log all request or reply bodies
Default Status
By default, the Logging Security Filter is disabled. To enable this Security Filter by Application Path,
in the Security Policies view, select the Application Path and select the Security Filter’s Enabled
option button. Note that the Full Auto Policy Generation mode is not available for this Security Filter.
When enabled, the Logging Security Filter’s default configuration uses the following properties.
Table 33: Logging Security Filter’s Default Configuration Properties
Stream Parameter Description

Request Log File Name \Event\Logging\Request.Log
Log File Maximum Size (KB) 4882
Log Request Header Enabled
Log Request Body Disabled
Reply Log File Name \Event\Logging\Request.Log
Log File Maximum Size (KB) 4882
Log Reply Header Disabled
Log Reply Body Disabled

Security Tools
Note:
The Logging Security Filter intercepts the two-way HTTP traffic routed to the Application Paths on
which it is enabled. It takes this information, breaks it down into the HTTP elements, and then
formats it according to the specification in the tunnel.
When files reach maximum size, they are backed-up to a file of the same name with the file
extension “bak”.
The header information begins with ##Tunnel_IP##Date## appended to the appropriate file. The
Body information begins with
Original request: GET /images/ logo.gif?egap=internal HTTP/1.1
Note: Request log
##10.0.0.01##3-30-2003##
GET /demo/whatis.asp?id=17 HTTP/1.1
Accept: */*
Referer: http://10.0.0.19:81/demo/faq.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: 10.0.0.19:81
Cookie: counteKIKI=4
Accept-Encoding: identity
##10.0.0.01##3-30-2003##
GET /demo/whatis.asp?id=16 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/
msword, application/vnd.ms-powerpoint, application/vnd.ms-excel, */*
Referer: http://10.0.0.01:80/demo/faq.html
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: 10.0.0.01:80
Cookie: counteKIKI=4
Accept-Encoding: identity
Note: Reply log
Original request: GET /demo/faq_up.gif HTTP/1.1

Response:
HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/5.0
Date: Mon, 31 Mar 2003 08:43:10 GMT
ETag: "0f15cfea857c01:970"
Content-Length: 0
Original request: GET /demo/query.htm HTTP/1.1

Response:

Security Tools
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 31 Mar 2003 08:43:12 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Tue, 25 Jun 2002 10:00:15 GMT
ETag: "6012be1a2f1cc21:970"
Content-Length: 257
<html>
<head>
<title>Demo Query Analyzer</title>
</head>
<frameset rows="35%,65%" border=0>
<frame src="QueyField.asp" scrolling="no" name="up">
<frame src="query.asp?query=SELECT%20*%20FROM%20categories" name="down">
</frameset>
</html>
Configuring the Logging Security Filter

Use this procedure to configure the Logging security filter.
To configure the Logging Security Filter

1. In the Configuration view, select Filters > Logging.
Apply .
3. In the Security Policies view, select Filters > Logging.
4. Modify the request/reply properties as required.
Table 34: Logging Security Filter options
Field Description
Log File Name The full or relative path to the AppWall folder where the log files are stored.
Log File The maximum log file size. Once a file reaches maximum size, it is written to a
Maximum Size backup file of the same name (overwrites existing) with an added extension of
(KB) “bak” and a new blank log file is created.
Logging request bodies will potentially equal two files, each of the size specified.
“.log”
“.log.bak”
Log Request/ Select to log request/reply headers
Reply Header
Log Request/ Select to log request/reply bodies
Reply Body

Security Tools
SafeReply Security Filter

The SafeReply Security Filter screens outbound responses to determine if they expose sensitive
information, such as credit card numbers, Social Security numbers, and custom patterns. It can
detect valid Social Security number ranges, as well as major credit cards (for example, Visa,
MasterCard, Discover, or American Express).
The Security Filter screens the HTTP Body of each reply message for patterns and values matching
those specified in the Security Filter’s definition, which can include:
• Credit card numbers numeric values matching major credit card syntax in length and value. This
includes numerical algorithm and check values used to assure screened numbers meet credit
card check values.
• Social Security numbers looks for formatted strings matching valid Social Security number
ranges (0##-##-#### to 500-##-####).
• Custom patterns looks for text matching user defined patterns, either regular expression or
straight text. This is extremely powerful if you are looking for a set number or number format
such as an account or form number.
Any response message containing numbers not conforming to the Security Filter configuration will
be blocked and an event will be generated.
Mark Out/Redirect - Security Method

The system can also be set to replace credit card numbers with fake characters, or to redirect the
entire request to a secure page.
Default Status
The SafeReply Security Filter is enabled by default with credit cards and Social Security number
screening.
For the purpose of intensive, global data leakage prevention policy enforcement, which also inspects
the content of downloaded files from the secured application, you can configure AppWall to forward
the downloaded content to the DLP server, which supports ICAP protocol, for data leakage
inspection. If policy violation is detected and the file can be modified (for example, MS Excel files),
the ICAP server will modify the file. In cases where the file cannot be modified (for example, pdf
files) the ICAP server will reply with a status code notifying AppWall not to forward the file to the
client and AppWall will redirect the client to a security page.
The system was tested with Symantec for virus inspection in replies, and with WebSense for DLP
policy enforcement.
To enable ICAP-based DLP inspection, configure the Security Policy > Filters > SafeReply >
ICAP server settings.
Additionally, you must verify that the SafeReply security filter is enabled in the relevant application
path.
In the scenario of user authentication, AppWall will also redirect, to the ICAP server, the user and
the role information, as retrieved from the Radius/LDAP authentication servers.
The preview field must be enabled. Make sure that the Safe Reply filter is enabled in the security
policy for the relevant application path.
SafeReply Security Filter Global Settings

Configuring the SafeReply Security Filter includes enabling and disabling the types of information
that should be screened:
• Credit cards numbers
• Social Security numbers
• Custom patterns

Security Tools
To configure the SafeReply Security Filter

1. In the Configuration view, select Filters > SafeReply.
3. In the Security Policies view, select Filters > SafeReply.
5. In Security Method, select either Mark out Character, which will replace all sensitive information
with fake characters, or Redirect to the Security Page, which will direct the entire request to a
secure page.
6. If you selected Mark out Character, accept or change the default character used to mask the
sensitive information in the Character field.
7. Select or clear the Check for Social Security Numbers field.
8. Select or clear the Check for Credit Card Numbers field. For information about card types and
ranges, see Credit Card Types.
9. In the Custom Pattern List area, click the (Add) button to add a custom pattern, or select
an existing pattern and click the (Edit) button to modify it. You may also delete a pattern or
use the check box in the Enabled and Expression columns to enable/disable it.
10. In the dialog box that displays, specify the pattern using the table below and click OK.
12. On the AppWall Management Application toolbar, click Apply.
Table 35: SafeReply Security Filter options
Field Description
Pattern Enter the pattern for which to screen.
Use Regular Select if the pattern is a regular expression. Then use Check to validate the
Expression expression.
SafeReply Security Filter Refinements

SafeReply Security Filter refinements define exemptions on the Application Path level.
To configure the SafeReply Security Filter Refinements

1. In the Security Policies view, select Filters > SafeReply Security Filter > Refinements.
2. Click the (Add) button to add a new refinement, or select an existing refinement and click
the (Edit) button to modify it.

3. Complete the fields using the table below and click OK.

Security Tools
Table 36: SafeReply Security Filter options
Field Description
Reported on Web Application containing the host.
Check All Pages When selected, patterns in the Pattern List are exempted on all pages under the
Under the Application Path. This disables the Page and Pathname fields.
Defined
Application Path
The entry must end with either an extension or a forward slash.
Pathname Specify the relative URL to the page.
Pattern List Pattern to which the refinement applies the exemption.
Pattern Type Select the pattern type from the drop-down list. When Custom Pattern or Regular
Expression is selected, a dialog box requires you to select the specific pattern
and associated prefix or suffix.
Pattern Select the custom or regular expression pattern from the drop-down field. This
field is enabled when Custom Pattern or Regular Expression is selected in the
Pattern Type field.
Type and Ranges

The following types and ranges of information are checked.
• Credit card types
• Social Security number types and ranges
Credit Card Types

The credit card check screens for the following credit card types:
• MasterCard
• Visa
• American Express
• Discover
• Diners Club
• Carte Blanche
• Discover
• EnRoute
• JCB
Social Security Number Types and Ranges

The following table lists the social security number types and ranges.

Security Tools
Table 37: SSN Types and Ranges
Range Area Range Area Range Area

001-003 NH 318-361 IL 518-519 ID
004-007 ME 362-386 MI 520 WY
008-009 VT 387-399 WI 521-524, 650- CO
653
010-034 MA 400-407 KY 525, 585, NM
648-649
035-039 RI 408-415, 756- TN 526-527, 600, AZ
763* 601, 764-765
040-049 CT 416-424 AL 528-529, 646- UT
647
050-134 NT 425-428, 587, MS 530, 680 NE
588, 752-755*
135-158 NJ 429-432, 676- AK 531-539 WA
679
159-211 PA 433-439, 659- LA 540-544 OR
665
212-220 MA 440-448 OK 545-573, 602- CA
626
221-222 DEL 449-467, 627- TX 574 AL
645
223-231, 691- VA 468-477 MN 575-576, 750- HI
699 751
232-236 WV 478-485 IA 577-579 DC
232, 237, 246, NC 486-500 MI 580 VI
681-690
247-251, 654, SC 501-502 ND 580-584, 596- PR
658 599
252-260,667, GE 503-504 SD 586 GU
675
DC = District of Columbia
VI = Virgin Islands
PR = Puerto Rico
GU = Guam
AS = American Samoa
PH = Philippine Islands
RB = Railroad Board
WebServices Security Filter

The WebServices Security Filter screens the components of a WebServices application and
disseminates its messages for processing by other Security Filters.
The WebServices Security Filter screens requests for SOAP operations and detects countering
dictionary, encoding, and structure manipulations. The Security Filter provides full messages
availability control and, in conjunction with other Security Filters, secures against common
application threats like SQL injection, parameters manipulation, and so forth.

Security Tools
Default Status
By default, the WebServices Security Filter is disabled. Before enabling the Security Filter, you must
define the WebService operations you want to consider valid. No events are generated if the Security
Filter is enabled without a configuration. Note that the Full Auto Policy Generation mode is not
available for this Security Filter.
Note:
The following shows a SOAP request for a search operation.

POST http://mySearchServer/Search_WebService HTTP/1.1SOAPAction:
urn:SearchActionContent-Type: text/xml; charset="UTF-8"Host:
mySearchServerContent-Length: 411Proxy-Connection: Keep-Alive
<?xml version="1.0" encoding="UTF-8" standalone="no"?><SOAP-
ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/
"xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"xmlns:xsd="http://
www.w3.org/1999/XMLSchema"><SOAP-ENV:Body><m:doSearch
xmlns:m="urn:MySearch">
<keyword>My_Search_String</keyword>
<maxResults>100</maxResults>
</m:doSearch>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This request nests key components within the XML structure and the SOAP envelope. Working in
conjunction with the WSDL file specifications, the WebServices Security Filter allows you to screen
for invalid operations.
For this example, assume a hacker submits a request that uses a WebServices operation
DeleteRecord to attempt to delete records.
Assume also that while this functionality exists and is defined in the WSDL, it is not intended for use
by remote users. Note also, that the request is submitted in the form of an HTTP GET request.
GET /Operations/service1.asmx/DeleteRecord?RecordNum=611&RecordNum=613
HTTP/1.1
If the WebServices specification does not include the DeleteRecord operation as an accepted
operation, this request would be considered invalid.
If the WebServices Security Filter is configured to check the SOAP Action header and to screen for
requests that do not use SOAP, events are then generated by requests using simple GET requests,
which can be easily generated by a hacker.
If the WebServices Security Filter is sequenced before the Database Security Filter and is configured
to pass parameters on to subsequent Security Filters, all parameters are screened for dangerous
hacking values, such as a SQL injection of a delete command.
Configuring the WebServices Security Filter

Adding specifications for a Web Services Security Filter requires the following:
• Logs have been enabled: In the Configuration view, select Filters > WebServices. Ensure that
Enable Log is selected. If not, select this field and click Submit and Save and Apply .
• A configuration for Web Application > Tunnel > Host > Application Path where the
WebService file is located.
• One or more imported WSDL file.
The WebServices Security Filter provides three levels of validation:

• XML Only—Validates the structure of the XML to verify that the XML is well formed. Does not
perform any other validation.

Security Tools
• Operation Name—Validates XML and ensures that requests use allowed operations.
• Operation name & Structure—Validates the XML and Operation name, and that the
WebServices message complies with all WSDL requirements, such as enforcing parameter order
and operation sequence.
In addition, the WebServices Security Filter provides the following features that can be enabled or
disabled.
• Include WebServices Parameters in Subsequent Parameter-Related Filter Checks
It is very important to register the parameters and values for validations performed by
subsequent parameter related Security Filters, such as the Parameters Security Filter, for value
validation, and the Database Security Filter for database injection validation.
• Block HTTP requests that are using the GET or POST methods to access these
operations
When selected, allows only SOAP requests. Does not allow non-SOAP Requests that use GET and
POST methods. Non-SOAP requests are sometimes used either to debug or to hack the server.
• Check SOAP action
Validates that requests use the required SOAP action header according to the WSDL file.
The following table describes the features and settings in the WebServices Wizard.
Table 38: WebServices Security Filter options
Setting Description
Type WSDL file Full or relative path or browser for to the WSDL file.
location
WSDL file name The relevant file from the imported WSDL files.
Service name The service name from the available services in the WSDL file.
Port Name The name of the available ports in the WSDL file.
Service location The full URL listed in the WSDL file that remote users use to connect to the
selected service.
Denied Operations in the Accepted Operations list evaluate as invalid. These can be
Operation selected and moved to the Allowed Operation list.
Allowed Operations in the Accepted Operations list evaluate as valid. These can be
Operation selected and moved to the Denied Operation list.
The entry must begin with a forward slash (“/”) and end with either an extension
or a forward slash.
Validation Type Select the level of validation to apply:
• XML Only—Validates that the XML is well-formed. Performs no other
validation.
• Operation Name—Validates XML and that the request uses allowed
operations.
• Operation Name & Structure—Validates the XML and operation name, and
that the message complies with all WSDL requirements.

Security Tools
If you enable the WebServices Security Filter’s Forward the Parameters to other Filters property, it
must be sequenced before the other parameter-related Security Filters.
Managing WSDL Files

Use the following procedures to manage your WSDL files.
To import a WSDL file

1. In the Security Policies view, select Filters > WebServices.
2. Click Import WSDL to launch the wizard.
To view an imported WSDL file

> Select a WSDL file from the list and click View WSDL.
To remove a WSDL file from the list

> Select a WSDL file from the list and click Delete WSDL.
XMLSecurity Security Filter

The XMLSecurity Security Filter parses XML in a request, extracts values, and checks them using the
other parameter-related Security Filters. The parameters to evaluate are specified in the
XMLSecurity Security Filter’s configuration.
Notes
• This Security Filter only parses requests where the Content-Type header is set to one of the
following: Content-Type=text/xml Content-Type=text/*
• If the Security Filter’s Block Requests with Invalid XML Body is selected, requests containing an
invalid XML body will result in the generation of an event.
Default Status
The XMLSecurity Security Filter is disabled by default. Before enabling this Security Filter, you should
configure it with page names and set it to pass parameters to the sub-sequent Security Filters. No
events are generated unless this is done. Note that the Full Auto Policy Generation mode is not
available for this Security Filter.
Note:
Parameter names are created using the full hierarchy of nested tags and attributes containing each
value. The created parameters are passed for validation by subsequent parameter-related Security
Filters defined in the Application Path.
In this example, assume that the XMLSecurity Security Filter is configured for /imagine/ Secure/
InMessages.asp and that the Security Filter is enabled on the /imagine/ Application Path for the
post-acceptor page (Action URL).

Security Tools
Assume also that the following HTTP request message is received with an XML body:
POST /imagine/Secure/InMessages.asp HTTP/1.1
Content-Type should specify text/xml
Accept: */*
Accept-Language: en
Referer: http://www.Radware.com/imagine/Secure/InMessages.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows)
Accept: */*
Accept-Language: en
Referer: http://www.Radware.com
<?xml .. ?>
<catalog>
<book>
<title>War and Peace</title>
<price currency="USD">20</price> <author>Tolstoy</author>
</book>
<book>
<title>Lord of the Rings</title>
<price currency="USD">23</price>
<author>J. R. R. Tolkien</author>
</book>
</catalog>
catalog.book.title = 'War and Peace'catalog.book.price = '20'
catalog.book.price.currency = 'USD'catalog.book.author = 'Tolstoy'
catalog.book = ''
catalog.book.title = 'Lord of the Rings'catalog.book.price = '23'
catalog.book.price.currency = 'USD'catalog.book.author = 'J. R. R.
Tolkien' catalog.book = ''
catalog = ''
The following table shows the parameter names and corresponding values generated when the
Security Filter’s Parse Attributes as Parameters is enabled.
Table 39: Parameter Names and Values
Name Value
xml//catalog/book/title “War and Peace”
xml//catalog/book/price 20
xml//catalog/book/price/ USD
currency
xml//catalog/book/author “Tolstoy”
xml//catalog/book/title “Lord of the Rings”
xml//catalog/book/price 23
xml//catalog/book/price/ USD
currency
xml//catalog/book/author “J.R.R.Tolkien”

Security Tools
Notes
• The naming of values parsed from the XML tags is performed using the tag structure and a
prefix “xml/”.
• For Attributes: xml/+/ElementTag+//TagAttribute For Elements: xml/+/
ElementTag1+/ElementTag2+/ElementTagn where ElementTag1-n are nested XML tags
such as <catalog><book>0</book></catalog> or <catalog><book /></catalog> , the
TagAttribute is an attribute of an XML tag such as “currency=USD” in <price currency="USD">
Configuring the XMLSecurity Security Filter

Use this procedure to configure the XMLSecurity security filter.
To configure the XMLSecurity Security Filter

1. In the Configuration view, select Filters > XMLSecurity.
3. In the Security Policies view, select Filters > XMLSecurity.
4. Select the desired fields using the table below.
5. Right-click the table and click Add from the right-click menu.
6. Use the table below to complete the fields on the dialog box that opens and click OK.
Table 40: XMLSecurity Security Filter options
Field Description
Parse Attributes Enables the creation of parameters from the attributes of an XML tag. The
as Parameters parameters created will contain the attribute value.
Block Requests Determines if the XML is well-formed. Requests that fail parsing are not
with Invalid XML evaluated by subsequent parameter-related Security Filters and are blocked by
Body the AppWall Gateway.
Pass Requests Determines if the XML is well-formed. Requests that fail parsing are evaluated by
with Invalid XML subsequent parameter-related Security Filters.
Body
Application Path Application Path where the Security Filter should be used. This Application Path is
expected in the HTTP POST request.
The entry must begin with a forward slash (“/”) and end with either an extension
or a forward slash.

Security Tools
Table 40: XMLSecurity Security Filter options (cont.)
Field Description
Recurse to Sub- Indicates that the page definition applies to all directories under the Application
Directories Path, provided the request URL does not better match another existing
Application Path.
Included for These are page definitions that will be included in the parsing and XML
XML Security normalization checking, provided there are no “Excluded from Defined Pages”
working against the definition.
Excluded from By default, all pages are excluded. These definitions are only intended to work
Defined Pages contra to page ranges defined in the definitions marked “Included for XML
Security”.
Note: If there are no “Included for XML Security” definitions that include this
definition, it should be deleted.
In order for the XML Security Filter to process a request into parameters, the following criteria must
be met:
• The request must not match a definition specified in the Security Filter’s Excluded from Defined
Pages property.
• The request must fall under one of the definitions specified in the Security Filter’s Included for
XML Security property.
• The request must be a HTTP POST containing XML body.
• The XML must be well-formed. If the XML fails parsing, no event is generated regard-less of
whether Block Requests with Invalid XML Body or Pass Requests with Invalid XML Body is
enabled.
Managing XMLSecurity Security Filter Specifications

You can manage the specification of the XML Security Filter. This includes Adding, Deleting and
Editing Settings, such as modifying Include and Exclude pages, Re-curse functionality and more.
To manage the XMLSecurity Security Filter Specifications

1. In the Security Policies view, select Filters > XMLSecurity.
2. If you require tag attributes to be parsed as separate parameters, click Parse Attributes as
Parameters.
3. Click either Block Requests with Invalid XML Body or Pass Requests with Invalid XML Body.
4. Click the (Add) button, or select an existing entry and click the (Edit) button to modify
it.
5. On the Configure Page Settings dialog box, select from the drop-down lists: Web Application >
Tunnel > Host > Application Path.
6. In the Page box, enter a valid page or file extension (*.asp).
7. If you want the definition to apply to sub-directories, click Recurse to Sub-Directories.
8. Select either Included for XML Security or Excluded from Defined Pages and click OK.
9. Click Submit and Save and Apply for your settings to take effect.

Security Tools
Parameters Security Filter

The Parameters Security Filter evaluates parameters in user requests and generates events when
requests are determined to be invalid as set by the Security Filter’s configuration. The Security Filter
can be set to screen only the parameter name and type, or it may be set to include the parameter
value in its evaluation. The following criteria can be used to evaluate parameter values:
• Value Type
• Range
• Minimum/Maximum Length
• Parameter Order
• NULL values
• Regular Expression values
Use this Security Filter to detect harmful inputs to an application (cgi, script) such as parameter
values and types, ranges, lengths, parameter orders, and omissions. It can screen for manipulations
to the business logic, such as changes in prices, account numbers, or mailing address.
The Parameters Security Filter should be used in conjunction with the Vulnerabilities Security Filter.
When using the Parameters Security Filter to evaluate Web Services, XML, or HTTP path parameters,
the Session, WebServices, and XMLSecurity Security Filters must be enabled and sequenced prior to
the Parameters Security Filters.
Enable the Auto Refinements option (as described in Auto Policy Generation, page 166) to enable
refinements to be automatically added to the Parameters Security Filter. Refer to Parameters Auto
Policy Generation Refinements, page 172 for information on how to add or remove (lock)
refinements to/from the filter.
The Parameters Security Filter supports RegEx for specifying parameter values and names. This
allows the Security Filter to evaluate ranges, alpha-only, and subsets for parameter values.
You can specify parameter names, types, and value ranges that the Parameters Security Filter will
use to evaluate parameters sent in requests. The following parameter types can be defined for
validating parameters.
Table 41: Parameter Types
Type Description
Long A value range where Max/Min values +/-2,147,483,648
Float Double precision float 15 decimal-digits for mantissa and range of:
+/-308 for exponent
Number range is +/-1.7976931348623157E 308
Smallest positive number is: 2.2250738585072014 E -308
Numeric Numeric range value (digits 0-9)
Alpha Alpha length. Values limited to characters a-z and A-Z.
AlphaNum Alpha-numeric length. Values limited to: a-z and A-Z.
Expression Valid regular expressions with limits dictated by the regular expression
which can be either value length or range.

Security Tools
Table 41: Parameter Types (cont.)
Type Description
String String length. Characters that may pass depend on the tunnel properties
(by default, only chars that pass text-normalization (codepage and UTF8
normalization).
To prevent buffer overflows without preventing sizable inputs in
parameters, enter the maximum size in kilobytes. For example, if a buffer
overflow error occurs at 10MB (10240 KB), specify a maximum that is
slightly less than this value (10235).
Null Parameter Only empty values permitted (no greater than zero length).
This setting should not be confused with the Allow a Null Value setting
that is supported with other parameter types and allows Null as an
alternate value.
Operating Modes
The Parameters Security Filter provides two validation methods. The validation method you select
determines the Security Filter’s event generation behavior.
Targeted Validation: Checks only the parameters listed and generates an event when a parameter
does not conform to requirements. Allows all other parameters to pass without being checked.
Restricted Parameters with Validation: Allows and checks the parameters listed and generates
an event if it does not conform to requirements. Blocks requests with parameters not on the list.
The method you choose depends on other parameter-related Security Filters in use, the application’s
use of parameters, and the level of parameter monitoring that is required to detect vulnerabilities to
parameter-related threats.
Default Status
By default, the Parameters Security Filter is disabled, no parameters are specified, and the Security
Filter’s internal list of parameter rules is empty. Configure one or more parameters before enabling
the Security Filter. If it is enabled without doing so, events are generated by any request using
parameters.
Note:
For this example, assume an on-line bookstore allows orders of 1 to 5 books in an order. The
Parameter Security Filter is set to evaluate the Books_quantity parameter and generate an event if
the value is not between 1 and 5. The following request results in the generation of an event and
blocking of the request:
GET / myorder.asp?Books_quantity=25 HTTP/1.1
Bypass Parameter Flag

The Parameter Security Filter’s Bypass Parameter Flag can be used to exempt parameters from
evaluation by subsequent Security Filters. The Bypass Flag is transported using a Security Filter
communication system of validation credentials. A Bypass Flag carried by a parameter will be
honored by subsequent Security Filters as not requiring validation.
Note that each parameter defined in the Parameter Security Filter can be set to ignore the Bypass
Flag so that it is evaluated by any other Security Filter that is required to do so. In addition, if an
Application Path’s Force to Successive Filter Validations property is set, all successive Security Filters
will evaluate any parameters if they are configured to do so.

Security Tools
Bypass Flag Scenarios

The following show two Bypass Flag scenarios. These scenarios focus on parameters that are
validated. This example assumes that the same parameters are validated by both Security Filters. In
actual use, this may vary based on your configuration.
Scenario One—Attach Bypass Parameter Flag After Validation
In this scenario, the Parameters Security Filter is sequenced before the GlobalParameters Security
Filter. The following table shows the effects on later GlobalParameters Security Filter evaluations
when enabling the Bypass Flag on the Parameter Security Filter.
Table 42: Bypass Parameter Flag Scenario One
Security Filter Attach Bypass Always Check All Test parameters Bypass Flag
Sequence Parameter Flag Parameters and already validated Status
After Validation Ignore Validation
Bypass
Parameters ON OFF NO Added
GlobalParameters OFF OFF NO Received with flag
Scenario Two—Always Check All Parameters and Ignore Validation Bypass

In this scenario, the Parameters Security Filter is sequenced after the GlobalParameters Security
Filter. The following table shows the effects on the Parameters Security Filter evaluations when
enabling the Always Check All Parameters and Ignore Validation Bypass setting.
Table 43: Bypass Parameter Flag Scenario Two Parameters
Security Filter Attach Bypass Always Check All Test parameters Bypass Flag
Parameter Flag Parameters and already validated Status
After Validation Ignore Validation
Bypass
Parameters ON OFF NO Added
GlobalParameters ON ON YES Received with flag
Note: The Parameters Security Filter checks all parameters that pass the GlobalParameters Security
Filter checks. It does not accept the bypass credentials.
Configuring the Parameters Security Filter

Configuring the Parameters Security Filter involves the following steps:
• Setting the ByPass Flag and Operating Mode
• Setting Query Parameters
• Setting Path and Cookie Parameters
Setting the ByPass Flag and Operating Mode

Use this procedure to set the ByPass Flag operating mode.

Security Tools
To configure the Parameters Security Filter

1. In the Configuration view, select Filters > Parameters.
2. Ensure that Enable Log, Quick-Click Refinement and Auto Policy Generation are selected. If not,
select these fields and click Submit and Save and Apply .
3. In the Security Policies view, select Filters > Parameters.
4. In the right pane, complete the fields using the table below.
Table 44: ByPass Flag parameters
Field Description
Force additional When selected, any parameter that evaluates as valid will not be evaluated by
security subsequent Security Filters unless the parameter specifically overrides the
validation by Bypass Flag.
Parameters When not selected, parameters will be evaluated, if required, by subsequent
Filter Security Filters.
Operating Mode Select one of the following:
Targeted Validation—Only specified parameters are evaluated. An event is
generated if the evaluated parameter is invalid.
Restricted Parameters With Validation—Only specified parameters are
evaluated. An event is generated when:
• An evaluated parameter is invalid.
• A request contains any parameter that is not defined.
Setting Query Parameters

This procedure allows you to set rules for evaluating requests to a specific page (for example,
start.cgi) or multiple pages.
To set query parameters

3. In the right pane, click the Page tab.
4. Click the (Add) button to add a new parameter, or select an existing entry and click

5. Complete the Manage Parameters - Query Parameters dialog box using the table below.
6. In the Parameters List area, click the (Add) button to add a new parameter definition for
the page, or select an existing definition and click the (Edit) button to modify it.
7. To include the order of parameters in the evaluation, select parameters as required and use the
arrow buttons to arrange the required order. Then select the Enforce Parameter Order checkbox.

Security Tools
8. To prevent the page and all its parameters from being modified by Auto Policy Generation, click
the Lock checkbox. A padlock icon is inserted next to the parameters.
9. Click OK.
10. On the AppWall Management Application Console toolbar, click Apply .
Table 45: Query Parameter options
Field Description
Apply to Other When selected, the Security Filter evaluates requests made to all pages in the
Pages Application Path that are not defined by another Page parameter. When not
selected, the Security Filter will be used only for requests made to the specified
page.
asterisk character followed by the period and extension, for example: *.xxx The
entry must begin with a forward slash (“/”) and end with either an extension or a
forward slash.
Parameters List See Setting Path and Cookie Parameters.
Enforce When selected, an event is generated if the order of parameters in the request
Parameter Order does not match the order of parameters in the Parameter List.
Lock Select to prevent Auto Policy Generation from modifying the selected
parameters.
Setting Path and Cookie Parameters

Use this procedure to set the Path and Cookie parameters.
To set path and cookie parameters

3. In the right pane, click the Path tab to set path parameters or the Cookie tab to set cookie
parameters.
4. To add a parameter, click the (Add) button, or select an existing parameter and click

5. Use the displayed values in the top 4 fields or modify as required. For field descriptions, see
Setting Query Parameters.
6. In the Parameters List area, click the (Add) button, or select an existing parameter
definition and click the (Edit) button to modify it.

7. On the dialog box that displays, complete the fields on the Name and Value tabs and click OK.

Security Tools
Table 46: Name Tab
Field Description
Name Enter the parameter name or use the browse button to select from a list of
regular expressions.
Use Regular Select this check box if the parameter uses regular expressions.
Expression To test the validity of a regular expression, click Check and supply the required
information.
Table 47: Value Tab
Field Description
Enable Value When selected, the Security Filter evaluates both the parameter name and value.
Validation When not selected, it evaluates only the parameter name. Clearing this check
box grays out the remaining fields.
Value Type Select the parameter value type from the drop-down list.
Minimum Length For Long, Numeric, and Float types, enter the lower bound of the value range.
For String, Alpha, and AlphaNum types, enter the minimum string length.
Maximum For Long, Numeric, and Float types, enter the upper bound of the value range.
Length For String, Alpha, and AlphaNum types, enter the maximum string length.
Value (Appears when value type selected is Expression.) Specify the expression value.
Expression
Allow a Null Select to allow the value to be null.
Value
Always Check When selected, the parameter is evaluated even if assigned a Bypass Flag.
Required in the When selected, an event is generated if the parameter is not included in a
Request request.
Message
Use with Other Security Filters

The Parameters Security Filter should be used in conjunction with the Vulnerabilities Security Filter.
When using the Parameters Security Filter to evaluate Web Services, XML, or HTTP path parameters,
the Session, WebServices, and XMLSecurity Security Filters must be enabled and sequenced prior to
the Parameters Security Filters.
PathBlocking Security Filter

The PathBlocking Security Filter can be used to generate events for remote access requests for files
and Application Paths (and sub-directories).
Using PathBlocking in conjunction with the AllowList Security Filter allows you to specify all pages of
one type, but block individual files or subfolders.
Default Status
By default, the PathBlocking Security Filter is disabled and no paths are specified. When enabled,
the Security Filter configuration must specify path information before generating any events.
Note:

Security Tools
Consider the PathBlocking Security Filter is enabled and configured with the following list of paths.
/mysite/orders/
/mysite/clients/special/Admin.htm
When a request accesses any file under the orders directory, the request generates an event
because the directory has been defined as blocked.
When a request accesses Admin.htm under the special directory, the request generates an event.
However, no event is generated by requests accessing any other file or folder under the /clients/
directory.
Configuring the PathBlocking Security Filter

Use this procedure to configure the PathBlocking security filter.
To configure the PathBlocking Security Filter

1. In the Configuration view, select Filters > PathBlocking.
Apply .
3. In the Security Policies view, select Filters > PathBlocking.
4. Click the (Add) button to add a path, or select an existing entry and click the (Edit)
button to modify it
5. Complete the fields using the table below.
Note: When specifying blocked paths for applications that use path parameters. Do not include
the path parameters in the specifications and verify that Analyze Path Parameters is enabled in
the tunnel configuration.

Table 48: PathBlocking Security Filter options
Field Description
Path Specify a path. Requests made to this path will generate events. To restrict
Security Filter evaluation to a specific file, append the file name to the path.
Example: /mypath/mypage.htm
Note: To counter a vulnerability, the Automatic Configuration module has Application Paths where
the PathBlocking Security Filter is enabled. Thus the Auto Policy Generation module prevents
“Predictable Resource Location” Attacks on the protected application.

Security Tools
Session Security Filter

The Session Security Filter is aimed at preventing remote users from manipulating Session state
information and submitting it to the Web Application.
An HTTP session is the sequence of service requests made by a single user using a single client to
access a Web server. The information maintained in the session across requests is called Session
State. Session State may include both information visible to the user (shopping cart contents, for
example) and invisible application control information (such as user preferences).
HTTP is a stateless protocol, which does not have built-in support for Session State information
management as part of the communication protocol.
Client HTTP Session State is important for many Web Applications that perform different operations
that depend on current Session State. One example might be blocking users from accessing data
they are unauthorized to access.
As a result, an application that wants to keep Session State must use one of the following optional
workarounds:
• Stateful servers – The server keeps all Session State information.
• Stateless server – the client keeps the Session State. The Session State is sent to the client and
resent to the server in following requests.
There are four basic conceptual methods for sending the Session State to the client:
• In a cookie
• Form parameters
• In path parameters
• In query parameters.
When using one of methods above for session management, the end-users are trusted to return the
Session State information, unchanged, to the Web Application in future requests. Therefore, it is
extremely important to make sure that such Session State information is not returned to the Web
Application if it has been manipulated, or hijacked by a malicious user.
Caution: By default, cookies are protected by the Session Security Filter; however, URLs and
Parameters are not and must be configured.
Cookie Manipulation Protection

The Session Security Filter prevents remote users from modifying a cookie’s value as originally set
by the application. This, with the optional binding of the cookie to the client IP, helps counter
attempts such as cookie poisoning, cookie hijacking, and cross-site scripting.
The Session Security Filter inspects the HTTP cookies in a request, comparing the cookie’s value with
the value specified when the cookie was encrypted and set. The HTTP cookie in the reply message is
processed by AppWall and encrypted. When the cookie is returned it is decrypted and verified by the
Session Security Filter. If the cookie was tampered with, or received from the wrong client, the
decrypting will immediately reveal this and invalidate the cookie.
Parameter Manipulation Protection (Form, Path, and Query)
Note: As of Alteon version 31.0.1 a separate feature license is required for Parameter Manipulation
Protections in Forms and URLs.
The Session Security Filter prevents remote users from submitting modified parameter values stored
in HTML Forms by the application.

Security Tools
Imagine a malicious user views the source of an order form and starts changing hidden and read-
only values such as price and quantity. If successful, the malicious user receives a shipment of 100
books for the price of one.
The Session Security Filter provides a way to detect when this type of manipulation occurs. It safely
encrypts the original values so that simple editing of parameter values (hidden, read-only and
multiselect values) is detected before the request (form post) reaches its destination.
Encryption of the values that are received from the original reply is checked against the values
submitted in the action request. A request made by the user from the original page (form) is
protected from modification of the hidden and read-only parameter values as well as multiselect
elements (for example, drop-down lists, radio buttons). If the protected parameters have changed
the Session Security Filter will deny the Action-request and a security page will be returned instead.
Configuring the Session Security Filter

Configuring the Sessions Security Filter involves the following:
• Configuration of Global Settings.
• Configuration of refinements at the Cookie, URL, and Parameter levels.
Session Security Filter Global Settings

Use this procedure to configure the session security filter global settings.
To configure the Session Security Filter

1. In the Configuration view, select Filters > Session.
Apply .
3. In the Security Policies view, select Filters > Session.
4. Select the Settings tab.
5. Use the table below to complete the fields in this tab and click OK.
Table 49: Global Cookies Settings
Deny Requests This setting blocks the HTTP Request and sends a security page if the cookie is
with Untrusted deemed invalid. When disabled and the cookie is deemed invalid, the Security
Cookies Filter removes the Cookie Header and passes the HTTP request.
Verify Cookie When enabled, the cookie is checked to assure that it is being used by the client
Ownership IP that it was issued to. If it is not, the cookie will be considered invalid.
(Client IP
Binding)
Default Mode: Selecting this mode automatically encrypts all cookies in undefined/disabled
Allow Cookies Application Paths.
Auto Protection
– All Cookies are
Encrypted

Security Tools
Table 50: Global Cookies Settings - HTTP Reply Body
Do not parse When the flag is set, the filter will encrypt protected links even if they appear in
HTTP Replies Application paths that do not have the session filter activated. For example, in
across Application path \Sale\ , all parameters to sale.aspx are requested to be
Application protected. Links to: /Sale/sale.aspx will be protected even if they exist in any
Paths other folder. When enabling this option, there will be performance impact as ALL
text/html responses need to be parsed.
Cookies Secured Values: Sign or Encrypt
Mode Sign: AppWall adds a signature of the original cookie value as sent by the web
server. Cookie value is not hidden, but the value cannot be modified on the client
end. When it is required to secure the cookie and the client side applications
process the cookie value as part of their legitimate functionality, “Sign” mode is
the only option.
Encrypt: AppWall encrypts the original cookie value as sent by the web server.
Cookie value is hidden, and the value cannot be modified on the client end.
If the client side applications does not read the cookie value as part of their
legitimate functionality, you can use this stronger protection mode.
Prefix The prefix of the parameters can be edited to avoid exposure of AppWall devices
in case of an external security page defined using FQDN.
Parameters Values: Sign or Encrypt
Secured Mode Sign: AppWall adds a signature of the original parameter value as sent by the
web server. Parameter value is not hidden, but the value cannot be modified on
the client end. When it is required to secure the parameter and the client side
applications process the parameter value as part of their legitimate functionality,
“Sign” mode is the only option.
Encrypt: AppWall encrypts the original parameter value as sent by the web
server. Parameter value is hidden, and the value cannot be modified on the client
end.
If the client side applications does not read the parameter value as part of their
legitimate functionality, you can use this stronger protection mode.
Session Security Filter Refinements

The Refinement tab of the Session Security Filter allows protection and validation for Cookies, URLs,
and Parameters. The Refinements tab is divided into additional tabs for Cookies, URLs, and
Parameters. Each tab allows configuration of refinement rules by protecting list entries or protecting
anything except for list entries, as explained below.
Quick-click refinements are available for this Security Filter. When an icon displays in the Tips
column of the table, you can right-click the icon and select Accept to accept the refinement.
To configure the Session Security Filter Global refinements

1. In the Security Policies view, select Filters > Session.
2. In the right pane, click the Refinements tab, and select the tab for Cookies, URLs, or
Parameters.
3. Fill in the required information according to each Tab definition, described below.

Security Tools
4. Click the (Add) button to add a new refinement, or select an existing entry and click

5. Complete the fields and click OK.
6. Click Submit and Save and on the AppWall Management Application Console toolbar, click
Apply .
Cookies Tab
The list of Cookie refinements provides the user with the ability to add, edit, and delete Cookie
refinements at the Application Path level and at a Global level.
In the event of a refinement added by a user that contradicts an existing refinement a message will
be displayed providing the following information:
• When adding a Host refinement—The Validation and Encryption mode of the host is different
to that of at least one Application Path refinement. This will cause the host configuration to be
overridden by the Application Path configuration.
• When adding an Application Path refinement—The Validation and Encryption mode of the
Application Path is different to that of the host refinement. This will cause the host configuration
to be overridden by the Application Path configuration.
Furthermore, when the dialog above displays the Application Level refinement, any global cookies
defined for the host display (disabled). Host cookie definition will only be added to the Application
Path if the Validation and Encryption mode are the same.
Table 51: Session Security Cookies Parameters
Field Description
Activate Cookies Select the checkbox to activate Cookies Configuration according to the settings
Configuration below.
Work in Default Select this box to operate in the default mode (all Cookies are automatically
Mode encrypted).
Table 52: Session Security Cookies Parameters - Refinement Levels
Field Description
Application Path The Refinements apply to the cookies in the requests handled by the Application
Path specified.
Host The refinements apply to cookies for requests on any of the Application Paths
under the specified host that have the Session Security Filter enabled.
Table 53: Session Security Cookies Parameters - Protected Cookies
Field Description
All Listed By enabling the Session Security Filter in All Listed Cookies operational mode,
Cookies you secure only the cookies named in the Cookies list for the Application Path, or
all Application Paths at the host level.
All Except for By enabling the Session Security Filter in All Except for Listed Cookies
Listed Cookies operational mode, you secure all cookies that have not been named in the
Cookies list for the Application Path, or all Application Paths at the host level.
Reported on Web Application containing the host.

Security Tools
Table 53: Session Security Cookies Parameters - Protected Cookies (cont.)
Field Description
Host Host containing the Application Paths where the Security Filter should be applied.
Application Path Application Path where the Security Filter should be applied.
Expression Icon indicates whether the Cookie Name is a regular expression. To test the
validity of a regular expression, click Check and supply the required information.
Name Displays the name of the Cookie.
Mode Displays the mode defined.
URLs Tab
The list of URL refinements provides the user with the ability to add, edit, and delete URL
refinements at the Application Path and Global level.
Table 54: Session Security URL Parameters
Field Description
Activate URLs Select this option to activate the URLs configuration according to the settings
Configuration below. Upon activation URLs in the list (or all but those in the list) will be
protected.
Work in Default Select this box to operate in the default mode (all URLs are unprotected).
Mode
Table 55: Session Security URL Parameters - Protected URLs
Field Description
All Listed URLs By enabling the Session Security Filter in All Listed URLs operational mode, you
apply protection only to the URLs named in the list of URLs for the Application
Path, or all Application Paths at the host level.
All Except for By enabling the Session Security Filter in All Except for Listed URLs operational
Listed URLs mode, you apply protection to all URLs that have not been named in the URLs list
for the Application Path, or all Application Paths at the host level.
Expression Icon indicates whether the URL Name is a regular expression. To test the validity
of a regular expression, click Check and supply the required information.
Name Displays the name of the URL.
Parameters Tab
The list of Parameter refinements provides the user with the ability to add, edit, and delete
Parameter refinements at the Application Path level and at a Global level.

Security Tools
Table 56: Session Securities Parameters Tab
Field Description
Activate Select this option to activate the Parameters configuration according to the
Parameters settings below. Upon activation Parameters in the list (or all but those in the list)
Configuration will be protected.
Work in Default Select this option to operate in the default mode (all Parameters are protected).
Mode
Table 57: Session Securities Parameters Tab - Protected Parameters
Field Description
All Listed By enabling the Session Security Filter in All Listed Parameters operational mode,
Parameters you apply protection only to the Parameters named in the list of Parameters for
the Application Path, or all Application Paths at the Global level.
All Except for By enabling the Session Security Filter in Protect All Except for Listed Parameters
Listed operational mode, you apply protection to all Parameters that have not been
Parameters named in the Parameters list for the Application Path, or all Application Paths at
the Global level.
Expression Icon indicates whether the URL Name is a regular expression. To test the validity
of a regular expression, click Check and supply the required information.
Name Displays the name of the Parameter.
To configure Session Security Filter Application Path refinements

1. In the Management Application Policies view, select Filters > Session Security Filter.
2. In the right pane, click the Refinements tab, and select the tab for Cookies, URLs, or
Parameters.
3. Fill in the required information according to each Tab definition, described above.
4. Click the (Add) button to add an Application Path refinement, or select an existing entry
and click the (Edit) button to add additional refinements to the Application Path.
5. Complete the fields and click OK.
6. Click Submit and Save and, on the AppWall Management Application Console toolbar, click
Apply .
Session Security Filter Auto Policy Generation

The session security filter offers a unique support for per-cookie protection mode. As a first step,
when a cookie name or value matches a keyword criteria, AppWall will identify the cookie as
sensitive an will consider securing it. By default, only “session-cookie” will be secured. If persistent
cookies also required to be secured, you should add them manually to the list of secured cookies.

Security Tools
Once sensitive cookies are identified, AppWall will remove the cookies which are modified on the
client side from the list, as these cookies cannot be secured for modification. The modified cookies
will be switched to disabled mode. The non-modified cookies will then be switched from passive to
active mode and will be actively secured.
Vulnerabilities Security Filter

The Vulnerabilities Security Filter checks incoming requests for known vulnerability patterns and
combinations. It generates an event when a request contains defined patterns and parameter
expressions. The Security Filter performs a number of validations on the URL, Header, Body, and
parameters of a request using an extensive library of patterns as well as any configured custom
patterns. By refining the Security Filter, you may specify patterns and parameter combinations that
present vulnerabilities in custom-made applications.
Default Status
The Vulnerabilities Security Filter is enabled by default.
An HTTP Request is processed through a special algorithm that finds patterns and parameter
expressions in a Request. If an HTTP Request matches the listed parameter and parameter
definitions for that pattern, an event is generated. An event is not generated if the request matches
the pattern but not the parameter definitions.
• To screen requests for documents using temp files, such as a “~WRL0551.tmp” file, create a
custom pattern “~WRL” for the URL detection. Any URL request for a file-name containing this
pattern will generate an event.
• To screen for requests that post an executable prettypark.com file, use “prettypark” as a custom
pattern for Body detection. Any request containing that pattern will generate an event,
including, for example, prettypark.exe or prettypark.bat.
• To screen for a request to view the source code of a page using a Header “Translate: f”, no
pattern is necessary, because this pattern is already defined in the default patterns. The request
will generate an event.
• To screen for a request, such as GET /Accounts.asp?user=Temp&password=Temp&mode=2
HTTP/1.1,create a custom pattern “.asp” and “mode=2&User=Temp&password=Temp”. This
parameter combination with any ASP page request generates an event.
Note: All criteria must be met for the request to generate an event. Parameter order is not
important; patterns/values are not case sensitive.
Configuring the Vulnerabilities Security Filter

This procedure allows you to create custom vulnerability patterns with or without illegal parameter
expressions. In addition, you can use Pattern ID codes from the Security Log to disable internal
Vulnerability patterns.
To configure the Vulnerabilities Security Filter

1. In the Configuration view, select Filters > Vulnerabilities.
2. In the left pane, select the Settings tab.
3. Ensure that Enable Log and Quick-Click Refinement are selected. If not, select these fields
and click Submit and Save and Apply .

Security Tools
4. Click the (Add) button to add a new pattern, or select an existing entry and click

Table 58: Vulnerability Security Filter Dialog Box Settings
Field Description
Scanning Zones The area of an HTTP request message to search. These areas are searched for
the specified pattern if the associated Scanning Zone is enabled in the Security
Filter’s Scanning Zone settings. If a zone is disabled, no patterns are searched
for in that scanning zone.
Active Patterns To add a pattern, right-click in the field and click Add, or select an existing
pattern and click Edit or Delete. Clicking Add or Edit opens a dialog box.
Expected Select the expected location of the pattern.
Location
Pattern Select or enter a pattern to look for or enter a new one.
Parameters Note: All requests are converted to UTF8 before reaching the Security Filters,
therefore the pattern should be the UTF8 equivalent represented in the
simplest ASCII characters. Specify the parameter/value for which to look.
Patterns can be defined by the combination of both Pattern and Parameters. If
parameters are defined, the pattern generates an event when those
parameters appear in the request and match the defined values.
Examples: Parameter Value only: %20& Multiple Parameter Value only: %20&
Parameter assignment syntax: a=1 Parameter Name: UserID
Description A description of the pattern.
Custom Patterns
Use this procedure to configure custom patterns for the vulnerabilities security filter.
To configure the Vulnerabilities Security Filter

2. In the left pane, select the Settings tab.
3. Click the (Add) button to add a new pattern, or select an existing entry and click

4. Ensure that Enable Log and Quick-Click Refinement are selected. If not, select these fields
and click Submit and Save and Apply .
6. In the Custom Patterns - Active patterns Panel click the (Add) button. An Add a Custom
Pattern dialog box opens.
7. Mark the expected location checkboxes as required.
8. Enter a pattern from the drop-down list that includes the following:

Security Tools
.bkup, .old, .bac, .backup, .~01, .~00, .000, /../, .orig, .temp
Note: The Patterns are not case sensitive and should be represented in the simplest ASCII
characters. For example, a specification of a custom pattern “image” would generate an
excessive number of events, as follows.
Table 59: Custom Patterns
Description Example
Any request to or /Images/spot.gif (in the HTTP Body code and in the URIs)
containing a URL with
the pattern “image”
Any request with file “help_image.jpg” (in the HTTP Body code)
containing the word
“image”
Any file containing text “Refer to the following image…”(in the HTTP Body text)
with the pattern “image”
Any request with a Host: NewImage (in the HTTP Header)
header containing the
pattern “image”
Any request with a function ShowImage (in the HTTP Body code)
function containing the
pattern “image”
Any request with a <META NAME="keywords" CONTENT="Images, Photos, (in the HTTP
partial word containing Body code)
the pattern “image”
Disabling Default Pattern IDs

This functionality is for special cases where there is a need to override the default Vulnerability
Patterns. You can disable default patterns used in the Vulnerabilities Security Filter only after you
have acquired the ID code.
To disable the default pattern IDs:

1. In the Security Policies view, select the Vulnerabilities Security Filter.
2. Right-click the Refinements tab and click Add.
3. On the Add an ID dialog box, enter the ID of the pattern you want to disable and click OK.
Notes
• By disabling patterns, you exclude the specific validation associated with the pattern for an
Application Path or for all Application Paths, Hosts, Tunnels, and Web Applications of the server
that have the Vulnerabilities Security Filter enabled.
• You can find the pattern ID number by viewing the description of the Security Log event
generated by the Security Filter.

Security Tools
• For security reasons, Vulnerabilities security codes are not listed in the documentation.
Therefore, it is recommended that you keep a description of the pattern for future reference.
• You can use the right-click > Copy commands in the Description text area of the Event Log
Properties dialog box to copy and paste this into a text document, which you can save for future
reference.
• When patterns are disabled, you lower the monitoring level of Application-layer attacks. Exercise
great care when disabling Pattern IDs.
Refinement List
This procedure allows you to refine vulnerability patterns with or without illegal parameter
expressions.
To configure the Vulnerabilities Refinements

2. In the right pane, select the Refinements tab. The Vulnerabilities Security Filter Refinement List
pane appears.
3. To add an ID, click the (Add) button. The Add an ID dialog box appears.
4. Mark the checkbox if you want this to apply to all application paths.
5. If you wish to specify an ID that you are adding, do not mark the checkbox. The Add an ID
dialog box appears.
6. Once you have finished, click Add to add this ID.
Web Application
A Web Application is a logical container object that contains and links Tunnels, Hosts, and Application
Paths. This section describes how to work with Web Applications in AppWall Management
Application.
Logical Model
AppWall Management Application uses a logical model of the application environment to apply finely-
tuned security policies.
Table 60: Managing Web Applications
Object Description
Web Application A logical container object that contains and links Tunnels, Hosts, and
Application Paths.
Tunnel Specifies the Web server IP/port and contains one or more host
assignments, including <Any Host>.
Host Serves as a container for one or more Application Paths. When using
virtual hosting, create a host object for each virtual host on the Web
server. When not using virtual hosting, use the <Any Host> object.
Application Path Specifies path parameters and contains one or more Security Filters.

Security Tools
Figure 26: Object Model
This object model allows for great flexibility when tailoring security policies to the particular needs of
the application environment. As the example below shows, the Web Application object can be
configured to include Application Paths from various tunnels.
Figure 27: Web Application object
Other sections of this User Guide provide instructions for defining your Web Application environment
settings in AppWall Management Application, managing the security policies used during monitoring
and protection, and maintaining other components and services needed to run the monitoring and
protection processes.
Logical Objects
A Web Application is a logical object, as shown in the previous section, used to link Tunnels, Hosts,
and Application Paths. Each Application Path can have its own set of Security Filters. The object
hierarchy is described below.

Security Tools
Table 61: Object Hierarchy
Object Description
Tunnel Specifies the Web server IP/port and contains one or more host
assignments, including <Any Host>.
Host Serves as a container for one or more Application Paths. When using
virtual hosting, create a host object for each virtual host on the Web
server. When not using virtual hosting, use the <Any Host> object.
Application Path Specifies path parameters and contains one or more Security Filters.
Enabling/Disabling a Web Application

When a Web Application is enabled, its Application Paths are monitored and protected using the
Security Filters configured for its Application Path objects. When disabled, monitoring and protection
are suspended.
Note: Disabling a Web Application does not necessarily suspend monitoring and protection of its
Application Paths.
To enable/disable a Web Application

1. In the Security Policies view, select the Web Application in the tree, and click the Settings tab.
2. Select or clear the Enable Web Application checkbox to enable or disable the Web Application,
respectively.
3. Click Submit and Save in the Content area.
4. Click Apply on the toolbar.
Adding Hosts, and Application Paths

You can configure a Web Application’s child objects by right-clicking the an object in the hierarchy
and select Add, Edit, or Remove.
Table 62: Tunnel, Host, and Application Path Parameters
Available Hosts Select an existing host from the drop-down list or click Add a New Host to
create one.
Security Page The relative path to the security page, which is the page returned to a client
for an invalid (blocked) request.
Application Path List Click Add to configure the Application Path
Application Path Specify the Application Path.
Force to Successive Check to pass requests through all enabled Security Filters so that each
Security Filter request is checked by the next Security Filter whether or not the preceding
Validations Security Filter resulted in the generation of an event
Use Regular Enable this setting if the entry in the Application Path field is a regular
Expression expression.

Security Tools
Notes
• To add a host to a specific tunnel, the host must be created using the Configuration view.
• If you use virtual hosts, you are not required to use <Any Host>.
Hosts
Each host added to the tunnel (in Configuration view, select Tunnel > Host Name) can have its
own properties and security policy. If no hosts are configured under the tunnel, you can use “Any
Host.”
The settings configured from the hosts include:
• Security Page (configured per host)
• SSO and Login Monitoring (set under the host)
• Adding Web roles and setting their properties
Note: Authentication Gateway and SSO settings are visible and functional only when an
Authentication Capacity license is available on the device.
Authentication Gateway, Single Sign-on and Login Monitoring

AppWall includes an authentication gateway providing single sign-on, user tracking, and
authentication enforcement for your secured Web application.
Note: Redirection to the login page is enforced when a “public” (non-authenticated) user attempts
to access a resource prohibited for public users. The AllowList and Path Blocking security filters
enforce Web access policy for the public role. On the other hand, if the user who is attempting to
access the resource has already performed a successful login but is not allowed to access the page
according to his role policy, he is redirected to the security page.
If you enable User Tracking and Authentication under the host, when a user logs into the secured
application, the user session is tracked using an HTTP session cookie. As a result, any security event
generated for any of the user transactions on any of the TCP connections established from the user’s
browser to the application includes the username.
Single Sign-On: Internal Login process vs. SAML based SSO

AppWall supports two approaches for single sign-on implementation. It offers an internal SSO
service where it hosts a login page and validates user credential against a user data store.
Alternatively, it works with an external SAML IdP (Identity Provider) who authenticates the user and
issues SAML assertions which are redirected back to AppWall for Web Access control and
Authorization policy enforcement.

Security Tools
Single Sign-On: SSO Server and Clients

AppWall provides Single Sign-On (SSO) services for multiple applications. For that purpose, a single
SSO server is defined. An SSO client is a customer application that uses the SSO services provided
by AppWall. Once the SSO server is configured, you can define multiple SSO clients which, together
with the SSO server, establish an SSO community. Identities within the SSO community are shared
so the same credentials are used to access multiple applications within the SSO community. AppWall
supports credential caching and resubmit credentials tools to offer a single login process for multiple
applications defined in the same SSO community. If the user is not yet authenticated, AppWall
redirects the user to the SSO server login page.
To configure an SSO server
1. From the Internal SSO tab, click to add a new internal SSO server.
2. Select the tunnel and the host that AppWall will use for the SSO Server.
3. Select if a two-factor authentication scheme is to be used.
4. Select the authentication server to validate the credentials.
Selecting None results in credential caching only, without validation.
5. In the Login/logout section, click Uploaded Directories to manage the relevant login pages.
6. Click to upload a new directory for the login pages.

7. Select the login directory.
The login directory should contain the login page with its relevant components. Additionally, a
2nd factor login page, a Web top page, and a failed login page can be included.
8. Select the login page.
9. If a two-factor authentication scheme is enabled, select the 2nd factor page.
10. Select the action to perform after successful login.
Usually this is Original URI to redirect back to the originally requested page, or it can be
Custom URI or a WebTop URI which is in the login directory.
11. Select the page to redirect to after a failed login attempt.
12. In the AppWall Session Management pane, configure a cookie name AppWall to be used for
managing the authentication sessions.
13. Select whether AppWall uses a session cookie or a persistent cookie.
If a session cookie is selected, the SSO session is maintained until the user closes the browser or
until an idle session timeout expires. If a persistent session is used the SSO session is kept for a
predefined time.
Notes
• The SSO server is a virtual host that AppWall is listening on in a specific tunnel. This host cannot
be used under the same tunnel for other purposes.
• The login page needs to contain a single HTML form with the action pointing to the same page
name, an input field Username, and an input field Password.
• The 2nd factor page needs to contain a single HTML form with the action pointing to the same
page name, and an input field Password.

Security Tools
• The 2nd factor page allows three attempts for entering the correct token. After each failed
attempt, AppWall returns the 2nd factor page with the Attempt Number parameter in the URL.
After the third failed attempt, AppWall redirects according to the Redirect After Failed Login
setting.
• When uploading a forlder, its name must not have spaces.
• See Radware's knowledgebase for more information and a sample login directory.
Configuring SSO Clients

In an SSO community, AppWall redirects un-authenticated users to the SSO server, and after
successful authentication AppWall redirects the users back to the requested Web application and
automatically performs authentication. AppWall supports the followingauthentication mechanisms
for the protected Web application:
• Form-Based Authentication—AppWall identifies the login form in the Web application and
submits the user credentials in it.
• NTLM—AppWall performs an NTLM negotiation to authenticate the user to the Web application.
• Kerberos—AppWall uses Kerberos Constrained Delegation to authenticate the user to the Web
application.
To configure a form-based SSO client

1. In the SSO tab, enable the SSO mechanism.
2. Select the SSO server to use.
3. For Backend Authentication Type, select Form-Based Authentication.
4. Complete the configuration of the Login Properties section as described in the following table:
Table 63: Login Properties
URI Enter the URI of the page containing the login form.
Login Form Name The name of the HTML form used for the login.
Action URI The URI to send the login request.
Username Field The name of the HTML input field used for the username.
Password Field The name of the HTML input field used for the password.
5. Complete the configuration of the Successful Login Detection section as described in the
following table:
Table 64: Successful Login Detection
Mode Choose the detection mode:
• Bad Reply mode assumes successful authentication unless the provided
patterns are matched.
• Good Reply assumes unsuccessful authentication unless the provided
Response Body Pattern A string pattern to match in the response body.
Response Status Code An HTTP status code to match in the response.

Security Tools
Table 64: Successful Login Detection (cont.)
Response Header Name An HTTP header to match in the response.
Response Header value The value inside the HTTP header.
To configure an NTLM-based SSO client

3. For Backend Authentication Type, select NTLM.
To configure a Kerberos-based SSO client

3. For Backend Authentication Type, select Kerberos.
4. Enter the SPN of the Web application that will consume the Kerberos ticket.
Note: AppWall uses the username provided in the domain controller settings of the SSO server
as the impersonator user with the key distribution center (KDC) for performing Kerberos
Constrained Delegation (KCD). This user must have the required permission in the domain
controller to perform KCD.
To configure Failed Login and Logout Handling

> In the SSO tab, complete the Failed Login and Logout Handling section as described in the
following table:
Table 65: Failed Login and Logout Handling Properties
Logout URI Enter a URI used to identify logout from the Web application for SSO
community logout purposes.
This field is optional.
Configuring the HTTP Header

After successful authentication, AppWall can add information about the user in HTTP headers or
cookies sent to the Web application.
• In the Client Authentication Headers section, you can add headers that contain the
username or user role.
• In the HTTP Headers Modification section, you can add, remove, or modify other HTTP
headers or cookies for specific URIs.

Security Tools
SAML
SAML (Security Assertion Markup Language) is is an XML-based data format used for Web single
sign-on (SSO). SAML is exchanging digitally signed authentication and authorization data between
the Identity Provider (IdP) and the Service Provider (SP). In the context of the discussed solution,
the IdP is functioning as the front-end user authentication authority while the SP is the authorization
(Web access management) and back-end authentication authority.
The authentication flow using SAML with Alteon Authentication Gateway is as follows:
1. The client tries to access a Service Provider (e.g. SharePoint) via the Alteon VIP address.
2. Alteon generates a SAML authentication request (authnrequest).
3. The user is redirected to the external Identity Providerâ€™s (IdP) SSO URL (e.g. ADFS).
4. The client receives a login page from the IdP server.
5. The user authenticates to the IdP.
6. The IdP generates a SAML authentication response (authnresponse).
7. The IdP returns an encoded SAML response (containing JS postback script) to the client browser.
8. The client browser executes the postback and sends a POST request to the SP.
9. The SP validates the SAML response and grants access to the application (SharePoint).
External SAML IdP

SAML is a format for exchanging authentication and authorization data between an identity provider
and service providers. The IdP is an Authentication Authority while the SP is expected to enforce the
Authorization policy through Web Access Management.
AppWall supports integration with external SAML IdP (e.g. Shibboleth, ADFS 3.0, Goole IdP).
To configure an external SAML IdP

1. From the External SAML IdP tab, click the plus sign to add a new SAM IdP.
2. Provide a SAML IdP ID.
3. Provide the username attribute in the SAML assertion as provided by the IdP.
4. Import the SAML IdP xml meta file or to AppWall.
5. From the Web Roles navigation tree node, click the plus sign to add a new role.
6. Provide the Role Name, select the Role Type to be SAML, and define the attribute name and
value.
7. From the Authentication tab under the Web Application host level enable Authentication.
8. For the Authentication Type select External SAML IdP.
9. For the Back-end Authentication type select either Kerberos or None. If you select
Kerberos, you are required to provide Kerberos server details. NTLM is not an option in this
scenario.
10. Configure the External SAML IdP Provide the Authentication Cookie Name, and click
Generate.
11. Click Download Metadata File and import it into your IdP server.
12. From the Host level in the navigation tree view, right click the host and select Add Role.
13. From the Application Path of the Public role click the select AllowList Only Predefined Policy.
14. From the newly added role, define your desired security.

Security Tools
Login Monitoring
If you enable Login Monitoring under the host, when a user logs into the secured application, the
user session is tracked using an HTTP session cookie. As a result, any security event generated for
any of the user transactions on any of the TCP connections established from the user's browser to
the application includes the username.
To set login monitoring

1. In the Login Monitoring tab, enable the Login Monitoring mechanism.
Table 66: Login Properties
URI Enter the URI of the page containing the login form.
Login Form Name The name of the HTML form used for the login.
Action URI The URI to send the login request.
Username Field The name of the HTML input field used for the username.
Password Field The name of the HTML input field used for the password.
2. Complete the configuration of the Successful Login Detection section as described in the
following table:
Table 67: Successful Login Detection
Mode Choose detection mode:
• Bad Reply mode assumes successful authentication unless the provided
• Good Reply assumes unsuccessful authentication unless the provided
Response Body Pattern A string pattern to match in the response body.
Response Status Code An HTTP status code to match in the response.
Response Header Name An HTTP header to match in the response.
Response Header value The value inside the HTTP header.
3. Optionally, in the Failed Login and Logout Handling section, set the Logout URI.
If the logout URI is requested, AppWall removes the HTTP session cookie used to track the user.
4. Optionally, in the HTTP Session Tracking section, configure the relevant cookie name for
correct user tracking in case of an unsuccessful login.
5. Optionally, in the Client Authentication Headers section, configure headers sent to the Web
application containing the username or role.
6. Optionally, in the HTTP Header Modifications section, configure headers or cookies to be
added, removed, or modified on specific URIs
7. In the AppWall Session Management pane, you can configure the cookie name AppWall will use
for monitoring the authentication sessions.
8. Select whether AppWall uses a session cookie or a persistent cookie.
If a session cookie is selected, the session is kept until the user closes the browser or until an
idle session timeout expires. If a persistent session is used, the session is kept for a predefined
time.

Security Tools
If User Tracking is enabled under the host, and two or more Web roles are defined for the Web
application, User Tracking is implemented through LDAP or RADIUS authentication mode rather than
just extracting the username from the field.
After you configure an LDAP or RADIUS server, you can enable the authentication option for that
host.
Web User Roles

Having configured your authentication server, you are now ready to define a web user role.
To configure a web user role

1. In the Configuration view, open Management and select Web User Roles.
2. In the Add Role dialog box, specify the parameters using the table below.
3. Click OK.
Table 68: Web User Role options
Field Description
Name Name of the role
Type Set the authentication type.
Values:
• LDAP
• LDAP for Digest
• RADIUS
• Authenticated (Auto-Detection)
Authentication The authentication server configured for the authentication type you selected
Server displays.
Members Add members associated with this Web role.
Authentication Gateway Implementations

• Implementation of an RSA SecurID Server for Authentication, page 146
• Implementation of an Azure Authentication Server, page 147
Implementation of an RSA SecurID Server for Authentication

RSA SecurID Access is the world's most widely-deployed multi-factor authentication solution. In
addition to the already existing integrations of Alteon Authentication Gateway with first and second
factor authentication systems (LDAP, Active Directory, Radius, and SMS Passcode), Alteon 31.0.2
Authentication Gateway integrates with RSA SecurID Access for OTP services using RSA SecurID
hardware and software token.

Security Tools
To configure the Authentication Gateway to authenticate web users from an RSA

SecurID server
1. Create a Radius Server in Alteon; select Configuration > Security > Authentication server
> Radius.
2. In the RSA SecurID Access software, add an RSA client which is the authentication gateway (the
previous Radius Authentication server in Alteon)
3. Create your Secure Web Application in Alteon, select Configuration > Security > Web
Security > Secure Web Applications.
4. In the AppWall Console, configure your tunnel, select Configuration > Tunnel >
Tunnel_Name. At least configure two hostnames: One for the authentication and one for the
web server access. The two domains must be the same. For example, the authentication server
could be auth.MyCompany.com and the web server can be MySite.MyCompany.com.
5. Change the Radius server type, select Configuration > Management > Authentication
Servers. In the Radius tab open your Radius Server and change the server type to RSA
SecurID.
6. Create an SSO server, in AppWall Console, select Configuration > Management > SSO
Server > Internal SSO.
Create a new SSO Server and provide the relevant information: Tunnel, Virtual Service, Host
(Choose the authentication server name. In our example it is auth.MyCompany.com),
Authentication server (the Radius - RSA SecurID server), the login/logout parameters.
A role has automaticaly been assigned to the SSO Server.
7. Create and configure your web application security policy, select Security Policies > Web
Applications > Tunnel_Name and add a new host in your tunnel with the name defined
above.
In the Host MySite.MyCompany.com, select the Authentication tab and provide the relevant
information. For Authentication Type select Internal SSO Server, for Backend Authentication
Type select None, for Authentication Server select auth.MyCompany.com, and the others
parameters can be configured as needed.
Note: Two roles appear, a PUBLIC role and a role name AUTHENTICATED-
Radius_Server_Name. Make sure that the Allow List filter is present in the PUBLIC role.
8. Connect to auth.MyCompany.com and test the authentication.
Note: 2 Authentication Factor: In step 6 above, in the SSO configuration page, the checkbox
Use 2 Factor Authentication must be checked and select the 2FA server.
Implementation of an Azure Authentication Server

Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution, allowing an
easy to use, scalable, and reliable solution that provides a second method of authentication with
One Time Password (OTP) for access from smart phones, tablets, laptops, and PCs. Users have
several different options on how they are going to connect and stay connected at any time. Alteon
Authentication Gateway offers a support for Azure MFA with an on-premise Active Directory
credential validation or using Azure Active Directory as an Identity Provider.

Security Tools
To configure the Authentication Gateway to authenticate web users from Azure MFA with
on-premise Active Directory
1. Create a Radius Server, in Alteon, select Configuration > Security > Authentication server
> Radius.
2. Create your Secure Web application, in Alteon, select Configuration > Security > Web
Security > Secure Web Applications.
3. In the AppWall Console, configure your tunne, select Configuration > Tunnel >
Tunnel_Name. Configure at least two hostnames: One for the authentication and one for the
web server access. The two domains must be the same. For example, the authentication server
could be auth.MyCompany.com and the web server can be MySite.MyCompany.com.
4. Change the Radius server type, in Alteon, select Configuration > Management >
Authentication Servers. In the Radius tab open your Radius Server and change the server
type to Azure.
5. Create a 2 Factor Authentication server, in AppWall, select Configuration > Management >
Authentication Servers. In the 2 Factor Authentication tab create your 2 Factor Authentication
server. Provide a name of your server and configure the First and the Second Factor with the
Radius server previously created.
6. Create an SSO server, in the AppWall console, select Configuration > Management > SSO
Server > Internal SSO.
Create a new SSO Server and provide the relevant information: Tunnel, Virtual Service, Host
(choose the authentication server name. In our example it is auth.MyCompany.com). Check Use
2 Factor Authentication and select your 2FA previously created, the login/logout parameters.
A role has automaticaly been assigned to the SSO Server
7. Create and configure your web application security policy, in AppWall, select Security Policies
> Web Applications > Tunnel_Name and Add a new host in your Tunnel with the name
define above MySite.MyCompany.com.
In the Host MySite.MyCompany.com, select the tab Authentication and provide the relevant
information. For Authentication Type select Internal SSO Server, for Backend Authentication
Type select None, for Authentication Server select auth.MyCompany.com, and the others
parameters can be configured as needed.
Note: Two roles appear; a PUBLIC role and a role name AUTHENTICATED-
Radius_Server_Name. Make sure that the Allow List filter is present in the PUBLIC role.
8. Connect to auth.MyCompany.com and test the authentication.
Security Page
When configuring the security page of a host within a Web application, you can define a locally-
hosted security page. This is in addition to the option of referring to a security page hosted on the
secured Web server.
To configure internal security pages

1. In the Security Policies view, select Web Applications > My Web App > My Host > Settings,
and select Internal Security Page.
2. Click Add Internal Security Page and follow the two- steps wizard.

Security Tools
The Security page can be configured as fully qualified domain name (FQDN) and not just as relative
path to the local web application. Additionally, there is a parameter (_event_transid) providing
information regarding the violating request which is added to the security page as query parameter.
The security page can process these parameters to present some of the information to the client (for
example, transaction ID) or to present different messages depending on the type of violation.
Security Page - User Defined Status Code
The configuration file WebApp.cfg contains information for the status code and the status message
that shows for a security page.
Some users want to give a different status code and message when the AppWall returns an internal
security page.
The user can change the status code and the status message if required.
The default value for the status code is 200 and the default for the status message is OK.
Valid values:200-599
If the transactions ID is embedded into the security page and presented to the client who performed
the security violation, the customer will be able to contact the support department at the protected
application site and provide a transaction ID for the security administrator to identify the exact
security violation event.
The prefix of the parameters detailed above can be edited to avoid exposure of AppWall device in
case of external security page defined using FQDN. Editing the parameter prefix performed in the
EventLog.cfg file in the <SecurityParamPrefix>.
<SecurityParamPrefix>_appwall_event</SecurityParamPrefix>
Additionally, the listed parameters can be added using javacript to the response page. By default
this setting is disabled but can be used for demonstration purposes. Enabling the javascript
performed in Comm.cfg file in the <InternalParams> section, in the InsertEventDataIntoPage
element.
Application Path
The Application Path specifies path parameters on the Web server and one or more Security Filters
that should be applied to a Web Application.
For information on how to add an Application Path to a Web Application, see Adding Hosts, and
Application Paths, page 139 in the previous section.
Managing Security Filters at the Application Path Level

This topic provides an overview of using AppWall Security Filters to monitor and protect network
traffic. Through the AppWall Management Application you can set up security policies for each
Application Path you define, which provides fine-grain control over your security environment.
To globally configure Security Filters, see Security Filters in Detail and Working with the Dashboard.
This section includes the following topics:
• Security Filter Overview
• Setting Security Filter Run Mode—Active, Passive, Disable, and Patch
• Refining Security Filters Definitions
Security Filter Overview

AppWall provides an adequate level of security that will satisfy the security needs for the majority of
users. However, the AppWall Management Application also provides you with the tools to customize
security policies for the particular needs of your enterprise.

Security Tools
Each Security Filter provides unique security protection. Use the AllowList Security Filter to specify
which paths or file types can pass without detection. Use the FilesUpload Security Filter to specify
the location where files can be uploaded.
This topic describes the standard procedures for changing Security Filters. For specific details about
each Security Filter, see Working with the Dashboard.
Setting Security Filter Run Mode—Active, Passive, Disable, and Patch

You can enable or disable different Security Filters within the Security Policy by setting the Security
Filter mode:
• Active mode enables stopping traffic triggered by the Security Filters.
• Passive mode enables full intrusion detection without stopping traffic (unless it is set to
escalate to Active).
• Patch mode enables full intrusion detection, while stopping traffic only where there is a patch.
(Patch mode is only available for Database and Vulnerabilities Security Filters.)
• Disable mode disables the Security Filter, allowing all traffic to go through.
You can run a full automatic configuration of your Security Filters by selecting the Auto Policy
Generation—Full Auto option. This ensures that the relevant security filters are automatically set
with the required mode, according to AppWall.
For further information, see Auto Policy Generation, page 166.
You can also work with Auto Policy Generation— Auto Refinements enabled (for the relevant Filters)
to ensure that refinements are still generated automatically, whatever the mode selected. See also
Working with Auto Policy Traffic Analysis Profiles for information on working with Auto Policy
Generation, which provide a pre-defined configuration.
To set Security Filters

1. In the Security Policies view, select Web Application > Tunnel > Host and select the specific
Application Path for which you want to set the Security Filter modes.
2. In the right pane, click the Settings tab and then select Active, Passive, Patch or Disable in the
Mode column (Note that this action is only available if the Full Auto option is not selected)
according to the requirements of your Web Application.
3. Click Submit and Save in the Content area, and click Apply on the toolbar.
Refining Security Filters Definitions

For some events in the Security Log, you can use the quick-click refinement feature to configure the
Security Policy based on a particular event. In order for a Security Filter to log events and for those
events to appear in the Security Log with Quick-Click refinements, the following conditions must be
met:
• The Security Filter must support Quick-Click Refinements. (See list below.)
• The Enable Log and Quick-Click Refinements options must be enabled for the Security Filter. For
details, see Setting Security Filters.
• The Security Filter is Enabled or Passive on one or more Application Paths. For more information,
see Enabling/Disabling a Web Application.

Security Tools
Host Level Configuration

Some security settings are configured at the host level and not at the Application Path level. These
settings can be global and applied to all hosts or overridden to specific host (for example,
www.google.com).
The Hosts section can be found in the Configuration view in the AppWall Management Application
where you can define which hosts (for example, www.google.com) are hosted on which web servers.
To map hosts to web servers

1. In the Configuration view, select Hosts.
2. In the Hosts to Web Server Bindings tab, click .

3. Enter a host name to be bound.
4. Mark the checkboxes of web servers that you wish to bind to this host from the displayed list.
5. Click OK. Your host has been configured and bound to web servers.
6. Once a host has been defined in the host section in the Configuration view, security settings can
be defined for that host in the Security Policy view.
The host level security settings include: CSRF, Hot Link, Directory Listing, URL Rewrite, Activity
Tracking, HSTS/Clickjacking and Reply Cookie Flags.
CSRF (Cross Site Request Forgery) Protection

This protection is activated only on the following HTTP methods: POST, GET, and HEAD.
CSRF is an attack which forces an end user to execute unwanted actions on a web application in
which they are currently authenticated. Usually, this type of attack is performed using a POST HTTP
method or using a GET method on dynamic pages.
By default, CSRF protection is set to passive mode (generating events but not blocking) and enabled
only on POST HTTP requests.
A list of standard landing pages is provided out-of-the-box in the Defenses Properties Section. An
additional excluded URI can be added and a list of search engine bots user-agents is also listed to be
ignored from inspection.
The CSRF protection is set at the host level in the host section.
It is possible to add trusted hosts for which the CSRF protection will not be applied. Trusted hosts
can be added either manually by clicking add in the trusted hosts list or by clicking Refine! on the
CSRF security events.
Excluded URI on which the CSRF protection will not be applied can added as well.
Prevention of CSRF (Cross Site Request Forgery) attack in AppWall

This can be configured for any group of hosts (using wildcards) or for a specific host.
The attack detection is performed by inspecting the referring header: Only a local domain referred
header or trusted hosts are allowed for transactions that are defined as protected.
The protection is configurable for different types of requests:
• POST method messages
• Get with query parameters
There is also a predefined list of allowable user-agents. These are search engines bots that AppWall
will not block from accessing the protected application for the purpose of indexing its pages.
Requests with these user-agent header values are not inspected.

Security Tools
By default the protection is enabled for POST messages only.

You can configure a list of excluded URIs for the CSRF inspection.
Hotlink Protection
Hotlinking or Bandwidth theft is the act of one site embedding content (such as images, audio files,
and videos) hosted on another site. This uses up the ‘bandwidth’ (data transfer allowance) of the
site hosting the file, which can be very expensive for webmasters who pay for hosting by the amount
of data transferred. Usually, this type of attack is performed using a GET method on static pages or
resources (for example, images).
By default, Hotlink protection is disabled.
A list of standard landing pages are provided out-of-the-box in the FactoryDefault.cfg file. An
additional excluded URI can be added and a list of search engine bots user-agents is also listed to be
ignored from inspection.
AppWall protects you from Hotlinking by inspecting the referring header.
It can be configured for any group of hosts (using wildcards) or for a specific host.
There is a pre-defined list of legitimate referrer header values (for example, search engines), and
additional ones can be configured.
Hotlinking protection can be configured on a different request but this usually will be defined on
media files.
Configuration options for protection on the following items can be added or removed:
• Media files
• Queries
• Any other Page
By default, Hotlinking protection is disabled.

There is also a predefined list of allowable user-agents header values. These are search engines bots
that AppWall will not block from accessing the protected application for the purpose of indexing its
pages. Requests with these user-agent header values are not inspected.
Excluded URIs can be defined. A possible example of legitimate URI can be images used in email
signatures (for example, /EmailSignature/image/).
To access Hotlinking
1. In the Security Policies view, select Hosts > [A Host].
2. Select the Hotlink tab. The Hotlink configuration options window appears. (Default is disabled.)
You can add/remove Trusted Hosts or Exclude URIs as appropriate.
3. Mark checkboxes as you require to protect: Media files, queries, and any other page.
Directory Listing
Directory listing is a fingerprint attack that exposes the structure and content of an application,
enabling the attacker to properly target his attacks. Prevention of fingerprint attacks is supported as
of AppWall version 5.31. Click Add to add excluded folders (suspicious GET requests with “/” at the
end of their URI). The replies for these requests are inspected to validate that there is no Directory
Listing information contained.

Security Tools
URL Rewrite
To obfuscate the real application structure from a potential attacker, you can configure a URL
Rewrite for the application structure by mapping the externally exposed folder structure to the
actual structure.
URL Rewrite modes include Active, Passive, and Disabled. In addition, you can set a rewrite rule
to Block mode. If the rule is set to Block mode and the rewrite mode is set to Passive, an event is
generated. If the rule is set to Block mode and the rewrite mode is Active, the request to the
destination folder is blocked, which is not expected to be accessed directly but only through rewrite
rule.
The Location and Content-Location HTTP headers are reverse rewritten to enable the proper rewrite
process.
Activity Tracking
Bot activities and attacks targeting Web applications are a complex threat for many site operators.
While simple script-based bots are not much of a challenge to detect and block, advanced bots
dramatically complicate the mitigation process using the following techniques:
• Mimicking user behavior: Several tools use a browser plug-in and are therefore able to mimic
user behavior, including running JavaScript, downloading images and other referenced content,
and following graphic links.
• Dynamic IP: Changing their source IP address allows tools to maintain a low rate of activity per
IP and thus evade IP-based detection systems.
• Anonymity: Tools are operated from behind anonymous proxies, CDNs, or carrier-grade NATs,
in order to keep the identity of attackers unknown.
In addition, the various bots aim to achieve different goals:

• Scraping extracts data from the application by generating sequential requests to search pages
where pricing information is available or to duplicate the application.
• Web application DDoS attacks impact Web server availability by generating different attack
vectors with:
— A high rate of requests to pages with large responses for the purpose of generating high
throughput.
— Low throughput connections (Low and Slow) impacting server stability.
— A high rate of requests to pages with high resource consumption on the server side, such as
search pages and login pages.
• Clickjacking activity to deceive pay-per-click-based advertisement systems to increase fake
payments.
AppWall Activity Tracking Module

To deal with these bot-generated threats, AppWall’s Activity Tracking mechanism can be set to one
of two operational modes:
• Anti-DDoS
• Anti-Scraping
Application DDoS does not necessarily target specific resources (though it may sometimes be the
case). Configuring AppWall to the Anti-DDoS mode tracks the activity of the users at the domain
level. If applied at the <Any Host> level, activity will be globally tracked (domain agnostic).
Scraping, however, is data-focused and usually targets specific Web pages where relevant
information can be extracted. In the Anti-Scraping mode, tracking is narrowed to the configured
URI(s). The Activity Tracking module counts the HTTP transaction rate to the defined application
scope (domain/page) per user per second. Once reaching the threshold, a security page is returned
instead of the requested resource.

Security Tools
The Activity Tracking module can be set to one of two tracking modes:
• IP-based tracking (available both in Passive and Active modes) is not intrusive.
• Device Fingerprint-based tracking (available only in Active mode) is intrusive.
While IP-based tracking offers the value of non-intrusive activity tracking and detection capabilities,
device fingerprint-based tracking offers IP-agnostic source tracking. AppWall can detect bots
operating in a dynamic IP environment and activity behind an sNAT (source NAT), such as an
enterprise network or proxy. Even if the bot dynamically changes its source IP address, its device
fingerprint does not change. AppWall tracks the device activity and correlates the source security
violations across different sessions over time.
Device Fingerprint technology involves various tools and methodologies to gather IP agnostic
information about the source. It also involves running JavaScript on the client side. Once a
JavaScript is processed, an AJAX request is generated from the client side to AppWall with the
fingerprint information. For demo purposes only, you can configure AppWall to show the Device
Fingerprint with all the gathered information. By default this page is invisible.
When Activity Tracking is set to IP-based tracking, it can be correlated with the IP blocking module.
Once a source IP reaches a configured threshold, the source IP is blocked (either Layer 3 or Layer7).
To avoid scenarios where AppWall is mistakenly detecting search engine bots (e.g. Google, Yahoo)
as malicious bots, there is a mechanisms in AppWall which is detecting legitimate search engine
bots, runs a reverse-DNS lookup process to verify their source and excluded them from the list of
sources which are being tracked.
To configure activity tracking

1. In the Security Policies view, select Hosts > My Host > Activity Tracking, and define the
action as Active, Passive, Inherit, or Disabled.
2. Select the Protection mode as Anti-DDoS or Anti-Scraping.
3. In Active action mode, select the Source Tracking Method as IP or Device Fingerprint.
4. Configure the Rate Thresholds as:
— HTTP Transactions per second per source
— HTTP Transactions per second per source per URI
5. In Anti-DDoS protection mode, configure the Exclude URI list. You can add folders or files
(regular expressions are supported) to be excluded from the tracking destination resources.
6. In Anti-Scraping protection mode, configure the Protected URI list. You can add URIs (regular
expressions are supported) to be included in the tracking destination resources.
7. In IP-based tracking method, add White list IP addresses as needed. By default, search
engine bots are excluded from the tracking sources list.
HSTS/Clickjacking
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect
websites against protocol downgrade attacks and click hijacking. It allows web servers to declare
that web browsers (or other complying user agents) should interact with it using only secure HTTPS
connections, and never via the insecure HTTP protocol.
Clickjacking is when an attacker uses multiple transparent or opaque layers to trick a user into
clicking on a button or link on another page when they were intending to click on the top-level page,
and routing them to another page, most likely owned by another application or domain.
AppWall's HSTS feature allows adding HTTP response headers to different hosts to improve security
in places where the application is lacking the required measures.
For more information, see https://www.owasp.org/index.php/List_of_useful_HTTP_headers

Security Tools
Two options of predefined headers are available, Strict-Transport-Security and Content-Security-

Policy, as shown in the screen below.
Strict-Transport-Security protects against protocol downgrade attacks and Content-Security-Policy
protects against clickjacking.
In addition to the predefined header values, the user can also add different headers in the response
if desired.
Reply Cookie Flags

A cookie returned from a web server can have attributes and flags, for example, “secure” and
“httponly” flags, that control the way the browser sends the cookie back to the server on the next
requests. The “secure” flag tells the browser to send the cookie only on a secure connection (i.e.
https), and the “httponly” flag tells the browser not to enable the page to read this cookie in
commands like document.cookie.
For security reasons, for some relevant cookies, the cookie returned from the server is modified to
contain the “secure” or “httponly” flag even if the server did not set them.
The Reply Cookie Flags option allows the user to update the returned cookie to contain a Secure or
HTTP Only flag.
Redirect Validation
Remote File Inclusion (RFI) and Local File Inclusion (LFI) are file inclusion vulnerabilities that allow
an attacker to include a file or expose sensitive internal content, usually exploiting a “dynamic file
inclusion” mechanisms implemented in the application. The vulnerability occurs due to the use of
user-supplied input without proper validation.
AppWall's Redirect Validation scans all parameters in the request

(including JSON, URL and body parameters) and looks for external or
internal redirect attempts to include files.
It is possible to add trusted domains and trusted URIs for which the Redirect Validation will not be
applied. These can be added manually by clicking 'add' in the trusted domains and trusted URIs list.
Defining Your Security Policy

This section describes the main scenarios in which AppWall is used to implement an Enterprise’s
Security Policy. This section does not cover all possible scenarios, but is designed to assist the user
in defining what is required to build the most effective Security Policy for the Enterprise’s Web
Application.
• AppWall Protection, page 156
• Defining Enterprise Requirements, page 156
• Setting a Security Policy, page 158
You can run a full automatic configuration of your Security Filters to practically eliminate any
administrator-level input. In addition, you can automatically discover the full structure of your Web
Application and to automatically assign Security Filters to the relevant directories at the click of a
button. For further information, see the relevant section.

Security Tools
AppWall Protection
The initial step in defining your Security Policy is to determine what exactly AppWall is going to
protect. The defining of what actually needs protecting is of utmost importance, because it enables
you to pinpoint your Security Policy’s exact requirements. For example, if you need to secure and
protect Dynamic pages (that require some user interaction), or if you are protecting types of Static
pages (including pages that hold media files), your defined Security Policy should reflect the settings
you require.
The following table provides some of the possible files/data that may need protecting. Once you
have determined what exactly needs protecting, click on the relevant link to see the possible
Security Policy settings you can apply.
Table 69: What needs Protection?M:\AppWall\AW 7.6.5 (with new webUI)\filtered AW-Alt
32.6.0\Security_Tools.fm
Requiring Protection
Dynamic pages, including:
• Database records
• Pages with parameters
• Pages with cookies
• XML pages
• Login pages
Static pages, including:
• Media files
• Pages without parameters
• HTML files
Administrator related content, which includes:
• Access and login data
• Web application reports and statistics
In addition, the environment in which you can install AppWall is also a major factor in defining your
Security Policy, at least initially. If, for example, you have a Test environment available, you can
apply some of the Security Filters in Passive mode with the Auto Refinements option enabled
where relevant. Once AppWall appears to have learned your application you can move to a
Production environment and the filters to Active mode with Auto Refinements enabled. If you only
have a Production environment in which to work, you should initially enable relevant Filters in
Passive mode with Auto Refinements enabled where relevant before moving to Active mode. For
further information, see Setting the Security Filter Run Mode, page 88.
Defining Enterprise Requirements

Another factor in defining your Security Policy is to determine what exactly your enterprise requires
and what it can commit to. The following series of questions is designed to enable you to define
exactly what you need from AppWall, though will, of course, depend on what you are protecting. In
addition, Web Application, page 137 provides an overview of a typical Web Application and some of
the security considerations that may offer some guidance to your own security requirements.

Security Tools
How secure does your Web Application need to be?

If security is of the utmost importance, then the Security Policy should reflect this. Perhaps the
obvious solution would be to enable all Security Filters, but this is not a viable option as this would
prove detrimental to your Web Application’s performance. However, depending on what you need to
protect, the relevant Filters specific to your needs can be enabled, as outlined in Setting a Security
Policy, page 158.
Do you need your Web Application to maintain high performance, or is security

paramount?
If your Web Application’s high performance is critical, it may prove beneficial to disable some of the
available Filters and maintain only those Filters that are critical for security, such as the
Vulnerabilities, Database and HTTPMethods Filters. If security is more critical an issue, then the
relevant Filters should be enabled. Be aware, however, that ensuring that your Web Application is
completely secure may have some effect on performance.
How advanced is your administrator knowledge/level of expertise?

If your level of Web Applications and Web Application security knowledge is limited, it may prove
beneficial to implement the basic settings as described in Setting a Security Policy, page 158. It is
also recommended to run the Full Auto option. If your knowledge is expansive, Radware
recommends you look at additional sections in this Guide or the Online Help for additional
configuration options that can enhance your Web Application’s security and performance still further.
Are you able to monitor AppWall constantly or once every so often?

The Security Policy that you define will determine the amount of time that you need to maintain it.
The two Security Filters that require the most input and time from Administrators are the AllowList
and Parameters Filters. If you require these Filters it is recommended to activate Auto Policy
Generation (in Passive mode if in a Production environment) and to then check periodically to check
refinements generated and to ensure no “false positives” (where legitimate requests are blocked)
occur.
In addition, if the Web Application is updated regularly, in particular with new media content, you
should consider whether to use the AllowList Filter.
Is your Web Application constantly evolving or is it stable and fairly static?

If your Web Application is constantly evolving and being updated you should note that some
‘negative security model’ Security Filters, such as the Vulnerabilities and Database Filters, actually
work well with pages that are constantly changing. Likewise, ‘positive security model’ Filters find it
more difficult to keep track of updated pages – Auto Policy Generation does help where available,
but it does require more monitoring time from the Administrator.
How quickly do you need AppWall deployed?

If you need AppWall employed immediately, Radware recommends you follow the basic guidelines
detailed in Setting a Security Policy, page 158. If, however, you have the time and resources to
invest in deploying AppWall in the most effective way, you can reap major benefits in both improved
security and improved performance.
Note: Web Application
The following example of a Web Application is designed to provide some guidance as to the security
issues you should consider when defining your own Web Application’s Security Policy. The example
below is a web store, with the URL www.booksetc.com, which AppWall will be protecting. This
imaginary store includes three subfolders; books, shopping and admin.

Security Tools
Figure 28: Web Application Example
The /books/ subfolder contains pictures of book covers, with additional HTML descriptions for each
book. These are static files and require minimal protection. Cookies may or may not be relevant for
a site like this.
The /shopping/ subfolder contains a shopping cart script, as well as a login page. These are dynamic
pages that require user input using parameters. There is also a backend database and cookies,
which both need protecting.
The /admin/ subfolder contains the web administrator’s login details and access to web statistics and
reports regarding the site. This is Administrator related content and should be restricted.
See the following section for details on how to actually apply the most effective Security Policy to
each of the above folders.
Setting a Security Policy

This section describes how to set your Security Policy, according to some of the factors described in
the previous sections, and includes the following:
• Basic Security Filter Guidelines
• Dynamic pages (which includes Database records, pages with parameters, pages with cookies,
and XML pages)
• Media files
• Administrator related content
• Public content
Refer to the appropriate section for an overview of the AppWall Security Filters. Alternatively, refer
to Working with Security Filters, page 85.
Basic Security Filter Guidelines

Your Security Policy is primarily defined by the Security Filters you select to work with. This section
includes tables that provide basic guidelines on how the Security Filters may affect your Security
Policy. For in-depth information on actually setting your Policy according to your requirements, see
the Dynamic Pages, Media Files and Administrator Related Content sections.
Filter Effect on Performance

The following table describes how each of the Security Filters affects performance.

Security Tools
Table 70: Filters affecting Performance
Filter Effect on Performance

AllowList Minimal, though if Auto Policy Generation is activated, performance
can be affected.
BruteForce Minimal
Database Minimal-Medium, though if Auto Policy Generation is activated,
performance can be affected.
FilesUpload Minimal
GlobalParameters Minimal
HTTPMethods Minimal
Logging High
Parameters Minimal, though if Auto Policy Generation is activated, performance
can be affected.
PathBlocking Minimal
SafeReply High-Very high
Session Minimal, though if parameters or URLs are protected, impact on
performance is high.
Vulnerabilities Minimal-Medium
WebServices Minimal
XMLSecurity Minimal
Recommended Filters
The following table provides a basic guideline on what Filters you can apply, according to what you
need to protect.
Table 71: Recommended Filters
Filter Recommended for Static Recommended for Recommended for

Pages Dynamic Pages Admin Content
AllowList Not recommended May be applicable May be applicable
Only if the
PathBlocking Filter is
not activated
BruteForce Usually not required May be applicable
Login pages only
Database If you require high May be applicable May be applicable
performance, do not
activate this filter
FilesUpload Not Recommended Only where relevant
GlobalParameters Recommended only when there are Global Parameters
HTTPMethods May be applicable May be applicable May be applicable
Logging Not recommended Not recommended Not recommended

Security Tools
Table 71: Recommended Filters (cont.)
Filter Recommended for Static Recommended for Recommended for

Pages Dynamic Pages Admin Content
Parameters Not recommended May be applicable May be applicable
Only if the
PathBlocking Filter is
not activated
PathBlocking Only where relevant for folders or Web Applications May be applicable
that should not be accessed
SafeReply Not recommended If you require high May be applicable
performance, do not
activate this filter
Session May be applicable
Only when cookies are being protected
Vulnerabilities May be applicable May be applicable May be applicable
WebServices Usually not required May be applicable
Only when Web Services are in use
XMLSecurity Usually not required May be applicable
Only when XML is in use
Dynamic Pages
Dynamic pages include pages that have some interaction with the user, where user input is required.
These pages also include pages that retrieve and send data to a database, pages with parameters,
pages with cookies, and XML pages. In the Example Web Application, dynamic pages are contained
within the /shopping/ folder.
The following steps provide a basic guideline in how to create your Security Policy for dynamic
pages, preferably within a Test environment. Two basic factors, performance and security, are the
main issues that will affect how you define your Security Policy and are therefore expanded upon
where necessary.
To create your Security Policy for dynamic pages

1. Ensure that there is a Web Application and tunnel defined. These are created from within the
Alteon application.
2. When adding a new Web Application, select Create Application Paths Automatically to
ensure that the structure of your Web Application, its Application Paths, is created automatically.
Note: When selecting this option, Security Filters are also automatically assigned to each
Application Path according to what AppWall sees as relevant for that particular Application Path.
3. In the Security Policies view select the required Security Filters to apply to the Application Path.
See the steps below for further information on the Security Filters required. By default, when
working in Manual mode rather than with Auto Policy Generation enabled, the Vulnerabilities,
HTTPMethods, Session, Database, and SafeReply Security Filters should be set to Active for the
Application Path.

Security Tools
4. Map out your site to display folders with relevant properties – media files, login pages,
administrator files/folders – in which you can select the Create Application Paths
Automatically option, or by using Auto Discovery (see Auto Discovery, page 174). This enables
you to uncover your Web Application’s complete folder structure as soon as traffic to your Web
Application commences. If you are not running in a Production environment, use an external
Web Crawler to generate traffic. Radware also recommends discussing the application’s structure
with the application’s developers.
5. For each of the key folders you can now apply a Security Policy. Note that this section assumes
that you are not running the Full Auto Configuration option (as described in Auto Policy
Generation, page 166) and that you are manually applying your Security Policy. The following
list is a general list of the options available for dynamic pages.
a. General—For each of the folders you are protecting the Vulnerabilities and HTTPMethods
Security Filters should be activated. These two Filters do not have a significant impact on
performance and are critical for basic security.
b. Scripts and constantly updating pages—If any folder contains scripts, such as shopping
cart scripts, or pages are constantly added and/or updated, it is recommended to activate
the AllowList Filter. This filter does not have a heavy impact on performance and will
enhance security.
c. User input via parameters—If you have user input pages, such as login pages or
feedback forms where users enter a variety of parameters, it is recommended to activate
the Parameters Filter. For login pages, it is recommended to activate the BruteForce Filter,
which prevents illegal attempts to gain passwords, and does not have a big impact on
performance. Activating this filter is not enough; you will also have to specify the login page
to be protected.
Notes
If you have path parameters and want them protected, set the HTTP properties for the tunnel by
selecting Analyze Path Parameters. Path parameters are embedded parameters in the
request message URL (for example, http://www.site.com/ docs;
PathParameterName=PathParameterValue/ register.jsp?id=3.)
If you have the AllowList and/or Parameters Filters activated, it is recommended to enable at
least the Auto Refinements option to simplify and automate the refinement process.
— Database—If you have a database or LDAP server, it is recommended to activate the
Database Filter, which does not have a significant impact on performance. This filter also has
Auto Policy Generation, which should also be activated.
Note that if database values are large (more than a few kilobytes) you can disable the
Database Filter for that particular parameter (manually) to enhance performance.
— Cookies—If you are working with cookies, activate the Session Filter. Note that the Session
Filter does have some impact on performance. As an alternative, if you do not need the
cookies encrypted but want some protection, you can activate the Parameters Filter, making
sure to set the relevant settings (select the ‘Analyze Cookies as Parameters’ checkbox) in
the HTTP Properties for the tunnel.
— XML—If you are working with XML pages, activate the XMLSecurity Filter, which has
minimal impact on performance.
— Enhanced security—If security considerations outweigh performance, it is recommended
to activate the SafeReply Filter, which protects Social Security and credit card numbers. This
filter offers enhanced security but can have some impact on performance.
— Additional protection—There are additional Security Filters that can be activated to
provide additional protection for dynamic pages, as listed below. Each of the filters listed has
minimal impact on performance when activated.

Security Tools
— FilesUpload Filter—If you want to monitor the upload activity of your Web Application
activate this filter. For example, you can set to evaluate requests to upload picture files (gif,
jpg, jpeg, bmp) to a specific application. An event is generated and the request is blocked
when a user uploads a DOC file to the specified Application Path.
— WebServices Filter—If you are working with Web Services, and want to verify and screen
them for invalid operations using a WSDL file, this filter should be activated.
— GlobalParameters Filter—Activate this filter to evaluate parameter values and to evaluate
parameters defined in other parameter-related Security Filters.
— Logging Filter—Activate this filter only in the event of serious problems (such as to debug)
to log request and reply messages, which can assist in troubleshooting and monitoring/
documenting invalid requests. This filter is not recommended for use in high traffic
production scenarios.
6. After determining the security filters required, you can apply the Filter mode using the
Automation Level tab according to your requirements and, more importantly, your environment.
If you are working with the following Filters, Radware recommends you use them in Active
mode.
— SafeReply
— Database
— Session
— Vulnerabilities
— HTTPMethods
If you are working with the following Filters and are in a test environment, you should use them
in Passive mode, together with Auto Policy Generation enabled.
— AllowList
— Parameters
If you are working in a Production environment with these same Filters, it is recommended to
work in Passive mode with Auto Policy Generation enabled. After using refinements and the
event log to ensure that events are being generated only for blocked files, you should move to
Active mode, with Auto Policy Generation still enabled.
7. As a general rule, leave the order of the Security Filters as is (you can move the filters by
selecting the filter and clicking the arrows in the top right corner).
Note: Some filters should be set before other Filters in specific situations. For example, the
XMLSecurity Filter has the option to parse XML attributes as parameters, which are then
analyzed by the Parameters Filter. In this scenario, the XMLSecurity Filter needs to run before
the Parameters Filter and should be set accordingly using the arrow buttons.
8. Once moving from a Test environment to a Production environment and your Security Policy has
been distributed successfully (as described in the section), it is highly recommended to monitor
any refinements generated, with adjustments to the filter settings perhaps being required if, for
example, events are being generated that should not be blocked.
Static Pages
Static pages refers to pages that are largely static, in so much that they are accessed for viewing/
audio purposes only, such as media files or HTML pages. These files may not be updated regularly,
though may come with accompanying text that can change. In the Web Application, page 137, static
pages are contained within the /books/ folder.
The following steps provide a basic guideline in how to create your Security Policy for static pages,
preferably within a Test environment. Two basic factors, performance and security, are the main
issues that will effect how you define your Security Policy.

Security Tools
To create your Security Policy for static pages

1. Repeat steps 1–4 as described in Dynamic Pages, page 160.
2. For each of the key folders you can now apply a Security Policy. As you are protecting static
pages, which are largely files such as HTML pages, images or MP3s, the maximum security you
will require is the Vulnerabilities and HTTPMethods Security Filters. These two Filters will ensure
good performance and security.
Note: Any additional Filters activated for folders that contain only static pages may have an
impact on performance.
User Tracking, Authentication and SSO

AppWall offers Authentication Proxy functionalities including a user tracking and authentication
enforcement mechanism in your secured application.
If you enable HTTP Session Tracking under the host, when a user logs into the secured application,
the user session is tracked using an HTTP session cookie. As a result, any security event generated
for any of the user transactions on any of the TCP connections established from the user's browser
to the application includes the username.
To set user tracking settings

1. In the Security Policy view, select the host object.
2. In the Authentication tab, enable the authentication mechanism.
3. In the Login Properties section, click Add and set the Login URI, Method, Username field, and
Password field.
4. Optionally, in the Logout Properties section, click Add to add Logout URIs.
5. Optionally, in the HTTP Session Tracking section, configure the relevant cookie name for correct
user tracking in case of an unsuccessful login.
If User Tracking is enabled under the host, and two or more Web roles are defined for the Web
application, User Tracking is implemented through LDAP Authentication mode rather than just
extracting the username from the field
After you have configured an LDAP server, you can enable the authentication option for that host.
Note: The login URI should exist within the secured application. AppWall does not store the login
URI.
By default, all policy settings for the Public role do not require authentication, and are accessible to
all users. All non-public role settings are applied to relevant users only after authentication. For
example, if the Public role can access only the /public/ folder and access to all other folders is
prohibited, only authenticated users are able to access those other folders, pending approval by the
configured security policy.
After you have enabled authentication for the host object, every client authentication process is
enforced against the configured authentication server (LDAP), and a new cookie is set by AppWall to
maintain the HTTP session initiated by the authentication process. You can set authentication
information over HTTP headers to be sent to the Web server for processing (for example, add a
username header so that it is added to all future transactions of the current user).

Security Tools
To configure the authentication settings

1. In the Security Policy view, select the host object.
2. In the Authentication tab, enable the authentication mechanism.
3. In the Login Properties section, click Add and set the Login URI, Method, Username Field,
and Password Field.
4. In the Logout Properties section, click Add to add Logout URIs.
5. In the HTTP Session Tracking section, if the authentication mechanism is used for role-based
policy enforcement for an application with a pre-existing authentication mechanism, click
Enable to enable the application session tracking option and define the session cookie to track.
6. In the AppWall Session Management section, you can configure the custom cookie expiration
time (Session Expiry) or edit the AppWall session cookie name (Cookie Name).
7. In the Client Authentication Headers section, click Add to add the authentication username to a
configurable header name, which is sent to the back-end server
Administrator Related Content—User Specific

Administrator-related content refers to files that are specific to the administrator, such as access and
login data, or reports and statistics from the Web Application. In the Web Application, page 137,
administrator related content is contained within the /admin/ folder.
The following steps provide a basic guideline in how to create your Security Policy for administrator
related content, preferably within a Test environment. Two basic factors, performance and security,
are the main issues that will effect how you define your Security Policy and are therefore expanded
upon where necessary.
To create your Security Policy for administrator related content

1. Repeat Steps 1–4 as described in Dynamic Pages, page 160.
2. For each of the key folders you can now apply a Security Policy. As you are protecting
administrator related content, it may prove preferable to completely block access to the folder
by activating the PathBlocking Filter. The very least you should activate is the SafeReply Filter,
while the more Filters activated for folders of this type of content, the better.
3. Repeat Steps 6–8 as described in Dynamic Pages, page 160.
Defenses Properties
This section contains the following topics:
• Landing Pages, page 164
• Bot List, page 165
• Search Engine Referer, page 166
Landing Pages
A landing page, or entry URL, is usually the first page that most users will be browsing to, when
accessing an application. AppWall’s list of landing page file extensions used for several purposes,
including CSRF and Hot–link attack mitigation modules. Both of these modules inspects the ‘referer’
HTTP header of the incoming HTTP request.

Security Tools
Landing pages are often linked to from social media, email campaigns or pay per click (PPC)
campaigns in order to enhance the effectiveness of the advertisements. The general goal of a
landing page is to convert site visitors into sales leads. By analyzing activity generated by the linked
URL, marketers can use click-through rates and Conversion rate to determine the success of an
advertisement.
When a user is performing search operation in a search engine, he will click on the link of found
results. By doing that the search engines redirects the user to a web page in our application. The
‘referer’ HTTP header value will be the search engine’s host and not an internal host.
AppWall ignores all HTTP requests to pages with landing page file extension when inspecting HTTP
requests for CSRF and Hot-Link attacks.
Naturally other external websites other than search engines might link to such pages.
Bot List
An Internet bot or web robot is a software running automated tasks over web applications. In many
cases bots are used as a tool to perform an attack campaign against applications, but also used for
productive means, such as search engines bots which crawl through the application and enumerate
the content for keyword search indexing purposes.
In most of the cases, these bots are welcome to access the application as we prefer our site to be
well indexed by search engine and to improve our search engine score.

Security Tools
The Bot List is a list of the different search engine bots' values user-agent header in HTTP
transactions, and a domain suffix of these bots. Once AppWall see a request with a user-agent from
the bot list, AppWall runs a reverse DNS lookup query on the source IP address. If host name
matches the defined suffix, AppWall treats this source as a search engine bot. Additional values can
be added to the list.
The Bot List is used to exclude these bots from the Activity Tracking analysis and as part of Hot-link
attack mitigation. In the Activity Tracking AppWall runs a reverse DNS lookup while in the Hot-link it
will only look at the user-agent header.
Search Engine Referer

This is a simple list used to view the search engine queries used by your visitors. It parses the
referer URLs of popular search engines in your access log and extracts the search queries.
When a user is performing a search operation in a search engine, they will click on the link of found
results. This causes the search engines to redirect the user to a web page in our application. The
‘referer’ HTTP header value will be the search engine’s host and not an internal host.
AppWall ignores all HTTP requests with ‘referer’ HTTP header values which are listed on the “Search
Engines Referers” list, when inspecting HTTP requests for CSRF and Hot-Link attacks.
Activity Tracking Global Settings

For every fingerprinted source, AppWall generates a persistent cookie. The expiration time of that
cookie is defined under the IP Validation field.
AppWall counts the number of HTTP transactions per source per domain or per URI. You can
configure AppWall to include static resources in the calculation. By default static resources are
ignored.
For demo purposes only, you can configure to show the fingerprint page to the end user.
> In the Logout Properties section, click Add to add Logout URIs.
You can configure the Fingerprinting page timeout. It is configured, by default, to two seconds. After
that time, even if the end user browser did not reply with the AJAX call with the device fingerprint,
AppWall will forward that client to the application. This setting provides a control on the level of
impact on the end user in latency and risk of false positives.
Auto Policy Generation

The Auto Policy Generation module provides AppWall administrators with the best tool for
automatically generating security policy for his Web application. The Auto Policy Generation module,
depending on the configured options, will automatically generate Application Paths, utilize the
required security filter, create refinements and switch the security filters into active mode. These
operations would normally require many manual refinements. Building a security policy usually
demands intensive work on the part of the administrator, while still leaving a system potentially
open to attack due to inherent human error. Auto Policy Generation is designed to secure a web
application as automatically as possible with little or limited user interaction.
There are different attributes of the secured application, the environment and the customer needs
that impact the process of policy generation. Auto Discovery lets you automatically discover the
structure of a web application (see Auto Discovery, page 174), while at the same time Auto Policy
Generation sets the relevant security filters for each of the Web Application’s directories.
This section contains the following topics:
• Known Types of Attack Protection - Rapid Mode, page 167
• Zero Day Attack Blocking - Extended Mode, page 167

Security Tools
• Security Filter Auto Policy Generation Tools, page 168

• Auto Discovery, page 174
Note: By design, in a cluster node configuration, when auto-discovery and auto-configuration are
enabled, if one of the nodes is disconnected, the configuration learned by the cluster auto-discovery
feature will not be synced to itself nor the available nodes which are still available. Only a manual
apply will sync the cluster itself.
Known Types of Attack Protection - Rapid Mode

Selecting “Known Types of Attacks” protection quickly generates an adaptive policy for a secured
application with limited user intervention.
A policy generated in this mode includes the following characteristics:
• A single application path which is the base application path.
• Tunnel Auto policy generation automatically adjusts the HTTP message sizes and generates
exceptions for the HTTP parsing rules.
• The following filters are used and configured automatically by adding refinements:
— HTTP methods
— Vulnerabilities
— AllowLIst with file extension rules only (not explicit filenames)
— SafeReply (when required)
— Database, with rules that have a confidence level higher than 2 (when required)
— PathBlocking is added with refinements to prohibit access to a risky path in the application.
Zero Day Attack Blocking - Extended Mode

Advanced auto policy generation mode generates advanced security policies with a wider range of
attack blocking capabilities than simple mode. The level or user intervention which is expected in
this mode is higher, and the time for generation of such a policy is longer, than for “Known Attacks”
mode.
A policy generated in this mode includes the following characteristics:
• The Tunnel Auto policy generation automatically adjusts the HTTP message sizes and generates
exceptions for the HTTP parsing rules.
• The following filters are used and configured by automatically adding refinements:
— HTTP methods
— Vulnerabilities
— AllowLIst (with explicit filenames)
— SafeReply (when required)
— Database, with rules which have a confidence level higher than 2 (when required)
— PathBlocking is added with refinements to prohibit access to a risky path in the application.
— Parameters
— Global Parameters
— Session

Security Tools
Working with Auto Policy Traffic Analysis Profiles

This topic provides details on the different Traffic Analysis Profiles. The automatically selected profile
is derived from the user inputs regarding his expectations for the level of security, “Zero Day” or
“Known Types” of attacks protection.
A Profile is a pre-defined configuration that defines how refinement probabilities are generated.
• Production - Automatic—Analyzes traffic properties from the production environment and
builds a dynamic network profile for a specific site according to which the Auto Policy Generation
module automatically builds the policy. Requires prolonged analysis.
• Production - Rapid Deployment—Suitable for production environments. Generates a policy
quickly and is the best fit for Rapid Auto Policy mode.
• Staging (attack free)—Machine Crawler—Suitable only for an attack-free environment
(stating). Can be used when automatically generated traffic can be processed. Can be used with
Enhanced mode to generate Application Paths only after crawling has stopped (1–2 days).
• Staging (attack free) - Manual Browsing—Suitable only for an attack-free environment
(stating). Used to build a policy quickly (4 hours) using manual browsing of the application. Can
be used with Enhanced mode to generate application paths after 4 hours of browsing an
application.
• Demo—Suitable only for demonstration purposes in an attack-free environment. Do not use in
production environments. Generates a policy within matter of minutes.
Security Filter Auto Policy Generation Tools

The following are the Auto Policy Generation levels, each of which can be set as required:
• Full Auto, page 169
• Auto Enabled, page 170
• Auto Refinements, page 170
To manually select the filter mode

1. From the Automation Level tab, select Manual for the relevant Filter.
2. Highlight the Mode column to display a drop-down list of mode options: Active, Passive, Patch,
Disable.
To automatically discover the structure of your Web Application (Full Auto)

1. Select Create Application Paths Automatically.
2. For more information, see Creating Application Paths Automatically, page 172.
Note: You can set only one the modes (Full Auto, Auto Enabled, Auto Refinements or Manual)
at any one time.
Auto Policy Generation Tuning

AppWall often only receives a single IP address as a source IP addresses (due to network
implementations such as a Proxy in front of the AppWall).
For more details on how to extract original source IP address from an HTTP header, refer to
Appendix E.

Security Tools
There are also other occasions where full Auto Policy Generation is not recommended and will not
function normally:
• When the AppWall IP Blocking Feature is in use.
• When a caching system is being utilized in front of the AppWall.
• When a Web site is static.
• When full control over security policies is required.
Therefore, Radware recommends that you use IP Blocking or Auto Policy Generation but not both.
Warning: IP Blocking should not be used when Auto Policy Generation is enabled!
Full Auto
This option automatically determines whether a specific Security Filter in a specific directory needs
to be Enabled or Disabled. It also enables you to discover an application’s structure and to
automatically activate the relevant Security Filters for each Application Path (if the Create
Application Paths Automatically checkbox is selected).
When this option is selected, no user interaction is required, except for recommended periodical
reviews of logs and events to ensure that the Auto policy generation feature is working correctly. In
fact, the administrator requires no knowledge of the protected Web Application and does not need to
be informed of modifications to the application.
To activate Full Auto
Note: When running the Web Application wizard, Creating a Web Application you have the
option to create Application Paths automatically or manually, with Security Filters defined
accordingly. Once the Web Application is created, and with at least one Application Path defined,
continue to Step 2.
3. If you have yet to create a Web Application, create one in the Alteon main application window.
4. In the Security Policies view, select the specific Application Path to display in the right pane. If
you selected to automatically create Application Paths, Auto Policy Generation determines which
Security Filters are relevant for that path and displays them.
Note: If you manually selected Security Filters when creating the Web Application, these filters
display in the Active Protection Level tab under the Settings tab, with the relevant mode you
defined; Active/Disabled/Passive/Patch.
5. Under the Settings tab, in the displayed list of Filters, select the Full Auto option button where
relevant.
6. You can also select the current mode of the filter, which may require the temporary deactivation
of the Full Auto option. For example, if your Web Application has undergone many changes, it
may be advisable to select the Manual option and set the filter as Passive before verifying that
the changes have been learned by AppWall and then setting the filter to Active. In this scenario,
it may also be advisable to switch to Auto Enabled: for further information see Auto Enabled.
Note: In addition, the Full Auto option is not available for all Filters because some, such as
the BruteForce and XMLSecurity Filters, require manual interaction from the user.

Security Tools
7. Click Submit and Save and then Apply.
Auto Enabled
The Auto Enabled option automatically determines which operational mode the Security Filter
needs to be in, either Passive or Active; Disabled is not available. This option works in tandem with
the Auto Refinements option, meaning that both these options are relevant only to specific
Security Filters (AllowList, Parameters, vulnerabilities, HTTPMethods, and Database Filters) and both
options operate interactively according to the amount of refinements taking place. Note that manual
refinements are not taken into consideration when determining the operational mode for a filter.
When there are a significant number of refinements taking place in a filter, the filter should
automatically be set to Passive mode. When the number of new refinements has considerably
dropped, the Auto Enabled option will switch the filter to Active mode automatically.
It is important to note that the Auto Enabled option works on the Application Path level, and will
only change the mode of a given Filter if there is considerable Web traffic in the Application Path/
directory. For example, if there are few refinements, but at the same time there is very little traffic
going through the particular Application Path, then the Auto Enabled option assumes the
Application Path is mostly inactive, and is unable to define the mode of operation. As soon as traffic
picks up again, checks are automatically made to determine if the operational mode should be
changed for the specific filter.
To activate Auto Enabled

1. As per the instructions for setting the Full Auto option, first create your Web Application. Once
the Web Application is created, and with at least one Application Path defined, select the
relevant Application Path. In the right pane, select the Settings tab and then click the
Automation Level tab.
2. Select the Auto Enabled option button for the relevant Security Filters.
Auto Refinements
Auto Policy Generation, when working with the Auto Refinements option, automatically adds
refinements to the more complex, hard to configure Filters, specifically the AllowList, Parameters,
and Database Filters, therefore reducing the burden on the administrator while simultaneously
providing a high level of protection. It is not fully automatic as compared to the Full Auto option,
but it allows the user a high degree of control over the enterprise’s Security Policy using the more
vital security filters available in AppWall.
The Auto Refinements option has three types of refinement that it automatically configures the
system with:
• AllowList refinements—Files that Auto Policy Generation believes should be allowed access.
• Parameter refinements—Parameters (per URL) that Auto Policy Generation believes should be
permitted. Auto Policy Generation assumes that all parameters are of type string and
automatically learns to limit them to specific length ranges.
• Database refinements—Add refinements on a very granular level: it adds rules to disregard
on a URL+Parameter level.
• Vulnerabilities refinements—Add refinements on an Application Path level.
• HTTP Methods refinements—Add refinements on an Application Path level.
• Session Auto refinements—Add refinements on an Application Path level.

Security Tools
For information on how to work with Auto Refinements in the AllowList and Parameters Security
Filters (for the Database Security Filter refinements display only and cannot be managed), see
AllowList Auto Policy Generation Refinements, page 93 and Parameters Auto Policy Generation
Refinements, page 172.
To activate Auto Refinements

1. As per the instructions for setting the Full Auto option, first create your Web Application. Once
the Web Application is created, and with at least one Application Path defined, select the
relevant Application Path. In the right pane, select the Settings tab and then click the
Automation Level tab.
2. Select the Auto Refinements option button for the relevant Security Filters.
AllowList Auto Policy Generation Refinements

This section describes how to work with the refinements generated for the AllowList Security Filter.
You should note that when Auto Refinements is enabled, it may add refinements that you want to
manually control and monitor. If you delete one of these refinements, the next time Auto Policy
Generation encounters the same refinement it will be added again. To prevent this, you can Lock a
refinement, which ensures that the refinement is not added again by Auto Policy Generation.
Refinements can be easily added or locked to/from the AllowList Filter, as described in the following
procedure.
To accept or lock refinements to/from the AllowList Security Filter

1. In the Security Policies view, select Filters > AllowList. A list of URIs currently permitted
displays in the AllowList tab.
2. To move a refinement to the Locked list (in the Auto Configuration Locked tab, see below), right-
click on the refinement and select Locked. The file is moved to the Locked list and can no longer
be accessed by users (after clicking Submit and Save and Apply). The refinement will not be
added again by Auto Policy Generation.
3. To move a locked refinement to the AllowList, click the Auto Configuration Locked tab. Then
right-click on the refinement and select Add As Refinement. The file is moved to the AllowList
tab and is now permitted for access by users (after clicking Submit and Save and Apply).

Security Tools
Parameters Auto Policy Generation Refinements

This section describes how to work with the refinements generated for the Parameters Security
Filter.
When enabled, the refinements listed in the Refinements tab (accessed from the Security Policies
view) are automatically generated by the Auto Policy Generation module. Note that you can lock
parameters so that they do not get automatically updated in the Security Filter: double-click on a
displayed parameter to display its properties, and select the Lock checkbox to ensure any
refinement with this parameter does not automatically update the Parameters Security Filter. A
padlock icon is inserted next to the relevant parameter in the Refinement list, as shown below.
Creating Application Paths Automatically

You can determine whether or not Application Paths are created automatically from the Web
Applications window, as shown in the following procedure.
Notes
• At least one of the Security Filters must be set to Full Auto when selecting the Create
Application Paths Automatically checkbox for this feature to work.
• Application Paths are only created for the current folder. For example, when in the root folder,
selecting the Create Application Paths Automatically checkbox ensures that all Application
Paths can be discovered.
To configure Application Paths to be created automatically

1. In the Security Policies view, select the relevant Application Path and in the Settings tab, click
the Automation Level tab (as shown in Full Auto, page 169).
2. Select the Create Application Paths Automatically checkbox, click Submit and Save and then
click Apply, or
3. In the Security Policies view, select the Web Applications main folder. In the right pane a list of
your Web Applications displays.
4. Select the relevant Web Application in the upper pane and select the Auto Application Paths
checkbox to ensure that all Application Paths for this Web Application will be created
automatically (alternatively, clear the checkbox to disable this feature).
5. In the lower pane, all Application Paths associated with the selected Web Application display.
Implementing Auto Policy Generation

In order for the Auto Policy Generation feature to work, the following settings must be configured:
Auto Discovery must be enabled (by default it is disabled). To enable Auto Discovery, in the Auto
Discovery view right-click a host and in the displayed popup menu, select Resume.
In the Security Policies view, one of the Full Auto, Auto Enabled or Auto Refinements options in the
Automation Level tab should be selected. Note that if the Manual option is selected, Auto Policy
Generation is not fully operative, though you can select the Security Filter mode to ensure that the
Security Filter is operational (or not, according to your requirements).
Typical Deployment Stages for Auto Policy Generation

To better understand the benefits of Auto Policy Generation, this section describes some deployment
stages and where Automatic Configuration fits in.

Security Tools
• Initial Deployment in a Testing Environment

During the initial deployment phase, the customer will switch on AppWall for the first time. It is
recommended that the AppWall is first deployed in a testing environment. Once the
administrator is satisfied that all the refinements are in, the learned configuration can be
deployed in the Production phase (see below). It is important to note that in this deployment
phase, Automatic Configuration does not play a role.
If the customer does not have a testing environment, they should proceed to the “Initial
Deployment in a Production Environment” section below.
• Initial Deployment in a Production Environment
Automatic Configuration is beneficial for both customers who do not have a testing environment
and customers who already have AppWall deployed in production but do not have Filters such as
AllowList and Parameters in “Active” mode, and want to activate them.
In these scenarios, it is recommended that Filters are set to “Passive” mode, with Automatic
Configuration activated (in Full Auto mode). In such a scenario, new refinements should be
added automatically over time. For Filters such as the AllowList and Parameters Filters, the
customer should give approximately a week for the refinements to be fully added. When the
customer is satisfied with the new refinements, the relevant Filters can be set to “Active” and
deployed in the “Production” phase.
Note: You should review the “Event Log” to verify that there are very few, if any, events
generated for valid requests.
• Application Changes in a Production Environment

Once the filter is in production, that is in “Active” mode, it is recommended that the Full Auto
Automatic Configuration option be activated. This will enable AppWall to adjust the
refinements for the relevant filters, automatically and in the background, whenever the Web
Application changes.
If the customer knows that no changes are planned for the short term, the customer can disable
Automatic Configuration for that period of time. When new changes are expected, it is
recommended that the customer once again activate Automatic Configuration.
Auto Tunnel Settings Optimization

The tunnel object has different settings that require optimization and modification once AppWall is
deployed. When Auto Tunnel Settings Optimization is enabled for the tunnel, it instructs the Auto
Policy Generation engine to automatically optimize tunnel level settings, including message size
settings both for the request and the response, the of adding of new headers with explicit size
limitations, and HTTP parsing properties exceptions. By default, this is enabled.
Note: Auto Discovery must be enabled for the Auto Tunnel settings Optimization to function.
Auto Policy Generation for Web Roles

AppWall can generate automatically policy for specific web roles once those were defined. If you
define multiple Web roles, add them to your security policy, and enable auto policy generation for
the relevant application paths, AppWall generates auto policy for each role independently.

Security Tools
Auto Discovery
The Auto Discovery view provides linkage between the Security Policy and Application view. The
Application view contains all URIs, parameters, cookies, path parameters, and query parameters
contained in user requests.
The Auto Discovery view assists in discovering the structure of Web Applications according to the
configured Security Policy and according to Web Application traffic. Upon configuration of the
Security Policy through the Management Application, traffic to the Web Application is registered in
the Auto Discovery tree. The Auto Discovery view receives the information about user traffic using
an HTTP-Message structure. Even requests made to non-existent pages are registered, as are
requests that were rejected, for example, Web server down.
The Auto Discovery tree displays an application view that contains the server, tunnels, hosts, folders
(URIs), files (pages), and parameters (Path and Query). The Auto Discovery tree structure is
combined of the tunnel as the root object, the host, taken from the HTTP Header, and the root URI,
which is the root folder of the application structure.
Auto Discovery detection can be disabled and resumed at the tunnel level, by right-clicking the
tunnel and selecting Suspend/Resume. Note that this only suspends the tunnel from Auto
Discovery and in no way does it compromise your security policy.
In addition, Auto Discovery must be enabled (by selecting Resume) in order for Auto Policy
Generation to work. See Auto Policy Generation, page 166 for further information.
Note: The Auto Discovery module creates a single XML document, where all of the discovered
information is held.
To discover the application structure

1. Create a Security Policy by following these steps:
2. Create the Tunnel node that represents the Web Application from the Configuration view.
3. In the Security Policies view, add a new Web Application and Application Path that represent the
structure of your Web Application.
4. From the Alteon main application, create the tunnel node that represents the Web Application.
5. From the Alteon main application, add a new Web Application and Application Path that
represent the structure of your Web Application.
6. In the Security Policies view, select the required Security Filters to apply to the Application Path.
By default, the Vulnerabilities, HTTPMethods, Session, Database, and SafeReply Security Filters
are set to Active for the Application Path.
7. On the main toolbar click Apply . The structure of your Web Application will be registered in the
Auto Discovery tree as soon as traffic to your Web Application commences. If you are not
running in a Production environment, use an external Web Browser to generate traffic.
8. In the Auto Discovery view, double click the server node. The structure of the Application
displays.
Note: The numbers in brackets represent the number of children (for example, files, folders, or
parameters) under the specific parent.
The table below provides an explanation of the icons displayed in the image above:

Security Tools
Table 72: Explanation of Symbols in the Auto Discovery View
Icon Description
Represents the actual Application Path.
Represents the URIs that are inherited from the Application Path (folders mapped
to a specific Application Path).
Represents a URI with unknown mapping to Security Policy Application Paths
(usually due to temporary communication issues)
Represents a URI that is not routed to any available Application Path in the tunnel.
{P} Path Parameter
{C} Cookie
{Q} Query Parameter
Auto Discovery Refinements

At the Application Path level, the list of Security Filters displays. Configuration of these Security
Filters is possible according to the requirements of the Web Application.
When the icons representing Routed to Application Path display no refinements are presented.
Selecting any of the Security Filters in the list displays the relevant Security Filter Refinement List.
The Refinements tab allows the user to define the rules and patterns to apply to a specific page in a
Web Application, Tunnel, Host, or Application Path.
Auto Policy Generation Statistics

The Auto Configuration tab, displayed when clicking on a URI in the Auto Discovery tree, gives
details of the potential refinements encountered. For example, the probability ratio of the refinement
being a valid refinement displays (low % figures in the Max. Probability column indicate that the
Auto Configuration Profile selected is probably a Prod Profile, which require a greater amount of time
and events to learn if the refinement is valid or not - 80.0% or above in the column indicates that
the refinement is almost certainly valid).
To display the possible refinements for all the descendants of a URI (descendants are indicated by
the number in parenthesis next to a URI in the Auto Discovery tree) select the Descendant
checkbox to display all the refinements.
Adding an Application Path in Auto Discovery

Once the linkage between the Security Policy and the Application view has been established and
displays in the Auto Discovery tree, it is now possible to define URIs as Application Paths. Only URIs
that are routed to a specific Application Path may be defined as Application Paths.
The following image displays the Application view in the Auto Discovery tree:
To define a URI as an Application Path

1. Right-click the icon representing the URI to define as Application Path, and from the menu select
Define as Application Path. The Add an Application Path wizard displays.
2. Click Next.
3. Select a Web Application from the menu.
4. Define the security page and click Next.
5. Click the (Edit) button to edit the security properties of the Application Path, and click OK.

Security Tools
6. Click Next, and click Finish. In the Security Policies view, under the new Web Application, the
defined Application Path is now visible.
Auto-Policy Analysis Rules

AppWall supports adding rules to analyze certain HTTP replies as different types for the purpose of
Auto Policy Generation. For example, new Web applications tend to use a “302” reply status code
instead of “404” (page not found). AppWall is required to identify these “not found” page replies to
properly generate a security policy. You can define a rule to analyze “302” replies with certain values
in the reply body or parameters as “404” replies for that purpose.
To configure auto-policy analysis rules

> In the Security Policies view, select Auto Policy Generation > Auto Policy Analysis Rules,
and add a new analysis rule with the following information:
— Received status code (for example, 302)

— Analyze as status code (for example, 404)
— Header or body value identifiers
Site Map List

Site-map files (compliant with the sitemaps.org format) are commonly available for external access
in many sites for the use of search engine bots. Usually such file if exists for a host will be located
under the / folder named sitemap.xml (for example, http://www.google.com/sitemap.xml). You can
import such external site map file for AppWall to process it for policy generation.
In order to automatically generate policy for the secured application, you should select the newly
generated sitemap.xml file and click the “process” bottom. Processing status is presented. For large
site map files (over 10 MB) processing might take dozens of minutes.
Note: For the Site-map Processing to be completed successfully AppWall prerequisite conditions are
required:
• Auto Discovery must be activated

• A Web Application with the relevant tunnels, set to Auto Mode must be defined
Auto Policy Generation Properties

You can use auto policy generation properties for profile and policy creation.
To access Auto Policy Generation

1. Go to Security Policies tab and select Auto Policy Generation. The Auto Policy Generation
window appears.
2. Click to reset data as appropriate.
3. Select a profile.

Security Tools
4. A policy creation progress bar displayed.
Note: To counter a vulnerability, the Automatic Configuration module has Application Paths
where the PathBlocking Security Filter is enabled. Thus the Auto Policy Generation module
prevents “Predictable Resource Location” Attacks on the protected application. See Setting
Security Filters.
The following profiles are now available:

• Prod-Automatic: analyzes traffic properties from the production environment and builds a
dynamic network profile for a specific site according to which the Auto Policy Generation module
will automatically build the policy.
• Testing-Normal: Limited to reduced time periods and a minimal number of Event IPs (3).
Recommended for testing purposes only.
• Demo-At Once: Limited to a small range of time periods and one IP. Not recommended for use in
production environment.
Auto Policy Progress

The Auto Policy Generation progress bar shows the progress of the generation. The first half of the
progress bar shows the dynamic profile generation, and the second half shows the progress of the
auto policy generation.

Security Tools

CHAPTER 5 – BEST PRACTICES
This chapter describes the best practices required to maximize your AppWall experience.
• Policy Changes and Their Effect on Performance, page 179, describes the effect any changes
made to a Security Policy will have on system performance.
• Working with the Dashboard, page 190 describes how to view and analyze real-time network
activity.
Policy Changes and Their Effect on Performance

Defining your initial Security Policy should result in the optimal Security Policy for your Web
Application at a given time. However, as changes to your Web Application inevitably occur, changes
to your Security Policy will almost certainly be required. Any changes should be carefully considered,
as, for example, the simple activation of a Security Filter may have a significant impact on your Web
Application’s performance.
For example, if your Web Application has undergone many changes, it may be advisable to set a
filter as Passive before verifying that the changes have been learned by AppWall and then setting
the filter to Active. Note that when in the Full Auto Policy Generation mode, this process is
performed automatically; when a filter also has the Auto Enabled option this may be activated,
rather than Full Auto.
The key factor in making any changes to your security policy is to realize that the Security Filters
were not created equal in regards to performance issues. A modification to your Web Application,
such as the introduction of cookies, logically demand the activation of the Session Security Filter to
ensure the cookies are protected, but this filter can have some impact on your Web Application’s
performance.
As a result, when making changes to your security policy, it is recommended to follow the guidelines
described in the section, as well as referring to details on each of the relevant Security Filters.
Working with Events

This section describes how to work with the events generated within AppWall, and includes:
• Viewing Events in the Forensics View, page 180
• Reviewing the Event Log, page 181
• Viewing Event Details, page 181
• Reading a Log, page 182
• Working with the Security Log, page 184
• Accessing the Security Log in the Forensics View, page 185
• Quick-Click Refinements From the Security Log, page 186
• Displaying Graphical Reports of Applications and Security Filters, page 186
• Viewing Security Events by Applications, page 187
• Viewing Security Events by Filters, page 188
• Viewing Security Events per Application, page 188
• APSolute Vision Reporter, page 189

Best Practices
Viewing Events in the Forensics View

The Forensics view of AppWall Management Application allows you to examine and analyze AppWall
event logs. Analyzing event logs is a key factor when deploying AppWall as it enables you to
determine the validity of events being generated and whether or not AppWall has correctly learned
your Web Application.
The Forensics view consists of a Forensics tree in the left pane that lists a set of AppWall logs and an
Event Viewer in the right pane that contains event records for each log.
Figure 29: Forensics Tree
The Forensics view generates and displays the logs and reports described in the following table. For
further information on these event logs and reports, see Reviewing the Event Log, page 181.
Table 73: Forensics Logs and Reports
Tree Node Description

Administration Log Reports activities of AppWall Management Application such as
configuration changes, unauthorized login attempts, server restarts.
System Log Reports activities of the AppWall processes such as licensing information
and AppWall configuration changes
Initialization Log Reports when the last system startup occurred and what processes were
started, including Security Filters, Web Applications, and Licensing
Manager. This boot log is replaced each time AppWall restarts (service/
process level restart).
Escalation Log Reports when an escalation rule has been activated, and the tunnel being
escalated. Reports the rule and action applied to the tunnel, the time
limit, and whether the escalation was manual or automatic.
Security Log Reports and events about security policy violations and login information
for all Web Applications being monitored.
Events by Application Displays a graphical pie chart depicting event types by Web Application.
Report

Best Practices
Table 73: Forensics Logs and Reports (cont.)
Tree Node Description

Events by Filters Report Displays a graphical pie chart depicting event by type of Security Filter.
Events per Application Displays a graphical pie chart depicting event types in a specific Web
Report Application.
Note: AppWall stores events in a local SQL-Lite database. The following are the default files size
limits:
• Security: 250 MB
• System: 50 MB
• Escalation: 10 MB
• Administration: 10 MB
• Initialization Log: 10 MB
All database files are located under: ./Event/ folder

Using 250 MB for the security log, AppWall can store up to 350,000 events. When reaching the
maximum file size, AppWall deletes 20% of the database and generates an event in the system log.
Note: If the AppWall Management Application contains more than one AppWall server, the Forensics
view contains a set of logs for each AppWall server.
Reviewing the Event Log

This section describes how to review Event logs, for both periodic and post-mortem review.
Accessing the Event Viewer

The Forensics view in the Management Application has a node for each type of log available. By
selecting a Log node, the Event Viewer appears in the right pane displaying events for this Log.
When you select a log node from the tree, the AppWall Security Event Viewer changes, depending
on the type of log displayed.
To access a log
1. In the Forensics view, select the type of log node you want to view: Administration Log,
System Log, Initialization Log, Escalation Log, or Security Log. The expanded node
displays one log, the Default View.
2. Select the Default View to view the log. The log appears in the right pane.
3. Double-click a row to display the event’s properties and description.
Viewing Event Details

Use this procedure to view the event details.

Best Practices
To display details about an event in the Event Viewer

1. Select an Event in the Event Viewer.
2. The event details display in the Event Details window.
Reading a Log
Logs enable you to easily monitor system activity throughout the AppWall server environment.
Even though each log reports different types of events, most logs provide information listed in the
following table
Table 74: Log Examples
Column Description
Severity The severity level of the event: Lowest, Low, Medium, High, or Critical.
Passive Indicates whether the event was logged by an AppWall Gateway in

Bypass mode. An AppWall Gateway in Bypass mode performs no action
apart from logging and reporting events. This field helps the user
differentiate between events that were protected by the AppWall
Gateway and events that were only detected and logged.
Security Log only.
Date Date and time the event occurred.
Title A short description of the event.
Threat The attack type, such as SQL Injection.

Events are grouped by their threat type and can be filtered by group.
Generated By Module of AppWall server that generated the event such as System
Manager, Security Filters, Administration.
Reported On AppWall server module on which the event was reported.
IP Address Security Log: the client IP that generated the event. Administration
Log: the Console machine IP that generated the event.
Available in Administration and Security Log only.
User Name Name of the particular user.
Available in Administration Log only.
Time Limit Maximum time allotted for the escalated security policy.
Available in Escalation Log only.
Is Manual The method of invoking the escalated security policy.
Values: Manual, Automatic.
Action Action taken on the escalated security policy. Possible values are:
Escalation, De-Escalation.
New State The state of the tunnel after the escalated security policy is applied.
Possible values are: Bypass, Passive, Active.

Best Practices
Table 74: Log Examples (cont.)
Column Description
Rule Name The name of the escalation rule.
Event Transaction ID This parameter is useful when the relative or the absolute path to the
security page is returned to a client for request which violates the
security policy and is actively blocked.
Therefore, when defining a relative path to the security page, a query
parameter is added to the request. This enables the page to add the
event transaction id to the response for the end client to have a ticket
number when accessing support, and enable easy filtering of the
security event log.
Forensics events can be easily filtered according to all the listed parameters below.

Best Practices
Click the Filter button to open the Log Filter window.
Figure 30: Log Filter window
Note: After upgrading from versions 7.6.6 and earlier, filtering events by 'Refined' will include only
new events generated after the upgrade. Filtering events by 'Not Refined" will include all events
from before the upgrade, refined and not. For best results, it is advisable to use this filter together
with a time range filter.
Working with the Security Log

The Forensics view Security Log helps you to monitor and improve the effectiveness of your security
policies. This log provides pertinent information regarding all security-related operations and invalid
requests. By viewing the Security Log, you can get a perspective of your security policy for the
configuration. This log displays a collection of security-related events from all monitored Web
Applications.

Best Practices
Notes
• To view a security log for a particular Web Application, use the Security Policies view. The
Security Policies view reports security activity for the Tunnels, Hosts, and Application Paths
configured for the application.
• The Security Log tab in the Web Applications > Default Web Application node in the
Security Policies view presents the same information as the Security > Web Applications >
Default Web Application node in the Forensics view.
• The Security Log> Default View displays a composite of all events from all Web Applications
configured for the AppWall server. You can easily compare Security Logs by specific Web
Applications in the Forensics view as well.
For more information about the Security Log, see Reading a Log, page 182. The Forensics view
Reports are particularly helpful in analyzing security activity. For details on Reports, see the
Displaying Graphical Reports of Applications and Security Filters section.
Event Grouping
You can group security event into categories based on source IP address and/or Attack.
If you select to group by Attack, it groups the events by the attack threat (shown in the Events list).
To group events
1. Click Filter to open the Log Filter window.
2. In the Group by field, select IP and\or Attack.
3. Click OK.
The event log is now grouped according to the IP address and/or the attack, as you selected.
You can now click on a group to view all the events within the group and then click the Back button
to go back to the list of groups.
Accessing the Security Log in the Forensics View

Use this procedure to access the security log in the Forensics view.
To access a Security Log in the Forensics view

1. In the Forensics view, Security Log and select the Default View node. A composite Security
Log displays security events from all Web Applications. For more information on the columns in
this log, see the Security Events tab.
2. In the right pane, double-click an Event for a description and other properties.
3. Expand any other nodes in the Security Log> Web Applications node to view a Security Log
for a specific Web Application, Tunnel, Host, or Application Path.
Note: To compare Security Logs visually, see Displaying Graphical Reports of Applications and
Security Filters, page 186.

Best Practices
Quick-Click Refinements From the Security Log

You can change a Security Filter’s definition directly from a Security Log. By accessing the log entry
and invoking the Refine function, the entry is appended to the Security Filter’s Refinements page.
The following procedure describes how to refine a Security Filter in the Forensics view.
This procedure describes how to perform Quick-Click Refinements from the Forensics view. You can
also set refinements from the Security Policies view.
1. In the Forensics view, open Security Log and select the Default View node.
Note: Only events that display the quick-click icon can be refined. Events without a quick-click
icon have already been refined or have no Quick-Click Refinement configuration.
2. In the right pane, double-click an Event to display its Event Log Properties dialog box.
3. Click Refine to display the Refinements page.
4. On the Refinements page, check the fields specifying the refinement and click OK.The filter is
automatically saved.
Note: You can also perform policy refinements in a Cluster node using the Refine! button in
the Forensics view. This refinement is sent to the Cluster Manager server, and then shared
among all AppWall servers in the Cluster.
Handling Undefined Requests with Quick-Click Refinement

Undefined requests that cannot be routed to a Security object generate Security events. To avoid
filling your Security Log with this type of event, you can use the Quick-Click Refinement feature to
tell the AppWall server to ignore these requests.
This feature can be accessed either through the Configuration view or Security Policies view.
Refinement for Parsing Events

This option enables you to refine HTTP parsing from Security Events.
To refine parsing events

> Click Refine! when selecting an HTTP parsing event. This adds a new URL related rule to the
HTTP Parsing properties.
Displaying Graphical Reports of Applications and Security Filters

In the Dashboard view, you can refer to graphical reports when analyzing various aspects of your
Web Application security policy.
From the Dashboard view, you can access three types of security reports. Each report is a graphical
pie chart that shows the distribution of security events.

Best Practices
Table 75: Types of Security Reports
Groups Objects
Events by Applications Shows the distribution of security breaches occurring on each Web
Application, relative to other Web Applications. The information box
displays the name of the Web Application, the number of events and
the percentage rate of all events by Application.
Events by Filters Shows the distribution of security breaches arrested by each Security
Filter, relative to other Security Filters. The information box displays the
name of the filter, the number of events and the percentage rate of all
events by filter.
Events per Application Contrasts the Security Filters of an application you select, showing the
distribution of invalid requests received for each Security Filter. The
information box displays the name of the filter, the number of events
and the percentage rate of all events per Application.
The Events by Applications report shows the distribution of Invalid Requests grouped by Web
Application. This report enables you to see the proportional number of invalid requests for the entire
Web Application in a graphical pie chart. It can be used to identify which Web Application receives
the most invalid requests (multiple invalid requests may be an indication that the application has
been targeted by a hacker).
Viewing Security Events by Applications

Use this procedure to view security events by application.
To view security events for all Web Applications combined

1. In the Forensics view, open Reports.
2. Select Events by Applications. The Events by Applications pie chart displays.

Best Practices
Viewing Security Events by Filters

The Events by Filters report shows the distribution of invalid requests per Security Filter. This report
enables you to see which segments of attempted breaches most commonly occur on a local or
remote AppWall server.
To view security events by Security Filters

1. In the Forensics view, select Reports.
2. Select Events by Filters. The Events by Filters pie chart displays.
Viewing Security Events per Application

The Events per Application report enables you to choose a Web Application and view the distribution
of invalid requests by Security Filter. By identifying which Security Filters receive the greatest
number of invalid requests, you can gain an understanding of hacker attempts, configurations, and
possible required refinements. Included in this chart are invalid requests that failed HTTP
normalization.
To view Security Filter-related events for a specific Web Application

1. In the Forensics view, select Reports.
2. Select Events per Application and, if there is more than one Web Application, select Web
Application from the drop-down menu. The Events per Application pie chart displays.

Best Practices
APSolute Vision Reporter

To get reports on these events, see APSolute Vision Reporter, page 82.
Hiding Sensitive Content Parameters

Masking values of sensitive parameters (for example, passwords, credit card and social security
details)
In order to activate this functionality for an additional parameter, in the Configuration view, select
Events > Security Event Logs > Security Log and select the Sensitive Parameters tab.
By default the AppWall would hide parameter names ‘password’, 'passwd', 'ccn', 'ssn', ’pin’, and
‘ConfirmNewPassword’.
In a scenario where the Database Security Filter or Vulnerabilities security filter blocked a request
and generated a security event because of parameter value violation, the pattern contained in the
parameter value which was detected as the attack pattern will be shown while the rest of the
parameter value will be masked.
The purpose of showing the value is to provide the security administrator with the relevant
information for identification of legitimate request or rejection of an attack. Parameter values which
triggered other types of violations (for example, type or size range violation of parameters detected
by Parameters Security Filter), will be completely masked.
Transaction ID
Each http transaction, for which an event (of any type) was generated, will be assigned with an
unique ID. This UID will be added to the event log.

Best Practices
Transaction IDs are added to hidden parameters and are useful in tracing security events. When
violations are identified, the transaction ID is sent back in the response.
Events can be filtered by clicking the Filter button in the Forensics view by the Transaction ID to
identify the event generate for a specific HTTP transaction.
Working with the Dashboard

The Management Application Dashboard provides a perspective of the entire AppWall workplace. It
allows you to:
• Watch current network activity to and from the Web server.
• View network activity pictorially, as a graph.
Selecting AppWall in the Dashboard view provides its network statistics in the Dashboard tree.
The following is a rundown of the five tabs of the Dashboard view. Each tab is explained in detail in
the following pages.
• Summary—The Summary tab provides a summary of all information related to AppWall . It
provides the Properties, Administrative Events, Activity, and Violations related to AppWall .
Note: Clicking on the View Details button in any of the different topics opens the relative tab
(only after the user is logged in).
• Properties—The Properties tab includes the Details, Group and Cluster, and Tunnels.
• AppWall Activity—This tab provides the Status Details, Current Activity, and Resource Usage of
AppWall.
• Tunnels—This tab provides the user with tunnel information and the current activity of the
tunnels.
Summary Tab
From the Dashboard view, you can view connection details, general information, security events and
violations for the AppWall as described below.
The Summary tab is divided into the following sections:
• Properties — Provides information such as the name and IP address of the AppWall, as well as
the number of tunnels defined for AppWall.
• Administrative Events—Provides information such as the time frame for administrative
system events, and the number of logged Security Violation, Escalation, and System events.
• Security Violations—Provides information such as the time frame for Security Violation events
that occurred in the system and the number of Security Violation events for each Web
Application configured in AppWall Management Application.
Properties Tab
The Dashboard view Properties tab provides details about the selected AppWall and details of any
associated tunnels.

Best Practices
Figure 31: Properties Tab
AppWall Activity Tab

The AppWall Activity tab provides details about the AppWall current status and the current activity of
the Management Application. Note that in the Current Activity pane the current activity information
is arranged in a table presenting the following information:
• Scale—All activity information will be scaled to fit the graph display. For example, if the number
of Active Connections is 30, the scale will display 1. If the number of Active Connections is 300,
the scale will display 0.1. This setting cannot be configured.
• Current—The current quantity of the activity.

Best Practices
Figure 32: AppWall Activity Tab
Tunnels Tab
The Dashboard view Tunnels tab provides details about the tunnels configured for AppWall.

Best Practices
Figure 33: Tunnels Tab
By default, the Graph displays only information about the AppWall active connections. Note that you
must initialize a tunnel before you can view its data in a graph. You can modify the settings to view
other types of data as well:
• Pending connections per tunnel
• Active connections per tunnel
• Connection rate per tunnel
• Transaction rate per tunnel.
To add or remove a data series to a graph

1. In the Dashboard view, under the Current Activity pane, click Modify. The Add or Remove
Graphs dialog box displays.
2. Select or deselect the name of the data-series to graph and click OK. The graph refreshes,
reflecting these changes.

Best Practices

CHAPTER 6 – ADDITIONAL
CONFIGURATION OPTIONS
This section describes advanced configuration options that can be applied after you have set up your
initial configuration (as described in earlier sections).
• Distributing an AppWall Tunnel Policy to other AppWalls, page 195
• IP Blocking, page 196
• Signature Update Service (SUS), page 198
• Managing Security and Escalation Events Settings, page 198
Distributing an AppWall Tunnel Policy to other AppWalls

Use the Policy Distribution wizard to export or import an AppWall tunnel policy.
This section describes how to use the Policy Distribution wizard to perform these tasks.
To export a tunnel configuration to a file

1. In the Configuration view, right-click the AppWall server that contains the configuration files you
want to export from, and select Policy Distribution.
2. When the Policy Distribution wizard appears, click > to begin.
3. In the Options dialog box, choose Export to a File, and click >.
4. In the Tunnel to Export dialog box, select the tunnel from which to copy the configuration.
Choose the tunnel to be exported from the Available Tunnels drop-down list.
5. Select if you want to Include Auto-Policy Generation Settings, and click >.
6. In the Export Destination Settings dialog box, enter a file name to create and a description of
the file to where the exported configuration will be written.
7. Select if to export the file to a local machine, and click >.
8. A Save As window will appear. Browse and select the location to save the file, and click Save.
9. The Policy Distribution Wizard has completed, click Close.
To import a server configuration from a file

1. In the Configuration view, right-click the target AppWall server to where you would like to import
the tunnel configuration and select Policy Distribution.
2. When the Policy Distribution wizard appears, click > to begin.
3. In the Options dialog box, choose Import from a File, and click >.
4. In the Import from a File dialog box, select to import from a file location on the local machine
and enter the file name.
5. Click File Location and browse and select the file to import, and click Open
6. In the Properties to Import dialog box, select the property groups to be imported and click >:

Additional Configuration Options
— Communication Properties
— HTTP Properties
— Security Properties
— Import Global Configuration
— Create a Unique Web Application Name
7. In the Import to Tunnel dialog box, from the Available Tunnels drop-down list, select an existing
tunnel to be overwritten with the selected properties.
8. In the Backup Target Server dialog box, select if to backup the gateway configuration and enter
a backup directory name, and click >. This is a recommended precautionary backup that will be
available for restore operations.
9. The Policy Distribution Wizard has completed, click Close.
Working with AppWall Services

AppWall Management Application Services allows you to change configuration settings for the
Services provided with AppWall.
Table 76: Service Descriptions
Service Description
Publisher Lets you configure the AppWall servers that are accepted by the
publisher server, including Allow and Deny lists.
CDN Support Lets you configure the CDN support.
IP Blocking Lets you configure the IP address allow/block service. See IP Blocking,
page 196 for further information.
IP Blocking
AppWall provides two basic types of IP Blocking:
• User defined IP addresses—IP addresses manually entered as always blocked or always
allowed.
• Automatic IP blocking—IP addresses blocked based on security history.
Support for IPv6 for Web Traffic Processing

When configuring IPv6 settings, AppWall for Alteon processes the IPv6 traffic and, depending on its
configuration, extracts the IPv6 source address from the Layer 3 source header, or the HTTP (Layer
7) XFF (X-FORARDED-FOR), the True-Client-IP or from other headers. Security polices can be
applied on IPv6 addresses (for example, IP blocking) with the exception of Brute Force and Session
Security Filters, and geo-location policies that do not support IPv6 addresses.
Configuring IP Blocking
Use this procedure to configure IP blocking.

To configure IP blocking
1. In the Configuration view, expand Services and select IP Blocking.
2. Complete the fields in the Configuration tab as described in the table below.
Table 77: IP Blocking Configuration Parameters
Enable Click to enable or disable IP blocking.
Listening Port If you selected to integrate the IP blocking feature with CheckPoint’s FireWall-
1 application, the listening port for the firewall is pre-filled.
Change the listening port if necessary.
3. Complete the fields in the Penalty Score tab as described in the table below.
Table 78: IP Blocking Penalty Score Parameters
Security Score / IP blocking gives suspect IP addresses security level from Level 1, a low
Penalty Time security threat, to Level 3, a high security threat.
You can edit the amount of time, in minutes, that the firewall blocks IP
addresses that belong to each security level.
4. Complete the fields in the Always Block/Never Block tab as described in the table below.
Table 79: IP Blocking Always/Never Block Parameters
Always Block These Note: Use Add, Edit, and Remove to edit the list of IP addresses that
IPs should always be blocked. Each IP address can also have a description of
why it has been blocked.
Never Block These Note: Use Add, Edit, and Remove to edit the list of IP addresses that
IPs should never be blocked. Each IP address can also have a description of
why it is always allowed.
5. Click Submit and Save, and on the AppWall Management Application toolbar click Apply .
Managing Blocked IP Addresses

AppWall enables you to check all IP addresses that have actually been blocked, either manually or
automatically, and allows you to manually unblock them.
To manage blocked IP addresses

1. In the Configuration view, expand Services and select IP Blocking.
2. The Blocked IPss tab contains a list of all IP addresses that have been blocked.

Table 80: Blocked IP address Parameters
IP The blocked IP address.
Blocked Until The date and time until which the IP address has been blocked.
3. Right-click the IP address in the list if you want to:
— always block this IP address
— never block this IP address
— unblock this IP address.
Signature Update Service (SUS)

AppWall supports an auto-update service for attack signatures and geo-location data, through its
website at: http://www.radware.com.
Every registered device with an SUS license is entitled to the signature update service. You can set
scheduled checks for new updates, or manually check on demand.
Every update includes a short description of the updates available with the new version.
All past and current updates supported for the device version are displayed and can be installed,
enabling rollback to previous versions.
Auto-update service options include: Check Only and Check and Install.
Customers with an AppWall version prior to 7.5.7 will have to upgrade to a later version in order to
receive the signature updates.
Customers without a valid SUS license will not be able to install new updates, will remain with their
latest signature database, and will not be able to use the geo-location database with role-based
policies.
Managing Security and Escalation Events Settings

The Security and Escalation Events Settings node allows you to:
• Enable or disable logging and publishing for security events. The list of all events is known as
the “Event Map”.
• Manage publishing rules, which are rules that define where to notify in the case of a security
event.
• Manage severity level rules, which are rules that assign or change the severity level of all events
for specified parts of the system, such as tunnel or database system events.
• Change the file size and archiving rules for event logs.
• Define Escalation rules, which are a set of rules that escalate the state of a server or tunnel.
(Escalation is deployed to automatically turn on filtering for a server or tunnel that has not used
Security Filters actively.) (Only for Security Violation events).
This section includes the following topics:

• Managing the Event Map
• Managing Severity Rules
• Managing Publishing Rules
• Managing Log Files

Managing the Event Map

You can enable or disable logging or publishing for each type of security event by making the
changes in the Event Map.
To change the Event Map

1. In the Configuration view, select Events > Security Events Log > Security Log.
2. Click the Event Map tab. A list of all defined events displays. A description of each column in the
list appears in the table below.
3. Double-click an event. A dialog box appears.
4. Select to enable or disable logging or publishing in the dialog box and click OK.
Table 81: Event Map Fields
Field Description
Severity Level The severity level assigned to the event. (read only)
Title A short description of the event. (read only)
Enable Log A check mark appears if logging is currently enabled for this event.
Enable A check mark appears if publishing is currently enabled for this event.
Publishing
You can also activate the event aggregation for the security logs. The "events aggregation"
will aggregate all the identical consecutive events. You can configure the number of events to
see before aggregation. An event is "identical" when the title and the description of the
consecutive events are identical.
Managing Severity Rules

You can create severity rules that will change the severity level of any event based on the severity
and source of the event. This might be useful if you would like to create a uniform severity level
when, for example, any database related event occurs.
To manage severity rules

2. Click the Severity Rules tab. A list of all defined severity rules displays. A description of each
column in the list appears in Table 82 - Severity Rules Tab Fields.

Table 82: Severity Rules Tab Fields
Field Description
Name The name of the rule.
Generated By The required generating source and the associated source type of the security
violation to trigger this rule. If the Source Type is “Filters”, the Source is a
specific Security Filter, or all Security Filters.
If the Source Type is “Sub Systems”, the Source is a specific sub system, or all
sub systems. The sub systems are: Administration, Application Path, Application
Session, Certificate Manager, Escalation, Event Log, Filters, IP Blocking, License
Manager, Publisher, Resource Manager, SSL, System Manager, Tunnels, or Web
Applications.
If the Source Type is “System”, this field remains blank. If the Source Type is
“Tunnels”, the Source is a specific tunnel, or all tunnels.
If the Source Type is “Web Applications”, the Source is a specific Web Application,
or all Web Applications. Possible values for Source Type are: Filters, Sub System,
System, Tunnels, Web Applications.
Web Application The Web application to which the rule is associated.
Tunnel The tunnel to which the rule is associated.
Host The host to which the rule is associated.
Application Path The Application Path to which the rule is associated.
Severity Level The new Severity Level setting for events that match the rule.
3. Click Add to add a new rule, or double-click a rule to edit the rule. An Add/Edit Severity Rule
dialog box displays with two tabs, Rule Condition and Rule Actions.
4. In the Rule Condition tab, enter the name and required originating source of the event to trigger
this severity rule. Refer to Table 82 - Severity Rules Tab Fields for details.
5. In the Rule Actions tab, select the new severity level according to the options described in Table
83 - Rule Actions Fields, below.
Table 83: Rule Actions Fields
Field Description
Set Fixed Specify the exact severity level to which you want to apply to the event.
Severity Level
Increase Select the number of steps by which to raise the severity level for this event.
Severity Level There are five severity levels, from “Lowest” to “Critical”.
by
Decrease Select the number of steps by which to decrease the severity level for this event.
Severity Level There are five severity levels, from “Lowest” to “Critical”.
by
Exit on Success Select this option if you want to prevent any further Severity Rules settings
processing of this event by AppWall.
6. When you are finished, click OK.
7. Click Submit and Save in the AppWall Security Management Application Content area.

Managing Publishing Rules

AppWall provides a number of different options for invoking actions or sending notification after an
event has triggered. Events may be published using SNMP, SMTP, SysLog, or ODBC. Events can also
trigger a specified program to run, and can be logged into a log file.
You can create publishing rules according to ranges of severity levels and the source or generator of
the event.
To manage publishing rules

2. Click the Publishing Rules tab. A list of all defined publishing rules displays, if any. A description
of each column in the list appears in Table 84 - Managing Publishing Rules, below.
Table 84: Managing Publishing Rules
Field Description
Name The name of the rule.
Severity Level The severity level, or the range of severity levels, that can trigger this rule.
Generated By The required generating source of the security violation to trigger this rule and
its associated source type. If the Source Type is “Filters”, the Source is a specific
Security Filter, or all Security Filters.
If the Source Type is “Sub Systems”, the Source is a specific sub system, or all
sub systems. The sub systems are: Administration, Application Path, Application
Session, Certificate Manager, Escalation, Event Log, Filters, IP Blocking, License
Manager, Publisher, Resource Manager, SSL, System Manager, Tunnels, or Web
Applications.
If the Source Type is “System”, this field remains blank. If the Source Type is
“Tunnels”, the Source is a specific tunnel, or all tunnels.
If the Source Type is “Web Applications”, the Source is a specific Web Application,
or all Web Applications. Possible source types are: Filters, Sub System, System,
Tunnels, Web Applications
Web Application The Web Application to which the target object is associated.
Tunnel The tunnel to which the target object is associated.
Host The host to which the target object is associated.
Application Path The Application Path to which the target object is associated.
3. Click Add to add a new rule, or double-click a rule to edit the rule. An Add/Edit Publishing Rule
dialog box displays with two tabs, Rule Condition and Rule Actions.
4. In the Rule Condition tab, enter the name of the rule, required severity levels, and required
source and target of the event to trigger this publishing rule, as required. Refer to Table 84 -
Managing Publishing Rules for details.
5. In the Rule Actions tab, enter the fields according to Table 85 - Rule Actions Tab Fields, below.

Table 85: Rule Actions Tab Fields
Field Description
Run this When enabled, enter the path to an application that you want to run when this
Program on event triggers.
AppWall
Send a Network Sends an instant message.
Message to
Note: This setting requires NetBEUI and Messenger installed on both the
server and the system that is the target of the message.
Send an SNMP Sends an SMTP trap. An icon appears with the object status. Possible values are:
trap Enable, Disable.
Enable and Disable values are relevant for all fields from “Send an SNMP trap” to
“Send an Email message To”.
Send a SysLog Sends a SysLog notification.
Notification
Send Using an Sends using an ODBC event.
ODBC
Send an Email Sends an email message to the specified recipient
Message To
6. When you are finished, click OK.
7. Click Submit and Save in the AppWall Management Application Console Content area.
Managing Log Files

You can change the behavior and location of the event log files.
To manage log files

2. Click the File Settings tab.
3. Enter new information into the fields according to Table 86 - Managing Log Files.
Table 86: Managing Log Files
Field Description
Enable Enables or disables logging.
File Location A relative path to the location of the log file (read only)
File Size Limit Indicates that the current log file should be archived after reaching this
size in Kb.
Current File Size A read-only field indicating the current size of the log file.
Maintain All Files Archive files are stored indefinitely.
Archive
Limit Archive to __ files Indicate the number of archive files to preserve. Older files will be
removed when a new archive file is created.
Request Data Settings - settings for request data files storage and archive control

Table 86: Managing Log Files (cont.)
Field Description
Request Dir Where requests are stored, for example ./Event/Requests
Request Log Limit Maximum number of requests that can be logged in Bytes
Request File Limit Maximum number of file requests in Kb
Request Folder Limit Maximum number of request folders in Mb
Events
AppWall includes an Events subsystem that allows you to change severity setting names, edit event
map properties, create publishing, escalation, and severity rules, and manage log file settings.
Severity Settings
AppWall assigns one of five severity settings to each event:
• Lowest—such as the system starting up.
• Low—such as system shutting down.
• Medium—such as inability to write data to a file.
• High—such as failure to upload a data file.
• Critical—such as failure to initialize the system or security events.
You can change the names of each of these severity settings.
Changing Severity Setting Names

Use this procedure to change the severity setting names.
To change the severity setting names

1. In the Configuration view, select Events > Severity Settings.
2. Double-click a severity setting, enter a new name for the setting, and click OK.
3. Click Submit and Save to save your changes.
4. To restore the default setting names, click Restore and Save.
Administration Events Logs

The Administration Events Settings tab provides the same functionality for administration events as
described for security related events in Managing Security and Escalation Events Settings. The
events you can manage in these nodes include:
• Administration—Events related to the AppWall Management Application as well as login
attempts.
• System—Events related to background server functionality, such as updates, renewing
certificates, and managing the request queue.
• Initialization—Events related to the system services starting and stopping.
Notes
• Each of these event types has its own unique log file.

• Unlike for the other event types, for initialization events you cannot define severity rules or
publishing rules, and you cannot change the location or functionality of the initialization event
log.

APPENDIX A – TROUBLESHOOTING
This appendix lists some of the common issues that you may encounter when working with AppWall.
It contains the following sections:
• General Issues, page 205
• Filters and Configuration Issues, page 205
General Issues
This section provides solutions to general AppWall issues.
How Do I Backup the Auto Discovery Tree?

When you backup the policy you should be aware that your Auto Discovery tree is not included. If for
any reason you wish to backup the Auto Discovery tree you can manually backup the ADserial.dat
file, which is located in the \AppWall Gateway\Config\State folder.
To restore the backup

1. Resume Auto Discovery.
2. Click Apply .
3. Stop the Gateway.
4. Copy the file and then start the Gateway.
Filters and Configuration Issues

This section details some common filter and configuration issues that you may encounter.
It contains the following topics:
• What is a SafeReply Security Filter? Why do I need it?, page 205
• Do I need the SafeReply Filter on every Application Path?, page 206
• Where else should I use the Brute Force Filter other than the login page?, page 206
• How can I read old AppWall events?, page 206
What is a SafeReply Security Filter? Why do I need it?

The SafeReply Security Filter prevents information leakage of data such as credit card number
(CCN), social security numbers (SSN) and other custom patterns that you define as sensitive.
If for some reason the information is leaked, the AppWall can replace the numbers with an X or
display the Security page.

Troubleshooting
Do I need the SafeReply Filter on every Application Path?

You should use the SafeReply Filter only on Application Paths with files that are defined as sensitive;
for example, Application Paths that contain files such as .asp, and .aspx are more sensitive than
Application Paths that contain images.
Where else should I use the Brute Force Filter other than the login page?
You should use the Brute Force Filter on each page you want to prevent systematic attacks, such as
a credit card guesswork page, or where you want to prevent "Contact us" forms of attack.
How can I read old AppWall events?

The easiest way to read old events is to put the EventViewer.exe (located in the AppWall Support
folder (\Radware\AppWall Gateway\Support)) in a temporary folder, copy the events files to the
same folder and remove the numbering suffix of the event files. Then run the Event Viewer.
For example, if you have system logs "System.idx.1148894607" and "System.idx.1148894607", you
need to do the following:
1. Copy EventViewer.exe to C:\temp
2. Copy the system logs (.log and .idx) to C:\temp
3. Rename System.idx.1148894607 to System.idx.
4. Rename System.log.1148894607 to System.log.
5. Run the EventViewer.exe.

APPENDIX B – REGULAR
EXPRESSIONS
This section provides information on how to use Regular Expressions within the AppWall application.
It includes the following topics:
• Quick Reference Table, page 207
• Escaping RegEx, page 208
• Regular Expression Syntax, page 208
Quick Reference Table

The following table provides a quick reference of RegEx operations you can use to create a regular
expression.
Table 87: RegEx Quick Reference
RegEx Quick Reference

Operators . ^ $ * + ? { [ \ |(
Matches any digit character [0-9] or \d
Matches any non-digit character [^0-9] or \D
Matches any whitespace character [ \t\n\r\f\v] or \s
Matches any non-whitespace character [^ \t\n\r\f\v] or \S
Matches any alphanumeric character [a-z A-Z 0-9_] or \w.
Matches any non-alphanumeric character [â-z A-Z 0-9_] or \W
Note: Expressions
Table 88: Expressions and Results
EXP Result EXP Results

A.A Yes: AaA, AbA, A1A, BA{2,4} Yes: BAA, BAAAA
A5A No: Baa, BA, BAAAAA
No: AA, AabA
[â12]* Yes: b34, fbc, xxx [ABC12de] Yes: A, C, 1, e
No: a12, a, 1, 2 No: ABC12de,z, E
\d Yes: 1, 9 D+\x41 Yes: DA
No: a, b, c (\x hexadecimal) No: D6, D\65, Da
A*d Yes: AAd, AaaAd, d \* Yes: *
No: abd, aaaa No: \*, \
A+R Yes: AAr, AR, AAAAR a(b|c) Yes: ab,ac
No: AAAA, Abr, R No: ad, a, ABC
(\S*|\s*)D Yes: AD, 12frD, f_DD \S*\@\S*\.\D* Yes:mail@xx.com
No: AAAA, 12frd, 112/D No: mail@xxaaa

Regular Expressions
Escaping RegEx
A number of components use RegEx. This adds a great deal of power in creating patterns.
In order for RegEx to offer this powerful feature, it uses several operators. If these operators, . ^ $*
+ ? { [ \ |, occur in a text string and you do not want them treated as RegEx operators, you must
escape them when RegEx functionality is enabled.
A RegEx that provides a list of folders with folder “.5” escaped.

Escaping RegEx operators is relatively simple; precede any special character with the backslash
character \. This lets RegEx know that the character that follows should be treated as text (literals).
Note:
A directory /Archive/ contains the following subfolders:

"/2000Archive_Ce105.101a/
"/2000Archive_Ce105.101b/
"/2000Archive_Ce108.501a//
"/2000Archive_Ce105.451za/
"/2000Archive_Ce125.500a/
You could define a RegEx Application Path that covers all archive folders whose last section of
numbers begins with 5.
There are multiple ways in which you could specify these paths; however failure to escape
characters that need to be treated as literals (text) can have adverse effects.
The following RegEx fails to escape the period before them for parsing the last section:
/2000Archive_(.*).5(.*)/
The user intended that the period before the 5 be treated as a literal but because the period was not
escaped the RegEx treats it as a wildcard character. Instead of getting the desired effect, it matches
every folder listed above.
To correct the RegEx so that it will only select folders 2000Archive_Ce108.501a and
2000Archive_Ce125.500a the “\” operator needs to be added prior to the period that needs to be
treated as a literal. The following is the correct way to escape the period preceding the last section
of numbers which we want to begin with a five.
/2000Archive_(.*)\.5(.*)/
Regular Expression Syntax

This section contains excerpts from Dr. John Maddock's documentation of the Regex++ Library used
in AppWall:
Copyright Notice for RegEx++ Library Copyright© 1998-2001 Dr. John Maddock.

Regular Expressions
Permission to use, copy, modify, distribute and sell the Regex++ library 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. Dr. John Maddock makes no representations about the suit-ability of the
Regex++ library software for any purpose. It is provided “asis” without express or implied warranty.
Literals
All characters are literals except: “.”, “*”, “?”, “+”, “(“, “)”, “{“, “}”, “[“, “]”, “^”, “$” and “\”. These
characters are literals when preceded by a “\”. A literal is a character that matches itself.
Wildcard
The dot character “.” matches any single character.
Repeats
A repeat is an expression that is repeated an arbitrary number of times. An expression followed by
“*” can be repeated any number of times including zero. An expression followed by “+” can be
repeated any number of times. All repeat expressions refer to the shortest possible previous sub-
expression: a single character; a character set, or a sub-expression grouped with “()” for example.
• “ba*” will match “b”, “ba”, and “baaa”
• “ba+” will match “ba” and “baaaa” but not “b”
• “ba?” will match “b” or “ba”
• “ba{2,4}” will match “baa”, “baaa” and “baaaa”
Non-Greedy Repeats
Non-greedy repeats are possible by appending a '?' after the repeat; a non-greedy repeat is one
which will match the shortest possible string.
For example, to match HTML tag pairs one could use something like:
“<\s*tagname[^>]*>(.*?)<\s*/tagname\s*>”
In this case $1 will contain the text between the tag pairs, and will be the shortest possible matching
string.
Parenthesis
Parentheses serve two purposes, to group items together into a sub-expression, and to mark what
generated the match. For example the expression “(ab)*” would match all of the string “ababab.” It
is permissible for sub-expressions to match null strings. If a sub-expression takes no part in a match
- for example if it is part of an alternative that is not taken - then both of the iterators that are
returned for that sub-expression point to the end of the input string, and the matched parameter for
that sub-expression is false. Sub-expressions are indexed from left to right starting from 1, sub-
expression 0 is the whole expression.
Non-Marking Parenthesis
Sometimes you need to group sub-expressions with parenthesis, but don't want the parenthesis to
spit out another marked sub-expression, in this case a non-marking parenthesis (?:expression) can
be used. For example the following expression creates no sub-expressions:
“(?:abc)*”

Regular Expressions
Forward Look-Ahead Asserts

There are two forms of these; one for positive forward look-ahead asserts and one for negative look-
ahead asserts:
“(?=abc)” matches zero characters only if they are followed by the expression “abc.”“(?!abc)”
matches zero characters only if they are not followed by the expression “abc.”
Alternatives
Alternatives occur when the expression can match either one sub-expression or another, each
alternative is separated by a “|”. Each alternative is the largest possible previous sub-expression;
this is the opposite behavior from repetition operators.
Note:
“a(b|c)” could match “ab” or “ac.”

“abc|def” could match “abc” or “def.”
Sets
A set is a set of characters that can match any single character that is a member of the set. Sets are
delimited by “[“and “]” and can contain literals, character ranges, character classes, collating
elements and equivalence classes. Set declarations that start with “^” contain the compliment of the
elements that follow.
Character literals
“[abc]” will match either of “a”, “b”, or “c.”“[âbc]” will match any character other than “a”, “b”, or
“c.”1.4.9.1Character ranges:“[a-z]” will match any character in the range “a” to “z.”“[Â-Z]” will
match any character other than those in the range “A” to “Z.”
Note: Character ranges are highly locale-dependent: they match any character that collates
between the endpoints of the range. Ranges will only behave according to ASCII rules.
Character classes are denoted using the syntax “[:classname:]” within a set declaration, for
example “[[:space:]]” is the set of all whitespace characters. The available character classes are as
follows:
Table 89: Character Classes
Class Description
Alnum Any alpha numeric character.
Alpha Any alphabetical character a-z and A-Z. Other characters may also be
included depending upon the locale.
Blank Any blank character, either a space or a tab.
Cntrl Any control character.
Digit Any digit 0-9.
Graph Any graphical character.

Regular Expressions
Table 89: Character Classes (cont.)
Class Description
Lower Any lower case character a-z. Other characters may also be included
depending upon the locale.
Print Any printable character.
Punct Any punctuation character.
Space Any whitespace character.
Upper Any upper case character A-Z. Other characters may also be included
depending upon the locale.
Xdigit Any hexadecimal digit character, 0-9, a-f and A-F.
Word Any word character - all alphanumeric characters plus the underscore.
Unicode Any character whose code is greater than 255, this applies to the wide
character traits classes only.
Collating elements take the general form [.tagname.] inside a set declaration, where tagname is
either a single character, or a name of a collating element, for example [[.a.]] is equivalent to [a],
and [[.comma.]] is equivalent to [,]. The library supports all the standard POSIX collating element
names, and in addition the following digraphs: “ae”, “ch”, “ll”, “ss”, “nj”, "dz", “lj”, each in lower,
upper and title case variations. Multi-character collating elements can result in the set matching
more than one character, for example [[.ae.]] would match two characters, but note that [^[.ae.]]
would only match one character.
Equivalence classes take the general form [=tagname=] inside a set declaration, where tagname is
either a single character, or a name of a collating element, and matches any character that is a
member of the same primary equivalence class as the collating element [.tagname.]. An
equivalence class is a set of characters that collate the same, a primary equivalence class is a set of
characters whose primary sort key are all the same (for example strings are typically collated by
character, then by accent, and then by case; the primary sort key then relates to the character, the
secondary to the accentuation, and the tertiary to the case). If there is no equivalence class
corresponding to tagname, then [=tagname=] is exactly the same as [.tagname.].
To include a literal “-” in a set declaration then: make it the first character after the opening “[” or
“[^”, the endpoint of a range, or a collating element. To include a literal “[“or “]” or “^” in a set then
make them the endpoint of a range, a collating element, or precede with an escape character.
Line Anchors
An anchor is something that matches the null string at the start or end of a line: “^” matches the
null string at the start of a line, “$” matches the null string at the end of a line.
Back References
A back reference is a reference to a previous sub-expression that has already been matched, the
reference is to what the sub-expression matched, not to the expression itself. A back reference
consists of the escape character “\” followed by a digit “1” to “9”. For example, “\1” refers to the first
sub-expression and “\2” to the second. The expression “(.*)\1” matches any string that is repeated
about its mid-point, for example, “abcabc” or “xyzxyz”. A back reference to a sub-expression that
did not participate in any match, matches the null string: NB this is different to some other regular
expression matchers.

Regular Expressions
Characters by Code
These characters consist of the escape character followed by the digit “0” followed by the octal
character code. For example “\023” represents the character whose octal code is 23. Where
ambiguity could occur use parentheses to break the expression up: “\0103” represents the
character whose code is 103, “(\010)3” represents the character 10 followed by “3”. To match
characters by their hexadecimal code, use \x followed by a string of hexadecimal digits, optionally
enclosed inside {}, for example \xf0 or \x{aff}, notice the latter example is a Unicode character.
Word Operators
“\w” matches any single character that is a member of the “word” character class, this is identical to
the expression “[[:word:]].”“\W” matches any single character that is not a member of the “word”
character class, this is identical to the expression “[^[:word:]].”“\<“matches the null string at the
start of a word. “\>” matches the null string at the end of the word. “\b” matches the null string at
either the start or the end of a word. “\B” matches a null string within a word.
The start of the sequence passed to the matching algorithms is considered to be a potential start of
a word. The end of the sequence passed to the matching algorithms is considered to be a potential
end of a word.
Buffer Operators
“\`” matches the start of a buffer.“\A” matches the start of the buffer.“\'” matches the end of a
buffer.“\z” matches the end of a buffer. “\Z” matches the end of a buffer, or possibly one or more
new line characters followed by the end of the buffer.
Escape Operator
The escape character “\” has several meanings.
• Inside a set declaration the escape character is a normal character.
• The escape operator may introduce an operator for example: back references, or a word
operator.
• The escape operator may make the following character normal, for example “\*” represents a
literal “*” rather than the repeat operator.
Single Character Escape Sequences

The following escape sequences are aliases for single characters:
Table 90: Single Character Escape Sequences
Escape Character Meaning

Sequence Code
\a 0x07 Bell character
\f 0x0C Form feed
\n 0x0A Newline character
\r 0x0D Carriage return
\t 0x09 Tab character
\v 0x0B Vertical tab
\e 0x1B ASCII Escape character

Regular Expressions
Table 90: Single Character Escape Sequences (cont.)
Escape Character Meaning

Sequence Code
\0dd 0dd An octal character code, where dd is one or more octal digits
\xXX 0xXX A hexadecimal character code, where XX is one or more
hexadecimal digits
\x{XX} 0xXX A hexadecimal character code, where XX is one or more

hexadecimal digits, optionally a unicode character
\cZ z-@ An ASCII escape sequence control-Z, where Z is any ASCII
character greater than or equal to the character code for '@'
Miscellaneous Escape Sequences

The following lists various escape sequences:
• \w Equivalent to [[:word:]].
• \W Equivalent to [^[:word:]].
• \s Equivalent to [[:space:]].
• \S Equivalent to [^[:space:]].
• \d Equivalent to [[:digit:]].
• \D Equivalent to [^[:digit:]].
• \l Equivalent to [[:lower:]].
• \L Equivalent to [^[:lower:]].
• \u Equivalent to [[:upper:]].
• \U Equivalent to [^[:upper:]].
• \C Any single character, equivalent to '.'.
• \X Match any Unicode combining character sequence, for example “a\x 0301" (a letter a with an
acute).
• \Q The begin quote operator, everything that follows is treated as a literal character until a \E
end quote operator is found.

Regular Expressions

APPENDIX C – CODE PAGES
Often client applications send requests that use special language characters (for example, non-
English languages) that are not encoded in lower ASCIII. Because there are many different ways in
which these characters can be encoded, AppWall needs to understand which of the many possible
encoding code pages were used.
By specifying the code page, encoded messages can be accurately converted to Unicode.
When creating a tunnel, you should specify a codepage encoding scheme to a specific code page.
This way, you inform AppWall what types of special characters are allowed in the request.
If your client application generates requests that use Western European (Windows) encoding or
converts special characters into Unicode, you need not change the Encoding Scheme setting from
the default; most US and Western European applications use “Microsoft Windows 1252 [ANSI].”
A tunnel may have only one codepage assignment. However, multiple language clients that convert
requests to UTF-8 are supported, as a fallback.
If you specify a different codepage than the default, text-normalization is done using the tunnel
codepage instead of UTF-8. Enable this setting when an HTTP request includes codepage-encoded
characters that may be mistaken for UTF-8. When disabled, UTF-8 translation is used for text-
normalization to Unicode.
If you use a language other than 1252 ANSI (US-ASCII default), the transcoding of characters may
be mistakenly applied to characters that appear to be UTF-8 encoded. This is common with Far
Eastern languages where escaped double-byte characters cannot clearly be differentiated from UTF-
8 encoding. When this ambiguity is possible with the encoded characters, it is important that this
setting is specified to prevent mistranslations.
If you are unfamiliar with the client application coding, you can try viewing the application in a
common Web browser, such as IE Explorer or Netscape, and select the Character Encoding from the
View menu of the browser. This often displays the encoding required by the Web Application.
In addition, code page information can often be found in the Meta tags of the application. The
following is an example of a code page designation in the HTML code.
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1252">
Refer to additional flags in the HTTP Properties tab, which aid AppWall in decoding requests.
Code Page Options

The following table lists the code page options available in AppWall.
Table 91: AppWall Code Page Options
Flag Description
Allow High ASCII Enabled. This enables language coding even in fields that should be only
characters English, for example, Header names, Parameter names, URIs, and so on.
Only Use Codepage Disabled. This cancels the UTF-8 stage.

Encoding for URL and
Parameters
Allow Messages with Disabled.
Parameter Value that
Fail Text Normalization
Use IIS Extended Enabled. This defends from coding problems that arise from using
Unicode Measures Unicode. That is, it corrects an accented á to a.

Code Pages
Code Description
The following lists the code page options available in AppWall.
Table 92: AppWall Code Page Options
Code Description
cp037: EBCDIC Codepage 037
cp424: IBM Hebrew (cp424)
cp437: MS-DOS Codepage 437 (US)
cp737: MS-DOS Codepage 737 (Greek IBM de facto standard)
cp775: MS-DOS Codepage 775 (BaltRim)
cp850: MS-DOS Codepage 850 (Multilingual Latin 1)
cp855: MS-DOS Codepage 855 (Russia) - obsolete
cp856: IBM Hebrew (cp856)
cp860: MS-DOS Codepage 860 (Portugal)
cp861: MS-DOS Codepage 861 (Iceland)
cp862: MS-DOS Codepage 862 (Israel)
cp863: MS-DOS Codepage 863 (Canada (French))
cp864: MS-DOS Codepage 864 (Arabic) without BOX DRAWINGS below 20
cp865: MS-DOS Codepage 865 (Norway)
cp866: MS-DOS Codepage 866 (Russia)
cp869: MS-DOS Codepage 869 (Greece)
cp874: MS-DOS Codepage 874 (Thai)
cp875: EBCDIC Codepage 875 (Greek)
cp932: MS-DOS Codepage 932 (Japanese)
cp932_Gaiji:: MS-DOS Codepage 932 (Japanese) with Gaiji support (rows 95 to 114)
0xF040 - 0xF9FC
cp936: Microsoft Windows Codepage 936 (EUC-Japanese)
cp949: Microsoft Windows Codepage 949 (Korean)
cp949_1: Modified Microsoft Windows Codepage 949_1 (Korean)
cp950:: Microsoft Codepage 950 Traditional Chinese (MS version of BIG5)
cp1026: EBCDIC Codepage 1026 (Turkish)
cp1250: Microsoft Windows Codepage 1250 (EE)
cp1251: Microsoft Windows Codepage 1251 (Cyrl)
cp1252: Microsoft Windows Codepage 1252 (ANSI)
cp1253: Microsoft Windows Codepage 1253 (Greek)
cp1254: Microsoft Windows Codepage 1254 (Turk)

Code Pages
Table 92: AppWall Code Page Options (cont.)
Code Description
cp1255: Microsoft Windows Codepage 1255 (Hebr)
cp1256: Microsoft Windows Codepage 1256 (Arab)
cp1257: Microsoft Windows Codepage 1257 (BaltRim)
cp1258: Microsoft Windows Codepage 1258 (Viet)
cp2022_jp ISO-2022-JP: Multi-Byte Japanese, RFC 1468 Codepage (jis, jis_encoding,
csjisencoding)
cp8859_1: ISOIEC 8859_1: 1998 Latin Alphabet No. 1
cp8859_5: ISOIEC 8859_5: 1999 Latin Cyrillic Alphabet
cp8859_6: ISOIEC 8859_6: 1999 Latin Arabic Alphabet
cp8859_7: ISOIEC 8859_7: 1987 Latin Greek Alphabet
cp8859_8: ISOIEC 8859_8: 1999 Latin Hebrew Alphabet
cp8859_13: ISOIEC 8859_13: 1998 Latin Alphabet No. 7 (Baltic Rim)
cp8859_14: ISOIEC 8859_14: 1998 Latin Alphabet No. 8 (Celtic)
cp8859_16: ISOIEC 8859_16: Latin alphabet No. 10
cp10000: Macintosh Roman
cp10006: Macintosh Greek
cp10007: Macintosh Cyrillic
cp10029: Macintosh Latin 2
cp10079: Macintosh Iceland
cp10081: Macintosh Turkish
cpkoi8_r: koi8-r (Russian U*IX encoding, also used by RELCOM)
cpbig5BIG5: Single/Dual-Byte Traditional Chinese
cpbig5_2003:: Extended (and modified) BIG5 Traditional Chinese
cpgb2312:: Single/Dual-Byte Chinese National Standard, Codepage (EUC-CN, EUCCN,
CSGB2312, CN-GB)
cpgbk: Single/Dual-Byte Simplified Chinese Codepage (CN-GBK)

Code Pages

APPENDIX D – HTTP STATUS CODES
The following table provides a list of HTTP response codes that appear in the HTTP structure.
Table 93: HTTP Status Codes
Response Code Response Code

“100” Continue “101” Switching Protocols
“200” OK “201” Created “202” Accepted
“203” Non-Authoritative Information “204” No Content
“205” Reset Content “206” Partial Content
“300” Multiple Choices “301” Moved Permanently
“302” Found “303” See Other
“304” Not Modified “305” Use Proxy
“307” Temporary Redirect “400” Bad Request
“401” Unauthorized “402” Payment Required
“403” Forbidden “404” Not Found
“405” Method Not Allowed “406” Not Acceptable
“407” Proxy Authentication Required “408” Request Time-out
“409” Conflict “410” Gone
“411” Length Required “412” Precondition Failed
“413” Request Entity Too Large “414” Request-URI Too Large
“415” Unsupported Media Type “416” Requested Range not Satisfiable
“417” Expectation Failed “500” Internal Server Error
“501” Not Implemented “502” Bad Gateway
“503” Service Unavailable “504” Gateway Time-out
“505” HTTP Version not supported

HTTP Status Codes

APPENDIX E – EXTRACTING ORIGINAL
SOURCE IP ADDRESS FROM AN HTTP
HEADER
In order for AppWall to process the original client IP address and not to use the TCP connection
source IP address (in cases there are Reverse Proxies in front of AppWall), AppWall can be
configured to extract the IP address from the X-Forwarded-For header or any other configurable
header (for example, TrueIP).
AppWall uses the excreted IP address for IP address presentation in security event logs, in learning
and Auto Policy Generation and for Session Security filter IP address enforcement, and for IP-based
policies.
In order to activate this front-end functionality, in the Configuration View, Services Internal
Parameters tab, in the Get User IP from HTTP Header field, enter the name of the HTTP header
from which to retrieve the client IP.
Support for IPv6 for Web Traffic Processing

When configuring IPv6 settings, AppWall for Alteon processes the IPv6 traffic and, depending on its
configuration, extracts the IPv6 source address from the Layer 3 source header, or the HTTP (Layer
7) XFF (X-FORARDED-FOR), the True-Client-IP or from other headers. Security polices can be
applied on IPv6 addresses (for example, IP blocking) with the exception of Brute Force and Session
Security Filters, and geo-location policies that do not support IPv6 addresses.

Extracting Original Source IP Address from an HTTP Header

RADWARE LTD. END USER LICENSE
AGREEMENT
By accepting this End User License Agreement (this “License Agreement”) you agree to be contacted
by Radware Ltd.'s (“Radware”) sales personnel.
If you would like to receive license rights different from the rights granted below or if you wish to
acquire warranty or support services beyond the scope provided herein (if any), please contact
Radware's sales team.
THIS LICENSE AGREEMENT GOVERNS YOUR USE OF ANY SOFTWARE DEVELOPED AND/OR
DISTRIBUTED BY RADWARE AND ANY UPGRADES, MODIFIED VERSIONS, UPDATES, ADDITIONS,
AND COPIES OF THE SOFTWARE FURNISHED TO YOU DURING THE TERM OF THE LICENSE
GRANTED HEREIN (THE “SOFTWARE”). THIS LICENSE AGREEMENT APPLIES REGARDLESS OF
WHETHER THE SOFTWARE IS DELIVERED TO YOU AS AN EMBEDDED COMPONENT OF A RADWARE
PRODUCT (“PRODUCT”), OR WHETHER IT IS DELIVERED AS A STANDALONE SOFTWARE PRODUCT.
FOR THE AVOIDANCE OF DOUBT IT IS HEREBY CLARIFIED THAT THIS LICENSE AGREEMENT
APPLIES TO PLUG-INS, CONNECTORS, EXTENSIONS AND SIMILAR SOFTWARE COMPONENTS
DEVELOPED BY RADWARE THAT CONNECT OR INTEGRATE A RADWARE PRODUCT WITH THE
PRODUCT OF A THIRD PARTY (COLLECTIVELY, “CONNECTORS”) FOR PROVISIONING,
DECOMMISSIONING, MANAGING, CONFIGURING OR MONITORING RADWARE PRODUCTS. THE
APPLICABILITY OF THIS LICENSE AGREEMENT TO CONNECTORS IS REGARDLESS OF WHETHER
SUCH CONNECTORS ARE DISTRIBUTED TO YOU BY RADWARE OR BY A THIRD PARTY PRODUCT
VENDOR. IN CASE A CONNECTOR IS DISTRIBUTED TO YOU BY A THIRD PARTY PRODUCT VENDOR
PURSUANT TO THE TERMS OF AN AGREEMENT BETWEEN YOU AND THE THIRD PARTY PRODUCT
VENDOR, THEN, AS BETWEEN RADWARE AND YOURSELF, TO THE EXTENT THERE IS ANY
DISCREPANCY OR INCONSISTENCY BETWEEN THE TERMS OF THIS LICENSE AGREEMENT AND THE
TERMS OF THE AGREEMENT BETWEEN YOU AND THE THIRD PARTY PRODUCT VENDOR, THE TERMS
OF THIS LICENSE AGREEMENT WILL GOVERN AND PREVAIL. PLEASE READ THE TERMS AND
CONDITIONS OF THIS LICENSE AGREEMENT CAREFULLY BEFORE OPENING THE PACKAGE
CONTAINING RADWARE'S PRODUCT, OR BEFORE DOWNLOADING, INSTALLING, COPYING OR
OTHERWISE USING RADWARE'S STANDALONE SOFTWARE (AS APPLICABLE). THE SOFTWARE IS
LICENSED (NOT SOLD). BY OPENING THE PACKAGE CONTAINING RADWARE'S PRODUCT, OR BY
DOWNLOADING, INSTALLING, COPYING OR USING THE SOFTWARE (AS APPLICABLE), YOU
CONFIRM THAT YOU HAVE READ AND UNDERSTAND THIS LICENSE AGREEMENT AND YOU AGREE
TO BE BOUND BY THE TERMS OF THIS LICENSE AGREEMENT. FURTHERMORE, YOU HEREBY WAIVE
ANY CLAIM OR RIGHT THAT YOU MAY HAVE TO ASSERT THAT YOUR ACCEPTANCE AS STATED
HEREINABOVE IS NOT THE EQUIVALENT OF, OR DEEMED AS, A VALID SIGNATURE TO THIS LICENSE
AGREEMENT. IF YOU ARE NOT WILLING TO BE BOUND BY THE TERMS OF THIS LICENSE
AGREEMENT, YOU SHOULD PROMPTLY RETURN THE UNOPENED PRODUCT PACKAGE OR YOU
SHOULD NOT DOWNLOAD, INSTALL, COPY OR OTHERWISE USE THE SOFTWARE (AS APPLICABLE).
THIS LICENSE AGREEMENT REPRESENTS THE ENTIRE AGREEMENT CONCERNING THE SOFTWARE
BETWEEN YOU AND RADWARE, AND SUPERSEDES ANY AND ALL PRIOR PROPOSALS,
REPRESENTATIONS, OR UNDERSTANDINGS BETWEEN THE PARTIES. “YOU” MEANS THE NATURAL
PERSON OR THE ENTITY THAT IS AGREEING TO BE BOUND BY THIS LICENSE AGREEMENT, THEIR
EMPLOYEES AND THIRD PARTY CONTRACTORS. YOU SHALL BE LIABLE FOR ANY FAILURE BY SUCH
EMPLOYEES AND THIRD PARTY CONTRACTORS TO COMPLY WITH THE TERMS OF THIS LICENSE
AGREEMENT.
1. License Grant. Subject to the terms of this Agreement, Radware hereby grants to you, and you
accept, a limited, nonexclusive, nontransferable license to install and use the Software in
machine-readable, object code form only and solely for your internal business purposes
(“Commercial License”). If the Software is distributed to you with a software development kit
(the “SDK”), then, solely with regard to the SDK, the Commercial License above also includes a
limited, nonexclusive, nontransferable license to install and use the SDK solely on computers
within your organization, and solely for your internal development of an integration or
interoperation of the Software and/or other Radware Products with software or hardware
products owned, licensed and/or controlled by you (the “SDK Purpose”). To the extent an SDK is

distributed to you together with code samples in source code format (the “Code Samples”) that
are meant to illustrate and teach you how to configure, monitor and/or control the Software
and/or any other Radware Products, the Commercial License above further includes a limited,
nonexclusive, nontransferable license to copy and modify the Code Samples and create
derivative works based thereon solely for the SDK Purpose and solely on computers within your
organization. The SDK shall be considered part of the term “Software” for all purposes of this
License Agreement. You agree that you will not sell, assign, license, sublicense, transfer, pledge,
lease, rent or share your rights under this License Agreement nor will you distribute copies of
the Software or any parts thereof. Rights not specifically granted herein, are specifically
prohibited.
2. Evaluation Use. Notwithstanding anything to the contrary in this License Agreement, if the
Software is provided to you for evaluation purposes, as indicated in your purchase order or sales
receipt, on the website from which you download the Software, as inferred from any time-
limited evaluation license keys that you are provided with to activate the Software, or otherwise,
then You may use the Software only for internal evaluation purposes (“Evaluation Use”) for a
maximum of 30 days or such other duration as may specified by Radware in writing at its sole
discretion (the “Evaluation Period”). The evaluation copy of the Software contains a feature that
will automatically disable it after expiration of the Evaluation Period. You agree not to disable,
destroy, or remove this feature of the Software, and any attempt to do so will be a material
breach of this License Agreement. During or at the end of the evaluation period, you may
contact Radware sales team to purchase a Commercial License to continue using the Software
pursuant to the terms of this License Agreement. If you elect not to purchase a Commercial
License, you agree to stop using the Software and to delete the evaluation copy received
hereunder from all computers under your possession or control at the end of the Evaluation
Period. In any event, your continued use of the Software beyond the Evaluation Period (if
possible) shall be deemed your acceptance of a Commercial License to the Software pursuant to
the terms of this License Agreement, and you agree to pay Radware any amounts due for any
applicable license fees at Radware's then-current list prices.
3. Lab/Development License. Notwithstanding anything to the contrary in this License
Agreement, if the Software is provided to you for use in your lab or for development
purposes, as indicated in your purchase order, sales receipt, the part number description for the
Software, the Web page from which you download the Software, or otherwise, then You may use
the Software only in your lab and only in connection with Radware Products that you purchased
or will purchase (in case of a lab license) or for internal testing and development purposes (in
case of a development license) but not for any production use purposes.
4. Subscription Software. If you licensed the Software on a subscription basis, your rights to use
the Software are limited to the subscription period. You have the option to extend your
subscription. If you extend your subscription, you may continue using the Software until the end
of your extended subscription period. If you do not extend your subscription, after the expiration
of your subscription, you are legally obligated to discontinue your use of the Software and
completely remove the Software from your system.
5. Feedback. Any feedback concerning the Software including, without limitation, identifying
potential errors and improvements, recommended changes or suggestions (“Feedback”),
provided by you to Radware will be owned exclusively by Radware and considered Radware's
confidential information. By providing Feedback to Radware, you hereby assign to Radware all of
your right, title and interest in any such Feedback, including all intellectual property rights
therein. With regard to any rights in such Feedback that cannot, under applicable law, be
assigned to Radware, you hereby irrevocably waives such rights in favor of Radware and grants
Radware under such rights in the Feedback, a worldwide, perpetual royalty-free, irrevocable,
sub-licensable and non-exclusive license, to use, reproduce, disclose, sublicense, modify, make,
have made, distribute, sell, offer for sale, display, perform, create derivative works of and
otherwise exploit the Feedback without restriction. The provisions of this Section 5 will survive
the termination or expiration of this Agreement.
6. Limitations on Use. You agree that you will not: (a) copy, modify, translate, adapt or create
any derivative works based on the Software; or (b) sublicense or transfer the Software, or
include the Software or any portion thereof in any product; or (b) reverse assemble,
disassemble, decompile, reverse engineer or otherwise attempt to derive source code (or the

underlying ideas, algorithms, structure or organization) from the Software, in whole or in part,
except and only to the extent: (i) applicable law expressly permits any such action despite this
limitation, in which case you agree to provide Radware at least ninety (90) days advance written
notice of your belief that such action is warranted and permitted and to provide Radware with an
opportunity to evaluate if the law's requirements necessitate such action, or (ii) required to
debug changes to any third party LGPL-libraries linked to by the Software; or (c) create,
develop, license, install, use, or deploy any software or services to circumvent, enable, modify
or provide access, permissions or rights which violate the technical restrictions of the Software;
(d) in the event the Software is provided as an embedded or bundled component of another
Radware Product, you shall not use the Software other than as part of the combined Product and
for the purposes for which the combined Product is intended; (e) remove any copyright notices,
identification or any other proprietary notices from the Software (including any notices of Third
Party Software (as defined below); or (f) copy the Software onto any public or distributed
network or use the Software to operate in or as a time-sharing, outsourcing, service bureau,
application service provider, or managed service provider environment. Notwithstanding the
foregoing, if you provide hosting or cloud computing services to your customers, you are entitled
to use and include the Software in your IT infrastructure on which you provide your services. It
is hereby clarified that the prohibitions on modifying, or creating derivative works based on, any
Software provided by Radware, apply whether the Software is provided in a machine or in a
human readable form. Human readable Software to which this prohibition applies includes
(without limitation) “Radware AppShape++ Script Files” that contain “Special License Terms”. It
is acknowledged that examples provided in a human readable form may be modified by a user.
7. Intellectual Property Rights. You acknowledge and agree that this License Agreement does
not convey to you any interest in the Software except for the limited right to use the Software,
and that all right, title, and interest in and to the Software, including any and all associated
intellectual property rights, are and shall remain with Radware or its third party licensors. You
further acknowledge and agree that the Software is a proprietary product of Radware and/or its
licensors and is protected under applicable copyright law.
8. No Warranty. The Software, and any and all accompanying software, files, libraries, data and
materials, are distributed and provided “AS IS” by Radware or by its third party licensors (as
applicable) and with no warranty of any kind, whether express or implied, including, without
limitation, any non-infringement warranty or warranty of merchantability or fitness for a
particular purpose. Neither Radware nor any of its affiliates or licensors warrants, guarantees, or
makes any representation regarding the title in the Software, the use of, or the results of the
use of the Software. Neither Radware nor any of its affiliates or licensors warrants that the
operation of the Software will be uninterrupted or error-free, or that the use of any passwords,
license keys and/or encryption features will be effective in preventing the unintentional
disclosure of information contained in any file. You acknowledge that good data processing
procedure dictates that any program, including the Software, must be thoroughly tested with
non-critical data before there is any reliance on it, and you hereby assume the entire risk of all
use of the copies of the Software covered by this License. Radware does not make any
representation or warranty, nor does Radware assume any responsibility or liability or provide
any license or technical maintenance and support for any operating systems, databases,
migration tools or any other software component provided by a third party supplier and with
which the Software is meant to interoperate.
This disclaimer of warranty constitutes an essential and material part of this License.
In the event that, notwithstanding the disclaimer of warranty above, Radware is held liable
under any warranty provision, Radware shall be released from all such obligations in the event
that the Software shall have been subject to misuse, neglect, accident or improper installation,
or if repairs or modifications were made by persons other than by Radware's authorized service
personnel.
9. Limitation of Liability. Except to the extent expressly prohibited by applicable statutes, in no
event shall Radware, or its principals, shareholders, officers, employees, affiliates, licensors,
contractors, subsidiaries, or parent organizations (together, the “Radware Parties”), be liable for
any direct, indirect, incidental, consequential, special, or punitive damages whatsoever relating
to the use of, or the inability to use, the Software, or to your relationship with, Radware or any
of the Radware Parties (including, without limitation, loss or disclosure of data or information,

and/or loss of profit, revenue, business opportunity or business advantage, and/or business
interruption), whether based upon a claim or action of contract, warranty, negligence, strict
liability, contribution, indemnity, or any other legal theory or cause of action, even if advised of
the possibility of such damages. If any Radware Party is found to be liable to You or to any third-
party under any applicable law despite the explicit disclaimers and limitations under these
terms, then any liability of such Radware Party, will be limited exclusively to refund of any
license or registration or subscription fees paid by you to Radware.
10. Third Party Software. The Software includes software portions developed and owned by third
parties (the “Third Party Software”). Third Party Software shall be deemed part of the Software
for all intents and purposes of this License Agreement; provided, however, that in the event that
a Third Party Software is a software for which the source code is made available under an open
source software license agreement, then, to the extent there is any discrepancy or inconsistency
between the terms of this License Agreement and the terms of any such open source license
agreement (including, for example, license rights in the open source license agreement that are
broader than the license rights set forth in Section 1 above and/or no limitation in the open
source license agreement on the actions set forth in Section 6 above), the terms of any such
open source license agreement will govern and prevail. The terms of open source license
agreements and copyright notices under which Third Party Software is being licensed to
Radware or a link thereto, are included with the Software documentation or in the header or
readme files of the Software. Third Party licensors and suppliers retain all right, title and interest
in and to the Third Party Software and all copies thereof, including all copyright and other
intellectual property associated therewith. In addition to the use limitations applicable to Third
Party Software pursuant to Section 6 above, you agree and undertake not to use the Third Party
Software as a general SQL server, as a stand-alone application or with applications other than
the Software under this License Agreement.
11. Term and Termination. This License Agreement is effective upon the first to occur of your
opening the package of the Product, purchasing, downloading, installing, copying or using the
Software or any portion thereof, and shall continue until terminated. However, sections 5-15
shall survive any termination of this License Agreement. The Licenses granted under this License
Agreement are not transferable and will terminate upon: (i) termination of this License
Agreement, or (ii) transfer of the Software, or (iii) in the event the Software is provided as an
embedded or bundled component of another Radware Product, when the Software is unbundled
from such Product or otherwise used other than as part of such Product. If the Software is
licensed on subscription basis, this Agreement will automatically terminate upon the termination
of your subscription period if it is not extended.
12. Export. The Software or any part thereof may be subject to export or import controls under
applicable export/import control laws and regulations including such laws and regulations of the
United States and/or Israel. You agree to comply with such laws and regulations, and, agree not
to knowingly export, re-export, import or re-import, or transfer products without first obtaining
all required Government authorizations or licenses therefor. Furthermore, You hereby covenant
and agree to ensure that your use of the Software is in compliance with all other foreign,
federal, state, and local laws and regulations, including without limitation all laws and
regulations relating to privacy rights, and data protection. You shall have in place a privacy
policy and obtain all of the permissions, authorizations and consents required by applicable law
for use of cookies and processing of users' data (including without limitation pursuant to
Directives 95/46/EC, 2002/58/EC and 2009/136/EC of the EU if applicable) for the purpose of
provision of any services.
13. US Government. To the extent you are the U.S. government or any agency or instrumentality
thereof, you acknowledge and agree that the Software is a “commercial computer software” and
“commercial computer software documentation” pursuant to applicable regulations and your use
of the Software is subject to the terms of this License Agreement.
14. Federal Acquisition Regulation (FAR)/Data Rights Notice. Radware's commercial
computer software is created solely at private expense and is subject to Radware's commercial
license rights.

15. Governing Law. This License Agreement shall be construed and governed in accordance with
the laws of the State of Israel.
16. Miscellaneous. If a judicial determination is made that any of the provisions contained in this
License Agreement is unreasonable, illegal or otherwise unenforceable, such provision or
provisions shall be rendered void or invalid only to the extent that such judicial determination
finds such provisions to be unreasonable, illegal or otherwise unenforceable, and the remainder
of this License Agreement shall remain operative and in full force and effect. In any event a
party breaches or threatens to commit a breach of this License Agreement, the other party will,
in addition to any other remedies available to, be entitled to injunction relief. This License
Agreement constitutes the entire agreement between the parties hereto and supersedes all prior
agreements between the parties hereto with respect to the subject matter hereof. The failure of
any party hereto to require the performance of any provisions of this License Agreement shall in
no manner affect the right to enforce the same. No waiver by any party hereto of any provisions
or of any breach of any provisions of this License Agreement shall be deemed or construed
either as a further or continuing waiver of any such provisions or breach waiver or as a waiver of
any other provision or breach of any other provision of this License Agreement.
IF YOU DO NOT AGREE WITH THE TERMS OF THIS LICENSE YOU MUST REMOVE THE
SOFTWARE FROM ANY DEVICE OWNED BY YOU AND IMMEDIATELY CEASE USING THE
SOFTWARE.
COPYRIGHT © 2020, Radware Ltd. All Rights Reserved.

AlteonOS-32-6-0-AppWall For Alteon User Guide

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AlteonOS-32-6-0-AppWall For Alteon User Guide

Transféré par

Droits d'auteur :

Formats disponibles

AppWall for Alteon

Software Version 32.6.0

2 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 3

4 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 5

This product contains code developed by the OpenBSD Project

6 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 7

Notice traitant du copyright

8 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Ce produit inclut un logiciel développé par Nils Nordman.

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 9

Dieses Produkt enthält von Markus Friedl entwickelte Software.

10 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 11

Limitations on Warranty and Liability

Limitations on Warranty and Liability

Limitations de la Garantie et Responsabilité

Haftungs- und Gewährleistungsausschluss

12 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Figure 1: Electrical Shock Hazard Label

DUAL-POWER-SUPPLY-SYSTEM SAFETY WARNING IN CHINESE

Figure 2: Dual-Power-Supply-System Safety Warning in Chinese

Translation of Dual-Power-Supply-System Safety Warning in Chinese:

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 13

14 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

This marking or statement includes the following text warning:

To connect the power connection:

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 15

Figure 3: Étiquette d’avertissement de danger de chocs électriques

AVERTISSEMENT DE SÉCURITÉ POUR LES SYSTÈMES DOTÉS DE DEUX SOURCES D’ALIMENTATION

16 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 17

Cette marque ou remarque inclut l’avertissement textuel suivant:

Pour brancher à l’alimentation électrique:

18 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Figure 5: Warnetikett Stromschlaggefahr

SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 19

Figure 6: Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung

Übersetzung von Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung:

20 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

BESONDERER HINWEIS FÜR BENUTZER IN NORDAMERIKA

Diese Markierung oder Erklärung enthält den folgenden Warntext:

Anschluss des Stromkabels:

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 21

Vorsicht - Zur Reduzierung der Stromschlag- und Feuergefahr

Figure 7: Statement for Class A VCCI-certified Equipment

Translation of Statement for Class A VCCI-certified Equipment:

22 Document ID: RDWR-ALOS-V3260_AW_AL_UG2002

Figure 8: KCC—Korea Communications Commission Certificate of Broadcasting and

Figure 9: Statement For Class A KCC-certified Equipment in Korean

Translation of Statement For Class A KCC-certified Equipment in Korean:

Figure 10: Statement for Class A BSMI-certified Equipment

Translation of Statement for Class A BSMI-certified Equipment:

Déclarations sur les Interférences Électromagnétiques

Document ID: RDWR-ALOS-V3260_AW_AL_UG2002 23

Figure 11: Déclaration pour l’équipement de classe A certifié VCCI

Traduction de la Déclaration pour l’équipement de classe A certifié VCCI:

Translation de la Déclaration pour l’équipement de classe A certifié KCC en langue coréenne:

Figure 14: Déclaration pour l’équipement de classe A certifié BSMI

Translation de la Déclaration pour l’équipement de classe A certifié BSMI: