AppWall Manual

AppWall User Guide
Software Version 5.6.1

Document ID: RDWR-APW-V561-UG1211
November, 2012
AppWall User Guide
2 Document ID: RDWR-APW-V561-UG1211

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. 2012. 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 suivantes:
Copyright Radware Ltd. 2012. 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. 2012. 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-APW-V561-UG1211 3

AppWall User Guide
Copyright Notices
The following copyright notices are presented in English, French, and German.
Copyright Notices
This product contains code developed by the OpenSSL Project
This product includes software developed by the OpenSSL Project. For use in the OpenSSL Toolkit.
(http://www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. All rights reserved.
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 (c) 1983, 1990, 1992, 1993, 1995
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3. Neither the name of the University nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
This 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

AppWall User Guide
1. Redistributions of source code must retain the above copyright notice, this list of conditions and
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
distribution.
ALL THE SOFTWARE MENTIONED ABOVE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
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 develpoed 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.

AppWall User Guide
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 (c) 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:
• Redistributions of source code must retain the above copyright notice, this list of conditions, and
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions,
distribution.
• Neither the name of ace-radius nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE 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 (c) 2001-2010 Jochen Katz, Frank Fock
The SNMP++v3.2.25 library is based on SNMP++2.6 from Hewlett Packard: Copyright (c) 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

Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Ce produit inclut un logiciel développé dans le cadre du projet OpenSSL. Pour un usage dans la boîte
à outils OpenSSL (http://www.openssl.org/).
Copyright (c) 1998-2005 Le projet OpenSSL. Tous droits réservés. Ce produit inclut la catégorie de
chiffre Rijndael.
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)

AppWall User Guide

@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:
Ce code est également placé dans le domaine public.
Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Copyright (c) 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É

AppWall User Guide
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
Dieses Produkt enthält einen vom OpenSSL-Projekt entwickelten Code
Dieses Produkt enthält vom OpenSSL-Projekt entwickelte Software. Zur Verwendung im OpenSSL
Toolkit. (http://www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. Alle Rechte vorbehalten. Dieses Produkt enthält die
Rijndael cipher
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:
Dieser Code wird hiermit allgemein zugänglich gemacht.
Dieses Produkt enthält einen vom OpenBSD-Projekt entwickelten Code
Copyright (c) 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

AppWall User Guide
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.
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.

AppWall User Guide
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.

AppWall User Guide
VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS
Figure 3: 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 action.
Figure 4: Statement for Class B VCCI-certified Equipment
Translation of Statement for Class B VCCI-certified Equipment:

This is a Class B product based on the standard of the Voluntary Control Council for Interference by
Information Technology Equipment (VCCI). If this is used near a radio or television receiver in a
domestic environment, it may cause radio interference.
Install and use the equipment according to the instruction manual.
KCC KOREA
Figure 5: KCC—Korea Communications Commission Certificate of Broadcasting and

Communication Equipment
Figure 6: 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.

AppWall User Guide
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

AppWall User Guide
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 7: É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.

AppWall User Guide
Figure 8: 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.

AppWall User Guide
DÉCLARATIONS SUR LES INTERFÉRENCES ÉLECTROMAGNÉTIQUES VCCI
Figure 9: 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.
Figure 10: Déclaration pour l’équipement de classe B certifié VCCI
Traduction de la Déclaration pour l’équipement de classe B certifié VCCI:

Il s’agit d’un produit de classe B, basé sur la norme du Voluntary Control Council for Interference by
Information Technology Equipment (VCCI). S’il est utilisé à proximité d’un poste de radio ou d’une
télévision dans un environnement domestique, il peut entraîner des interférences radio.
Installez et utilisez l’équipement selon le manuel d’instructions.
KCC Corée
Figure 11: KCC—Certificat de la commission des communications de Corée pour les equipements de
radiodiffusion et communication.
Figure 12: Déclaration pour l’équipement de classe A certifié KCC en langue coréenne

AppWall User Guide
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.
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.

AppWall User Guide
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.

AppWall User Guide
Figure 13: Warnetikett Stromschlaggefahr
SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

Die folgende Abbildung ist die Warnung für Radware-Plattformen mit Doppelspeisung.
Figure 14: 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.

AppWall User Guide
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.
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.
Figure 16: Erklärung zu VCCI-zertifizierten Geräten der Klasse B
Übersetzung von Erklärung zu VCCI-zertifizierten Geräten der Klasse B:

Dies ist ein Produkt der Klasse B 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.
Montieren und benutzen Sie das Gerät laut Anweisungen im Benutzerhandbuch.
KCC KOREA
Figure 17: KCC—Korea Communications Commission Zertifikat für Rundfunk-und

Nachrichtentechnik

AppWall User Guide
Figure 18: 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.
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.

AppWall User Guide
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.
Altitude and Climate Warning
Note: This warning only applies to The People's Republic of China.
1. 对于在非热带气候条件下运行的设备而言， Tma：为制造商规范允许的最大环境温度，或者为 25°C，采用两

者中的较大者。
2. 关于在海拔不超过 2000m 或者在非热带气候地区使用的设备，附加警告要求如下：
关于在海拔不超过 2000m 的地区使用的设备，必须在随时可见的位置处粘贴包含如下内容或者类似用语的警告标

记、或者附件 DD 中的符号。
“ 只可在海拔不超过 2000m 的位置使用。”
关于在非热带气候地区使用的设备，必须在随时可见的位置处粘贴包含如下内容的警告标记：

AppWall User Guide
“ 只可在非热带气候地区使用。”
附件 DD：有关新安全警告标记的说明。
DD.1 海拔警告标记
标记含义：设备的评估仅基于 2000m 以下的海拔高度，因此设备只适用于该运行条件。如果在海拔超过 2000m 的

位置使用设备，可能会存在某些安全隐患。
DD.2 气候警告标记
标记含义：设备的评估仅基于温带气候条件，因此设备只适用于该运行条件。如果在热带气候地区使用设备，可能
会存在某些安全隐患。
Document Conventions
The following describes the conventions and symbols that this guide uses:
Item Description Description (French) Beschreibung (German)

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
data des données ou du Daten
Caution: 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

AppWall User Guide
Item Description Description (French) Beschreibung (German)

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:

AppWall User Guide

AppWall User Guide
Table of Contents
Table of Contents
Important Notices .......................................................................................................... 3
Copyright Notices .......................................................................................................... 4
Safety Instructions ......................................................................................................... 9
Altitude and Climate Warning ...................................................................................... 21
Document Conventions ............................................................................................... 22
.................................................................................................................................... 23
Chapter 1 – Web Application Security .................................................................. 31

Overview ..................................................................................................................... 31
Introduction to HTTP ................................................................................................... 32
HTTP Methods ..................................................................................................................... 32
Security Issues, Hackers and Threats ......................................................................... 33
OWASP Top Ten Vulnerabilities Classification ................................................................... 33
WASC Web Security Attack Classification .......................................................................... 34
Threat Protection by AppWall ...................................................................................... 36
Chapter 2 – Introducing AppWall .......................................................................... 39

AppWall Overview ....................................................................................................... 39
Logging In to the AppWall Device ............................................................................... 39
AppWall Components .................................................................................................. 40
AppWall Management Application ....................................................................................... 40
AppWall Management Application Console ......................................................................... 42
Context-Sensitive Help ........................................................................................................ 46
Getting Started Pane ........................................................................................................... 46
Users and Authorization Status ........................................................................................... 47
AppWall Services and Processes ........................................................................................ 48
AppWall Gateway ................................................................................................................ 48
AppWall Cluster Manager .................................................................................................... 48
AppWall Publisher ............................................................................................................... 48
Watchdog ............................................................................................................................. 49
Management Tools - Command Line Interface (CLI) Manager ........................................... 49
The AppWall Command Line Command ............................................................................. 57
Management Tools - Management Console/Web Interface ................................................ 58
Licenses ............................................................................................................................... 59
Before Installation and Configuration ................................................................................... 59
Chapter 3 – Installing and Configuring AppWall.................................................. 61

System Startup ............................................................................................................ 61
Initial Configuration ...................................................................................................... 61
Managing Servers ................................................................................................................ 62

AppWall User Guide
Table of Contents
Defining a Cluster Server Configuration .............................................................................. 67

Managing Users .................................................................................................................. 70
Managing Web User Roles ................................................................................................. 75
Working With Certificates .................................................................................................... 78
Working with Tunnels .......................................................................................................... 87
Defining Console-Server Connections .............................................................................. 108
Configuring the Publisher .................................................................................................. 110
Defining the Escalation Server List ................................................................................... 115
Deployment Planning ............................................................................................... 115
AppWall Gateway Deployment .......................................................................................... 116
Reverse Proxy Deployment ............................................................................................... 116
Transparent Proxy Deployment ......................................................................................... 117
Bridge Deployment ............................................................................................................ 117
Cluster Deployment ........................................................................................................... 118
Requirements for AppWall Cluster Environment ............................................................... 119
Deploying AppWall in an ADC Environment ..................................................................... 119
Multiple Web Server/Web Farm Deployment .................................................................... 120
Escalation .......................................................................................................................... 121
Load Balancing ................................................................................................................. 122
AppWall Virtual Appliance ................................................................................................. 124
APSolute Vision Reporter ................................................................................................. 124
SNMP Agent ..................................................................................................................... 127
Chapter 4 – Security Tools................................................................................... 129

Working with Security Filters .................................................................................... 129
Security Filter Overview .................................................................................................... 129
Threats the Security Filters Protect Against ...................................................................... 130
Setting Security Filters ...................................................................................................... 131
Activating a Security Filter ................................................................................................. 132
Setting the Security Filter Run Mode ................................................................................. 132
Refining Security Filters .................................................................................................... 133
Security Filters in Detail ............................................................................................ 134
AllowList Security Filter ..................................................................................................... 134
BruteForce Security Filter .................................................................................................. 139
Database Security Filter .................................................................................................... 144
FilesUpload Security Filter ................................................................................................ 146
GlobalParameters Security Filter ...................................................................................... 148
HTTPMethods Security Filter ............................................................................................ 151
Logging Security Filter ...................................................................................................... 154
SafeReply Security Filter ................................................................................................... 157
WebServices Security Filter .............................................................................................. 161
XMLSecurity Security Filter ............................................................................................... 164
Parameters Security Filter ................................................................................................. 168
PathBlocking Security Filter .............................................................................................. 174
Session Security Filter ....................................................................................................... 175
Vulnerabilities Security Filter ............................................................................................. 181

AppWall User Guide
Table of Contents
Web Application ....................................................................................................... 184

Logical Model .................................................................................................................... 184
Logical Objects ................................................................................................................. 185
Creating a Web Application .............................................................................................. 186
Enabling/Disabling a Web Application .............................................................................. 187
Deleting a Web Application ............................................................................................... 188
Adding Tunnels, Hosts, and Application Paths ................................................................. 188
Hosts ........................................................................................................................ 189
User Tracking, Authentication, and Single Sign-On ......................................................... 189
Role-Based Security Policies for LDAP Managed Users .................................................. 191
Web User Roles ................................................................................................................ 192
IP-Based Role ................................................................................................................... 193
Security Page ................................................................................................................... 193
Application Path ....................................................................................................... 194
Managing Security Filters at the Application Path Level ................................................... 201
Refining Security Filters Definitions .................................................................................. 202
Host Level Configuration .......................................................................................... 203
CSRF (Cross Site Request Forgery) Protection ............................................................... 204
Hotlink Protection .............................................................................................................. 205
Directory Listing ................................................................................................................ 205
URL Rewrite ..................................................................................................................... 205
Defining Your Security Policy ................................................................................... 206
AppWall Protection ........................................................................................................... 206
Defining Enterprise Requirements .................................................................................... 207
Setting a Security Policy ................................................................................................... 209
User Tracking and Host Authentication ............................................................................ 215
Defenses Properties ................................................................................................. 216
Landing Pages .................................................................................................................. 216
Bot List .............................................................................................................................. 217
Search Engine Referer ..................................................................................................... 217
Auto Policy Generation ............................................................................................. 218
Rapid Auto Policy Generation Mode ................................................................................. 218
Extended Auto Policy Generation Mode ........................................................................... 218
Working with Auto Policy Generation Profiles .................................................................. 219
Security Filter Auto Policy Generation Tools .................................................................... 219
Auto Tunnel Settings Optimization ................................................................................... 226
Working in Learn Mode ..................................................................................................... 226
Auto Discovery .................................................................................................................. 228
Web Crawler ..................................................................................................................... 231
Site Map List ..................................................................................................................... 232
Auto Policy Generation Properties .................................................................................... 232
Chapter 5 – Best Practices................................................................................... 235

Working in a Staging Environment (from Test to Production) .................................. 235

AppWall User Guide
Table of Contents
Policy Changes and Their Effect on Performance .................................................... 236

Working with Events ................................................................................................. 236
Hiding Sensitive Content Parameters ....................................................................... 246
Transaction ID .......................................................................................................... 246
Working with the Dashboard .................................................................................... 247
Chapter 6 – Additional Configuration Options................................................... 253

AppWall Server Configurations ................................................................................ 253
Backing Up an AppWall Server Configuration ................................................................... 253
Restoring an AppWall Server Configuration ...................................................................... 254
Setting the Maximum Size of AppWall Server Configuration Files .................................... 254
Distributing a Server Policy to other AppWall Servers ...................................................... 254
APSolute Vision Reporter ......................................................................................... 256
Working with AppWall Services ................................................................................ 256
Watchdog ................................................................................................................. 256
Configuring AppWall Watchdog ........................................................................................ 256
SNMP Agent ............................................................................................................. 257
Configuring AppWall SNMP Agent .................................................................................... 257
IP Blocking ................................................................................................................ 258
Configuring IP Blocking ..................................................................................................... 258
Managing Blocked IP Addresses ...................................................................................... 259
Signature Update Service (SUS) .............................................................................. 259
OPSEC — Integrating AppWall Server with Check Point FireWall-1 ....................... 260
Configuring General FireWall Properties on the AppWall Server ...................................... 260
Editing the OPSEC Configuration File ............................................................................... 261
Registering AppWall Server in FireWall and Vice Versa ................................................... 263
Establishing an Authentication Key ................................................................................... 263
Generating an Authentication Key .................................................................................... 263
Verifying the Key Exchange Process ................................................................................ 264
Managing Security and Escalation Events Settings ................................................. 264
Managing the Event Map .................................................................................................. 264
Managing Severity Rules .................................................................................................. 265
Managing Publishing Rules ............................................................................................... 267
Managing Escalation Rules ............................................................................................... 268
Managing Log Files ........................................................................................................... 270
Events ............................................................................................................................... 270
Resetting to Factory Defaults ............................................................................................ 271
Appendix A – Troubleshooting............................................................................ 275

General Issues ......................................................................................................... 275
What TCP Ports Does AppWall Use? ............................................................................... 275
How Do I Backup the Auto Discovery Tree? ..................................................................... 275

AppWall User Guide
Table of Contents
Filters and Configuration Issues ............................................................................... 275

What is a SafeReply Security Filter? Why do I need it? ................................................... 276
Do I need the SafeReply Filter on every Application Path? .............................................. 276
What is Policy Distribution and can I do this Cross Platform (OS)? ................................. 276
Where else should I use the Brute Force Filter other than the login page? ...................... 276
How does the AppWall Load Balancing (‘web server farms’) work? ................................ 276
How can I read old AppWall events? ................................................................................ 276
Appendix B – Regular Expressions .................................................................... 277

Escaping RegEx ....................................................................................................... 277
Appendix C – Code Pages.................................................................................... 283

Code Description ...................................................................................................... 284
Appendix D – HTTP Status Codes....................................................................... 287
Appendix E – Extracting Original Source IP Address from an HTTP Header . 289
Radware Ltd. End User License Agreement....................................................... 291

AppWall User Guide
Table of Contents

AppWall User Guide
Web Application Security
Chapter 1 – Web Application Security

This user guide is intended for IT professionals who are responsible for the implementation of a Web
Application’s security policy. This user guide will take you through basic initial steps to help you start
working with AppWall to more advanced AppWall configurations, depending on your requirement.
It is assumed that you are familiar with many of the concepts and terms used throughout the Web
Application Security industry. This first chapter provides an introduction to the HTTP protocol, the
security risks to web applications and introduces AppWall capabilities providing a brief description of
its main characteristics in the following sections:
• Overview, page 31
• Introduction to HTTP, page 32
• Security Issues, Hackers and Threats, page 33
• Threat Protection by AppWall, page 36
The case in favor of enabling organizational processes and applications for the Internet has long
been proven, as has the need to protect them against attack. Strong network level protection
against attack (like firewalls and intrusion detection systems) is mandatory in all enterprise Web
application environments – you know the threat is real, the risk and potential costs are high – so
protection is required.
However, hacking techniques are now designed to legitimately access the Web application, and then
attack back-end systems using transactions that appear to be normal. These well-publicized Web
“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 all of this activity looks like perfectly legitimate Internet traffic, the network
security team is completely unaware of these attacks unless someone happens to notice their
effects.
This section includes the following:
• An overview of Web Application Security including an overview of HTTP and the security issues,
hackers and threats currently at play in the Web Application industry.
• A description of the protection given by AppWall.
Overview
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.

AppWall User Guide
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).
Introduction to HTTP
HTTP (which stands for 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 (resources are the R in 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 (e.g., 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.

AppWall User Guide
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
Vulnerability Class Summary Description

A1-Injection Injection flaws, such as SQL, OS, and LDAP injection, occur when
untrusted data is sent to an interpreter as part of a command or query.
The attacker’s hostile data can trick the interpreter into executing
unintended commands or accessing unauthorized data.
A2-Cross Site Scripting XSS flaws occur whenever an application takes untrusted data and sends
(XSS) it to a web browser without proper validation and escaping. XSS allows
attackers to execute scripts in the victim’s browser which can hijack user
sessions, deface web sites, or redirect the user to malicious sites.
A3-Broken Application functions related to authentication and session management
Authentication and are often not implemented correctly, allowing attackers to compromise
Session Management passwords, keys, session tokens, or exploit other implementation flaws to
assume other users’ identities.
A4-Insecure Direct A direct object reference occurs when a developer exposes a reference to
Object References an internal implementation object, such as a file, directory, or database
key. Without an access control check or other protection, attackers can
manipulate these references to access unauthorized data.

AppWall User Guide
Table 1: OWASP Top Ten Vulnerabilities
Vulnerability Class Summary Description

A5-Cross Site Request A CSRF attack forces a logged-on victim’s browser to send a forged HTTP
Forgery (CSRF) 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
A6-Security Good security requires having a secure configuration defined and
Misconfiguration deployed for the application, frameworks, application server, web server,
database server, and platform. All these settings should be defined,
implemented, and maintained as many are not shipped with secure
defaults. This includes keeping all software up to date, including all code
libraries used by the application
A7-Insecure Many web applications do not properly protect sensitive data, such as
Cryptographic Storage credit cards, SSNs, and authentication credentials, with appropriate
encryption or hashing. Attackers may steal or modify such weakly
protected data to conduct identity theft, credit card fraud, or other crimes
A8-Failure to Restrict Many web applications check URL access rights before rendering protected
URL Access links and buttons. However, applications need to perform similar access
control checks each time these pages are accessed, or attackers will be
able to forge URLs to access these hidden pages anyway
A9-Insufficient Applications frequently fail to authenticate, encrypt, and protect the
Transport Layer confidentiality and integrity of sensitive network traffic. When they do,
Protection they sometimes support weak algorithms, use expired or invalid
certificates, or do not use them correctly
A10-Unvalidated Web applications frequently redirect and forward users to other pages and
Redirects and Forwards websites, and use untrusted data to determine the destination pages.
Without proper validation, attackers can redirect victims to phishing or
malware sites, or use forwards to access unauthorized pages.
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

AppWall User Guide
— 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, patch level, etc. 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, online purchases, etc. 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

AppWall User Guide
Table 2: Unclassified Application Layer Attack Types
Form of Attack Summary Description

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
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.
Threat Protection by AppWall

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

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

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
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. The Session Security 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

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

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 Filter This Filter evaluates outbound replies for the presence of sensitive
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.
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.
For further information on working with AppWall Security Filters, see the appropriate section, or the
Online Reference guide (accessed by pressing F1 from within the Management Application).

AppWall User Guide
Introducing AppWall
Chapter 2 – Introducing AppWall

AppWall is the first comprehensive threat management system to support large-scale deployment of
Web Application and Web services security for the distributed enterprise. This chapter introduces
AppWall and its components and helps guide you to deploy AppWall in different scenarios.
• AppWall Overview, page 39
• Logging In to the AppWall Device, page 39
• AppWall Components, page 40
AppWall Overview
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.
AppWall consists of the following major components that together provide a scalable, manageable
solution for securing Web Applications:
• The AppWall Gateway Web Application Firewall.
• AppWall Management Application for centralized administration, management, reporting, and
forensics.
AppWall Gateways work in unison across the distributed enterprise to intelligently detect and block
internal and external attacks to Web Applications without impacting operational performance. The
centralized AppWall Management Application supports scalable deployment of AppWall Gateways
across multiple applications and locations while providing critical real-time and historical data for
decision-making.
Note: This document refers to AppWall Gateways as AppWall Server.
AppWall provides:
• Built in security policy for immediate, out-of-the-box protection.
• Deployment options to balance network performance expectations with threat levels:
— Inline deployed in reverse proxy.
— Positive and negative security models that ensure protection against the maximum number
and variety of attacks.
• High performance to minimize impact on current operations.
Logging In to the AppWall Device

For web interface access, the AppWall device comes pre-configured with a default management IP
address, 192.168.0.1/24, and username / password, admin / radware.
For CLI access, you can run AppWall in Maintenance mode and login with username / password,
root / radware.

AppWall User Guide
Introducing AppWall
AppWall Components
This section describes the main components that make up AppWall, and includes the following:
• AppWall Management Application, page 40
• AppWall Management Application Console, page 42
• Context-Sensitive Help, page 46
• Getting Started Pane, page 46
• Users and Authorization Status, page 47
• AppWall Services and Processes, page 48
• AppWall Gateway, page 48
• AppWall Cluster Manager, page 48
• AppWall Publisher, page 48
• Watchdog, page 49
• Management Tools - Command Line Interface (CLI) Manager, page 49
• The AppWall Command Line Command, page 57
• Management Tools - Management Console/Web Interface, page 58
• Licenses, page 59
• Before Installation and Configuration, page 59
AppWall Management Application

AppWall Management Application is a Web-based applet which is also distributed as aJava GUI tool
that allows administrators to centrally manage Web Application monitoring and protection for an
entire enterprise.
To launch the AppWall management application, in a Web browser, enter:
https://AppWall_IP_Address/Console/
AppWall Management Application enables users to:
• Centrally manage multiple AppWall Servers across an enterprise, and using AppWall Cluster
Manager to manage a cluster environment.
• 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.

AppWall User Guide
Introducing AppWall
Figure 19: AppWall Management Application
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 Management Application provides centralized administration, management, reporting, and
forensics for all AppWall Servers across the enterprise. This information is presented through four
views based on the individual’s role in the organization:
• The Configuration View (as shown in the image above) allows IT and/or security personnel to
physically configure AppWall Servers. 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 via 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 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.
For further information on the Console workspace and how to work with the Console’s main features, see the
Online Reference guide (accessed by pressing F1 from within the Console).

AppWall User Guide
Introducing AppWall
AppWall Management Application Console

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 Server logs.
Application Management Workspace

The AppWall Application Management graphical interface consists of the following main areas:
• Menu Bar and AppWall Management Application Toolbar
• Primary Navigation Area — View Selection
• Secondary Navigation Area — Tree View
• Display Pane — Content Area
• Status Bar
After opening AppWall Application Management, the main window appears as the following figure
shows.
Figure 20: Main AppWall Application Management Window
Menu Bar and AppWall Management Application Toolbar

The Menu Bar provides basic functionality and is generally available regardless of the active view:

AppWall User Guide
Introducing AppWall
Table 4: AppWall Management Application Toolbar
Main Bar Menu Function

Action menu Clicking the Action menu provides a list of actions that may be applied depending
on the current view selection. The following is an example of a possible available
Action menu:
• Add/Remove—Permits adding/removing AppWall Servers
• Rename—Permits editing the Server Group name
• Properties—Displays Server Group properties
• Backup/Restore—Permits backing up/restoring of configuration files
• Policy Distribution—Opens the Policy Distribution Wizard
• Connection Settings—Displays Console connection properties
• Revert—Allows the user to revert to the last saved configuration.
View menu Control display features: Turns Status Bar on or off, or set language codepage.
Tools menu Choose an XML editor for editing configuration files when running the system in
Appliance mode (available only in the Configuration view).
Help menu Displays online help. In addition, clicking F1 in any screen or dialog displays a
contextually relevant help page.
The AppWall Management Application toolbar provides access to AppWall Server 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 21: 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 5: Functions of Different Views
Main Bar Function

Configuration Change configuration settings of Tunnels, Security Filters (and enable Auto Policy
Generation), Logs, Users, Licenses, and more. Access additional services such as
Publisher, Certificates, 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.

AppWall User Guide
Introducing AppWall
Table 5: Functions of Different Views
Main Bar Function

Forensics Monitor Web Application activity by viewing logs and reports of events that occur
in your Web Application. Observe changes to the AppWall Server and look out for
potential security problems.
Dashboard An overall view of status and properties of the AppWall Servers running on your
network.
Manage the AppWall Server: set refresh intervals, and view server status and
properties.
Secondary Navigation Area — Tree View

The Secondary Navigation Area, which provides a tree view for navigating through your AppWall
Server 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 AppWall
Server, Web Application, or Security Filter.
The top of the tree begins with a node representing the AppWall Application Management Console,
followed by a node for the Server Group, which represents a collection of AppWall Servers.
Depending on the size of your network, you may have multiple Server Groups containing multiple
AppWall Servers.
LocalHost represents the default AppWall Server, which is typically installed on the local machine
with the server IP address 127.0.0.1 and ports 8200 (Gateway). AppWall Servers, however, can run
on another machine in the network (recommended).
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 Server.
Figure 22: Security Policies View

AppWall User Guide
Introducing AppWall
Figure 23: Configuration View
Display Pane — Content Area

The right pane, or Display Area, displays the window associated with the node selected from the
tree.
You can display additional information about specific options in this pane by hovering your mouse
over the selection. For example, in the HTTP Properties of the Configuration View, hover your mouse
over any property to obtain details about this property.

AppWall User Guide
Introducing AppWall
Figure 24: Display Pane
Status Bar
The Status Bar provides updates on the AppWall Server to which you are connected.
When you click Apply Changes to update the AppWall Server, the change may affect the network
sessions because some changes require that the AppWall Server restarts.
Figure 25: Status Bar
Context-Sensitive Help
AppWall Management Application has context-sensitive help. Press F1 to access help on any node,
toolbar button, dialog box, or window.
The Help window contains a Table of Contents, Index, and a full-text search function.
Getting Started Pane

The Getting Started Pane offers a user-friendly way to get you up and running.
Once you have logged into your server and gateway. Select Help > Getting Started from the drop-
down menu and the following pane will be added to your AppWall GUI.
By selecting each item, expanding it and following the procedures in turn, in no time you will have
successfully configured an AppWall. At the same time, in the left pane where the console tree is
located, outstanding action items will remain highlighted in red.

AppWall User Guide
Introducing AppWall
Figure 26: Getting Started Pane
Users and Authorization Status

You can view the users setup and their authorization status via a pop-up window.
To view login user and authorizations (from all views)
1. Right-click a AppWall Server node and select Properties.

or double-click a AppWall Server in the list of servers.
2. A pop-up window displays the following information.
Table 6: Viewing Login User and Authorization Status
Property Description
Server Type Type of AppWall Server: Gateway.
Server Version The software version of the AppWall Server, including build number.
Service Last Date and time the AppWall Server was last started.
Started
Last Changes Date and time the last Apply was performed.
Applied
Pending Reports whether changes await an Apply before updating a AppWall Server.
Operating Operating system on which this AppWall Server is running. Can be Windows, SUN
System or Linux.
Current Status Current status of AppWall Server: 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.

AppWall User Guide
Introducing AppWall
AppWall Services and Processes

The AppWall Server application consists of:
Table 7: AppWall Services and Processes
Component Description
AppWall Server Core server that listens to incoming HTTP and HTTPS traffic and
generates events and/or blocks traffic.
AppWall Management Application User-interface client for configuring and managing the AppWall
Server.
AppWall Publisher Event handler that can distribute server events to SNMP, SMTP,
SysLog, OPSEC ELA, and ODBC recipients.
Watchdog Auxiliary server that ensures reliable server operation by
restarting the AppWall Server whenever necessary, thereby
avoiding extended down time.
Invoking the AppWall Server consists of:

1. Starting the AppWall Server process (or service on Window systems).
2. Starting the AppWall Management Application.
AppWall Gateway
The AppWall Gateway is Radware's Web Application Firewall that operates in front of Web
Applications, intercepting all incoming and outgoing application-layer traffic. It guards your Web
Applications and IT infrastructure against HTTP and HTTPS based attacks. The AppWall Gateway
provides the Web Application protection you need to effectively round out your Internet security
plan.
The AppWall Gateway inspects HTTP and HTTPS requests in a manner that traditional security
measures cannot. It looks at what the request intends to do, what it's carrying, whom it's from and
where it's going. Using its patent-pending Protected Path technology, the AppWall Gateway initiates
multi-tiered validation of the messages. This includes validation for request and reply messages.
AppWall Cluster Manager

The AppWall Cluster Manager enables the enterprise to deploy AppWall Servers in a Cluster
arrangement. From a single Management Application, which is connected to the AppWall Cluster
Manager, it is possible to manage relevant changes to a Security Policy across a number of AppWall
Servers.
For further information on how to work with the AppWall Cluster Manager, see the Cluster
Deployment and Defining a Cluster Server Configuration sections.
AppWall Publisher
The AppWall Publisher is an Event handler, capable of publishing Events to specified users or
programs. Publisher administration includes such tasks as connections to AppWall Servers, SMTP
settings, ODBC connections, and others. The Publisher runs on the AppWall device and is managed
via the Management Application.
For further information on how to work with the AppWall Publisher, see the Configuring the Publisher
section.

AppWall User Guide
Introducing AppWall
Watchdog
The Watchdog is installed as a service that resides on each machine running an AppWall Server. It
maintains proper server operation, restarts the AppWall Server when necessary, and prevents
extended downtime.
For further information on how to work with Watchdog, see the Configuring AppWall Watchdog
section.
Management Tools - Command Line Interface (CLI) Manager

The CLI Interface Manager is used for management of the primary configuration. The CLI Manager
application is available using any of the following text consoles:
• Direct connection via local keyboard and video
• Serial connection using an RS232 console cable
• Network connection using a Secure Shell (SSH port 22) connection to the appliance
management IP address.
Upon logging into the system, the CLI Manager is displayed. The following instructions will assist
navigating of the CLI Manager:
• Use the arrow keys to navigate up and down
• Use the Enter key to select a menu or enter into a sub-menu and use the following keys to
navigate:
— Q – Quit - quit the manager application
— T – Top – go to the top of the current menu
— U – Up – move up one level
— H – Help – displays key settings and instructions.
• To move between multiple fields use the Tab button.
The following selectable screen options are provided to manage the appliance:
• Status – Review of system status and logs
• Administration – Administration of core appliance functionalities
• Networking – IP networking configurations
Figure 27: CLI Interface Manager

AppWall User Guide
Introducing AppWall
Status Screen
When selecting Status from the list you can review the following system status and log information:
• System Information – Displays system information
• Resource Usage – Shows appliance memory, disk, and CPU usage.
• Log Display – Displays log entries for system events
• Log Purge – Allows to erase log
System Information
This setting displays a list of devices and other system information, such as the amount of RAM, CPU
type, Disk space and NIC information.
Resource Usage
The Resource Usage selection provides information for the following Kernel counters:
• Interrupt/Second
• Context switches/second
• Percentage KERNEL
• Percentage I/O
• Percentage APPLICATION
To access Resource Usage
1. From the main CLI manager menu, select Status > Resource Usage > Kernel.
2. View the Kernel Counter information.
3. Click U(p), T(op) or scroll to Finish. You are returned to the previous level.
Log Display
Selecting the Log Display option from the menu displays all logged events, including server status,
management events and more.
Logging of events is registered in the Log including the exact date and time of the event, server
name and the severity level of the event.
To access the Log Display
1. From the main CLI manager menu, select Status > Log Display.
2. View the Log information.
3. Click Q(uit) to exit. You are returned to the previous level.

AppWall User Guide
Introducing AppWall
Log Purge
This option allows you to clear all log entries.
To purge Log Entries
1. From the main CLI manager menu, select Status > Log Display.
2. Click Enter to clear the Log.
3. Click Enter to exit. You are returned to the previous level.
Administration Screen
Upon selecting Administration from the list you can review the following administration
functionalities:
• Start/Stop Services
• Change Hostname
• Change Admin Password
• Change Viewer Password
• Configuration Backup/Restore
• OS Backup/Restore
• Break Multi-user Lock
• Reboot
• Cluster manager Mode
• Set Date/Time
• Timezone
• ODBC
• Shut down
Figure 28: CLI Administration Screen

AppWall User Guide
Introducing AppWall
Start/Stop Services
This setting allows for the manual starting and stopping of AppWall Gateway services.
To start/stop AppWall Gateway Services
1. From the main menu, select Administration > Start / Stop Services.
2. Select the Service you want to control.
3. Select the Action field and click Enter.
Note: You can start/stop services such as the Apache server and SSH connection, which are
required for compliance with common security standards. The screen below lists the
services available, including Apache and SSH.
Figure 29: AppWall Gateway services
Change Hostname
This selection permits changing the appliance host name.
To change the Appliance Hostname
1. From the main menu, select Administration > Change Hostname.

2. Type the new name for the Appliance (leaving this field empty and pressing Enter will abort the
change).
3. Click Enter.
Change Admin Password

This selection permits changing the admin (administrator) password by entering Administration >
Change Admin Password, typing in the new password and re-typing the password to confirm.

AppWall User Guide
Introducing AppWall
Change Viewer Password

This selection permits changing the viewer password by entering
Administration > Change Viewer Password, typing in the new password and re-typing the
password to confirm.
Configuration Backup/Restore
This setting allows creating backups of configuration files and settings and to restore them at a later
time. AppWall Gateway configuration files may be backed up and stored for use in the event of an
error that requires restoring a better configuration of AppWall Gateway.
To backup/restore AppWall Gateway
1. Select Administration > Configuration Backup/Restore > Configuration Backup.

2. Click Enter.
3. Click y(es) or n(o) to complete or cancel the configuration backup.
OS Backup/Restore
This option allows the user to create a complete backup of the system Kernel, OS utilities and
components, Appliance binaries and configuration and AppWall Gateway binaries and configuration.
This backup procedure is useful before upgrading to a new AppWall Gateway or Appliance version.
The backup is created on the second partition of the local machine. Restoring of the backup file is
performed either through the CLI manager or the Web Management Console.
To back up the OS
1. From the main menu, select Administration > OS Backup/Restore.

2. Select OS Backup and click Enter.
3. Click y(es) to backup the OS partition.
To restore the OS
Important: You are required to reboot the machine and boot to the backup partition. From that
location you may run the following restore procedure.
1. From the main menu, select Administration > OS Backup/Restore.
2. Select OS Restore and click Enter.
3. Click y(es) to restore the backup of the OS partition.
Break Multi-user Lock

As the Appliance supports remote and local connections, there may be more than one user logged in
to the system at any given time. To prevent a user from interfering with another user, the system
provides indication to a user that he is not the first user currently logged in to the system.
In some cases, for example, when a remote logged in user is rebooting his system, the system may
still count him as logged in and provide wrong indication for multiple logged in users. The Break
Multi-user Lock will restart counting of the logged in users.

AppWall User Guide
Introducing AppWall
To break Multi-user Lock
1. From the main menu, select Administration > Break Multi-user Lock
2. Click Enter.
Reboot
This setting is used to reboot the Appliance. This is accomplished by selecting Reboot from the
Administration menu, and clicking Enter.
Networking Screen
When you select Networking from the list, the following screen is displayed:
Figure 30: AppWall Gateway Networking
You may review and select from the following networking configurations:
• Address management
• Route Management
• Domain Information
• Time Servers
• NIC Settings
Address Management
To assign an Address to an Interface
1. Enter the Addresses via the Networking option of the Manager.

2. Scroll down to the interface you wish to change.
Note: Service interfaces (ethSRV1 to ethSRV8) can each be assigned up to 50 addresses.

AppWall User Guide
Introducing AppWall
3. Select Add an additional Address to add an IP in CIDR or IP notation format to the interface.
4. Select an existing IP address to remove, or disable it.
5. Select Blink to identify the interface. This will cause a LED on the NIC to blink.
Note: Changes to IP addresses are immediate.
Caution: Changes to the management IP (on ethMNG), while connected via SSH or Web
management, will cause the session to disconnect.
Route Management
The Default Route is an optional destination for Web traffic that does not belong to the LAN segment.
Request the Default Route address from your network administrator and set this parameter
accordingly. In this scenario of ADC deployment, the ADC functions as the AppWall Default Route.
The Default Route is an IP address (e.g., 172.16.8.12).
To configure the Default Route
1. From the Networking menu, select Route Management.

2. Type in the IP address of the router of your local area network.
Management Default Route

The Management Default Route is an optional destination for the management traffic that does not
below to the LAN segment. AppWall management application traffic as well as the CLI and Web
interface traffic which is sent to the device is marked and will be routed back to the client only from
the ethMNG interface through the Management Default Route.
To configure the Default Route
1. From the Networking menu, select Management Default Route.

2. Type the IP address of the router of your local network.
Domain Information
In order for the appliance to resolve Internet name addresses, you may configure DNS (domain
name server), which provide name resolution.
The domain name should be a domain name for your local network (e.g. Radware.com,
math.mit.edu, etc) and the Name servers should be IP addresses.
The appliance can belong to one domain and search an additional three domains. The appliance can
also use up to three DNS servers for name resolving.

AppWall User Guide
Introducing AppWall
From this point forward, the system can be managed using an SSH connection. Your appliance is
ready for remote configuration using the Management Console.
Note: This is required only if using domain names as well as IP addresses.
To configure the Domain Name and Name Server
1. Select Networking > Domain Information from the main menu

2. Select Add a Name Server to add additional domain name servers.
3. Select search domain from the list and click Enter to delete
4. Select Add a Search Domain to add additional search domains (Optional)
5. Select Default Domain to set the default domain for the Appliance. If none defined click Enter
to add.
Time Servers
The appliance can serve as an NTP client and as a Server.
To Configure Time Servers
1. Select Time Servers from the Networking menu.

2. Select Enable time update at boot to synchronize the system on every reboot.
3. Select Enable periodic time updates to allow for automatic periodic time updates.
4. Select Name of time server to change the name of the server (the user may type in a new
name or click enter to keep the current name server).
5. Select Update system time to synchronize the system time.
Note: To activate time service, open UDP port 123 on all firewalls between the AppWall host
and the remote time server with which you wish to synchronize.
NIC Settings
Devices that share a link segment are automatically configured with the highest performance mode
of interoperation. The auto negotiation activity exchanges information between two devices and is
performed out-of-band to identify the highest physical-layer technology that can be used by both
devices.
The auto negotiation also provides a parallel detection function that allows the speed of the link to
be established.
Note: When the NIC is operating on a 100BaseT/Full connection with Auto Negotiation – Off,
the appliance will fail to negotiate the correct speed and duplex mode. In this case, the
NIC will often use a 100BaseT/Half setting.

AppWall User Guide
Introducing AppWall
To change the NIC Settings
1. Select NIC Settings from the Networking menu. In the displayed screen, select the Network
Interface to change and press Enter.
2. Select the speed and type of duplex to use and click Enter.
3. To revert to the default setting, select AutoNeg: ON from the list and click Enter.
Note: The Link On/Link Off displays the current status of the connection. If there is no
connection the Link Off displays.
Caution: Be careful, when changing the connectivity on ethMNG. This may result in the loss
of the link, which will require physical intervention.
Network Configuration
The appliance has 4 network interfaces and 2 dedicated management interfaces. Each interface you
can add up to 50 IP addresses.
Notes
>> When connecting a network cable to one of the network interfaces, an indication is
displayed to the user as to which interface the cable is connected.
>> Management of the machine can only be performed through the ethMNG interface.
The AppWall Command Line Command

Additionally, you can manage the AppWal services by textual commands.
Table 8 includes a list of commands that can be used to manage the AppWall server processes from
the command line.
To manage AppWall Server processes on a Command Line system
• Use the AppWall command line, as described in the following table:
Table 8: Command Line Commands
Name AppWall
Description Command-line function that allows you to run the various AppWall components,
as well as starting, stopping, and displaying the status of AppWall services
(processes).
Syntax AppWall OPTION SUBSET
Parameters OPTION: start | stop | status | console | -h

AppWall User Guide
Introducing AppWall
Table 8: Command Line Commands
Name AppWall
start Starts the component specified in SUBSET, if supplied.
Otherwise, starts the AppWall Server.
Stop Stops the component specified in SUBSET, if supplied.
Otherwise, stops the AppWall Server
status Displays the current running status of the component specified
in SUBSET, if supplied. Otherwise, displays the status the
AppWall Server.
-h Displays this main page.
Parameters SUBSET all | server | publisher
all Applies OPTION to AppWall Server and AppWall Publisher.
server Applies OPTION to AppWall Server.
publisher Applies OPTION to AppWall Publisher.
Examples AppWall start all Start all AppWall components.
AppWall status Displays the status of the AppWall Server.
AppWall –h Displays the help file on the AppWall command line function.
Management Tools - Management Console/Web Interface

The Management Console is the Web interface application for system configuration and
management. The application is available by pointing the browser to the Management IP, using
HTTPS protocol (port 443), e.g. https://10.0.0.185.
When you log into the system, (default user\password is admin\radware), you will be presented
with the Management Console screen. The following selectable options are provided to manage the
AppWall:
System Information
• View/Change Status
• Performance
• Appliance Logs
System Configuration
• Settings
• Interfaces
• Backup/Restore
• User Access
Knowledge Base
• Help
• EULA

AppWall User Guide
Introducing AppWall
For further information about working with the Management Console, see the Online Reference
guide (accessed from the Help menu in the Web interface).
Note: AppWall web interface help doesn't display right pane in Google Chrome browser
Licenses
The licensing mechanism is used to provide an easy path for adding product capabilities after initial
product purchase. AppWall licenses are available for Gateway, Monitor, and Cluster versions.
AppWall supports the following licensing modes:
• Platform-based—With limited out-of-the-box bandwidth, which is platform-dependent.
• Throughput-tiered—Enables deployment of platform scalable solutions with a pay-as-you-
grow pricing model.
AppWall VA
The same licensing modes apply for AppWall VA.
For more information, see AppWall Virtual Appliance, page 124.
Note: Please also see the Radware Licensing Model for further information.
Before Installation and Configuration

Before installation, Radware recommends you take into consideration the following:
• Radware Platforms Supported, page 59
• Physical Connectivity Concerns, page 59
• IP Allocation Concerns, page 60
• Management Concerns, page 60
• Technical Support, page 60
Radware Platforms Supported

AppWall supports the following Radware platforms:
• OnDemand Switch VL
• OnDemand Switch 1 XL
For further information, see the Radware Installation and Maintenance Guide.
Physical Connectivity Concerns

A Radware device acts as a switch. Crossed cables should be used between switches and straight
cables should be used for connecting other network hosts. Make sure you use the right type of cable
as stated. Some platforms support the Auto sensing feature (MDIX) and can operate with any type
of cable, however this feature is disabled once you disable Auto negotiation.
Only GBICs that have been tested and approved by Radware can be used. For an updated list, refer
to: http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp.

AppWall User Guide
Introducing AppWall
Auto negotiation is activated by default. In most cases, this is the preferred option. Verify that it is
activated on the other side as well.
Note: Disabling Auto negotiation also disables the cable type Auto sensing feature (MDIX).
Optical cables are not provided by Radware and need to be purchased separately. Some devices use
SC connectivity and LC. Make sure you have the appropriate cable.
The copper cables that Radware provides are intended for management only and should not be used
for other types of traffic. CAT5 certified copper cables must be used.
When connecting to network switches and working with Radware's proprietary redundancy protocol,
ensure that you disable Spanning Tree or at least enable Port Fast on the relevant ports (on the
switch). You can also set the Spanning Tree to operate in fast learning mode on the relevant ports.
IP Allocation Concerns
Ensure that you have the IP addresses allocated and defined in your network for the AppWall's
interfaces, new servers, NAT IP addresses (if activated on the AppWall), DNS IP addresses (if
activated on the AppWall) and for the redundant AppWall as well.
Pay particular attention to the Local Triangulation implementation and VLANs (explained in this
document) where the IP addresses of the servers should be public routable IP addresses.
Management Concerns
Radware management uses SNMP communication running on UDP port 161. Ensure that this
communication port is not blocked by your firewall.
Radware devices also use HTTP, HTTPS, Telnet, and SSH for management. If you choose to activate
one of the above, verify that they are not blocked by your firewall. Traffic direction is from the
management system to the Radware device. Radware devices have a console port for terminal
communication. This uses an RS232 cable (provided by Radware).
Technical Support
Radware offers its Certainty Support Program, a suite of technical support packages in various
levels. You can view all programs at: http://www.radware.com/content/support/default.asp.
Once you purchased the relevant Certainty Support package you can either contact Radware via
email (support@radware.com) or via the phone using our worldwide toll free numbers. An updated
list is available at: http://www.radware.com/content/support/support program/contact.asp.
Additional information about the Radware Certainty Support program is available at: http://
www.radware.com/content/document.asp?_v=about&document=2774.

AppWall User Guide
Installing and Configuring AppWall
Chapter 3 – Installing and Configuring AppWall

This chapter assumes that you have already installed the AppWall Management Application, and
either the AppWall Gateway or AppWall Cluster Manager. For more information on installing these
components and installing the license from either the Gateway or the Cluster Manager, see the
Radware Installation and Maintenance Guide.
The Radware Installation and Maintenance Guide also includes procedures for mounting and
installing the AppWall device, as well a technical specifications.
System Startup
Upon system startup, you will be provided with the following options:
• Normal—Normal login brings you directly to the CLI Manager.
• Backup—Boot to the backup partition. Allows for a recovery of the main system partition.
Caution: This is important as OS backups are set to a different partition. When restoring the
backup of the OS, the backup file on the different partition countermands the current
OS. Use caution when restoring a backup of the OS so that important information is
not lost.
• Maintenance—Allows root login to the machine & shell access. This option provides a verbose
boot with all Linux and appliance indications.
Note: Booting into any mode other than Normal requires a password. The default password is
Radware.
To enter the CLI Manager screen through Maintenance

1. Select Maintenance from the menu.
2. Enter the following root login information: user: root, password: <same as admin password>,
(default is radware).
3. Type manager in the displayed screen. The CLI Manager is displayed.
Initial Configuration
This section describes the initial configuration steps that should be performed before proceeding
further with the configuration of your Security Policy. This section includes the following:
• Managing Servers, page 62, describes how to add and manage AppWall Servers via AppWall
Management Application.
• Defining a Cluster Server Configuration, page 67, describes how to set up a Cluster
configuration.

AppWall User Guide
• Managing Users, page 70, describes how to manage the users that have access to each AppWall
Server.
• Working With Certificates, page 78, describes how to view and create certificates, which are
used to verify the authenticity of the sender of a request.
• Working with Tunnels, page 87, describes how to work with Tunnels, including how to add An
HTTP/HTTPS or TCP tunnel.
• Defining Console-Server Connections, page 108, describes how to configure remote Console
connections.
• Defining the Escalation Server List, page 115, describes how to define a list of AppWall Servers
upon which to apply Escalation rules.
Once you have completed the above basic steps, Radware recommends that you review the
appropriate section to get started with the Management Application.
Managing Servers
AppWall Management Application provides you with centralized control over all remote AppWall
Servers that are configured. You can connect and configure as many AppWall Servers as you
require, depending on your network topology.
This subsection also includes how to add a Cluster Manager server; if you are working with a Cluster
configuration, see the appropriate section.
The initial AppWall Server configuration consists of one Server Group, called AppWall Server Group
and one AppWall Server called Local Host (if a server is running on a local machine). You can add
additional Server Groups, rename or remove them.
Managing Servers includes the following:
• Adding an AppWall Server, page 63
• Adding a Cluster Manager, page 64
• Logging In and Logging Out, page 64t
• Deleting/Renaming an AppWall Server, page 65
• Adding/Renaming/Deleting a Server Group, page 65
• Setting the AppWall Management Application Connection to an AppWall Server, page 67r
For additional, more advanced server configuration options, see the relevant section.

AppWall User Guide
Adding an AppWall Server
To add a Server
1. In the Configuration view, right-click the Server Group to which you want to add the AppWall
Server and select Add. The following dialog is displayed.
2. In the Add a Server dialog box, select the type of AppWall Server that you want to add.
3. Enter the Server IP (the AppWall Server's IP address for incoming configuration requests) and
Admin Port fields (the AppWall Server listening Port for incoming configuration requests).
4. Select the Use an Encrypted connection checkbox to use an encrypted connection between
the AppWall Server and the AppWall Management Application.
5. Click OK.
Notes
>> The Port number assigned should not be used by any other applications. The installation
uses 8200 as the default port for an AppWall Gateway.
>> The AppWall Management Application attempts to connect to the AppWall Server using
the information provided.
>> To add an AppWall Server to the Management Application, the AppWall Server must be
configured to accept connections from the AppWall Management Application. For
instructions, see Setting the AppWall Management Application Connection to an AppWall
Server, page 67.

AppWall User Guide
Adding a Cluster Manager

This section describes how to add an AppWall Cluster Manager, the main cluster server that controls
the configuration of AppWall Server nodes. Note that this procedure is only relevant for a Cluster
Server configuration. For information on setting up the Cluster Manager and its nodes, see Defining
a Cluster Server Configuration, page 67.
To add a Cluster Manager
1. In the Configuration view, right-click the Server Group root node and select Add Cluster
Manager.
2. In the Add a Cluster Manager dialog box enter the Server IP (the AppWall Server's IP
address for incoming configuration requests) and Admin Port (8270 - the AppWall Server
listening Port for incoming configuration requests) fields.
3. Click OK.
Note: The Port number assigned should not be used by any other applications.
Logging In and Logging Out

To perform most procedures, you must be logged in to the AppWall Server as an Administrator.
To log in to the AppWall Server
1. In the Configuration view, expand the Server Group and select the AppWall Server.
2. On the AppWall Management Application toolbar, click Login.
3. Enter your User Name and Password and click OK (if users are currently created for the
server). Or Log in as Administrator and create a new user.
To log out of the AppWall Server
1. In any view, expand the Server Group.

2. On the AppWall Management Application toolbar, click Logout.
To log in to the AppWall Cluster Manager and Cluster nodes
1. In the Configuration view, expand the Configuration Manager folder and select the AppWall
Server.
2. On the AppWall Management Application toolbar, click Login.
3. Enter your User Name and Password and click OK.

AppWall User Guide
Note: You must use the same User Name and Password for both the Cluster Manager and its
nodes.
Deleting/Renaming an AppWall Server

Deleting an AppWall Server permanently removes the AppWall Server from the group.
To delete a Server
In the Configuration view, right-click the AppWall Server and select Remove.
To rename a Server
1. In the Configuration view, right-click the Server and select Connection Settings. The following
screen is displayed.
2. In the Name field enter a new name.

3. In the Description field, enter a new description for new Server
4. Enter the IP Address and Port for the Server, if necessary.
5. Click OK.
Adding/Renaming/Deleting a Server Group

Adding Server Groups to AppWall Management Application allows you to create a logical network
topology, organizing groups in a variety of ways: by application, location, or user privileges.
Note: Before deleting a Server Group, you must delete any AppWall Servers under it.

AppWall User Guide
To add a Server group
1. In the Configuration view, right-click Console at the top the Configuration tree and select New.
The following screen is displayed.
2. In the Add a New Server dialog box enter the new group name.
3. In the Description field, enter a description for the new group, and click OK.
Note: A Server Group must contain at least one AppWall Server.
To rename a Server Group
1. In the Configuration view, right-click the Server Group and select Rename.
2. In the Group Name field enter a unique name.
3. In the Description field enter a description for the new group.
4. Click OK.
Notes
>> Changing the name of a Server Group does not affect the subordinate security
definitions, such as AppWall Servers and Web Applications.
>> Changing the server name is only logical and does not affect the AppWall Hostname
To delete a Server Group
In the Configuration view, right-click the Server Group and select Remove.

AppWall User Guide
Setting the AppWall Management Application Connection to an AppWall Server
To determine AppWall Management Application-Server connection properties
1. In the Configuration view, expand the Server Group, right-click the AppWall Server and select
Connection Settings.
2. On the Console Connection Properties dialog box, modify the Display Name, Server IP,
Encrypted Conn, and Admin Port fields as necessary.
3. Click OK.
Defining a Cluster Server Configuration

A Cluster Manager enables you to deploy your AppWall Servers in a cluster arrangement. From a
single Management Application, which is connected to the Cluster Manager, it is possible to manage
relevant changes to your Security Policy across a number of AppWall Servers, meaning that changes
and updates are applied once in the Management Application but are effectively applied to all
AppWall Servers in the cluster.
This section describes how to work with a Cluster Manager and its AppWall Server nodes, and
includes the following:
• Setting up your Cluster Configuration
• Forcing the Cluster Synchronization
• Viewing the Cluster Dashboard and Forensics
• Backing up the Cluster Configuration
Setting up your Cluster Configuration

This following describes how to set up your Cluster configuration from AppWall Management
Application, including how to assign Tunnels to all the AppWall Server nodes under the Cluster
Manager.
To setup your Cluster configuration
1. Add a Cluster Manager server, as described in the Adding a Cluster Manager section.
2. Login to the Cluster Manager (indicated by the icon in the Management Application), as
described in the Logging In and Logging Out section.
Note: The User Name and Password should be the same for the Cluster Manager and each of
its AppWall Server nodes.
3. Add AppWall Server nodes as required by right-clicking on the Configuration Manager folder
and selecting Add. The Add a Server window is displayed (see Adding an AppWall Server,
page 63).

AppWall User Guide
4. Once you have completed adding AppWall Server nodes, expand the Cluster Manager server to
display the subfolders.
Note: The Configuration Manager folder is unique to the Cluster Manager Server and lists all
the AppWall Server nodes in your Cluster configuration.
5. Add the Tunnels that you want to use for all of the Cluster Manager nodes using the Tunnel
wizard, (note that each Tunnel should be assigned to all Cluster nodes).
6. After adding a Tunnel, it is listed under the relevant HTTP, HTTPS or TCP folder.
7. Click on the relevant Tunnel and in the Tunnels State tab you can view a list of the AppWall
Server nodes to which the Tunnel is assigned.
8. Double-click the relevant AppWall Server node, or select it and click Edit, to display the Assign
Tunnel dialog box. Modify the Listening and Forwarding IP Addresses and Listening TCP Port
setting as required, and click OK. Then click Save.
Notes
>> Changes applied in this way override any settings listed for the Tunnel in the
Configuration Manager folder. Once applied, they are immediately updated in the
Tunnels tab of the relevant AppWall Server node you select under the Configuration
Manager.
>> You can also modify the AppWall Server node’s default IP by selecting the Configuration
Manager folder and in the displayed list of AppWall Server nodes, double-clicking the
relevant node. In the displayed Edit Node dialog box, modify the default IP from the
drop-down list of available IPs for the node.
>> We need this Default IP because when we put a node into a cluster, there are several IPs
per node. This makes it difficult to define for many tunnels. To resolve this problem,
AppWall’s default IP acts as a listening IP address per tunnel.
9. Click Apply Changes. Your Cluster configuration is now setup and can be expanded at any
time.
Note: When adding nodes to the Cluster Manager, the auto-synchronization of the security
configuration is immediately started, including the restart of the AppWall Cluster service.
Any changes to existing nodes (such as their removal from the Cluster Manager) are
also immediately updated in the cluster.

AppWall User Guide
Forcing the Cluster Synchronization

If the synchronization of files between the Cluster Manager and its AppWall Server nodes fails, you
can force the synchronization for each node, as described in the following procedure.
To force Cluster synchronization
1. Click on the relevant AppWall Server node under the Configuration Manager folder.
2. In the Server Properties tab, click Force Sync (located in the Node Action Panel section).
3. Synchronization between the selected AppWall Server node and the Cluster Manager is
immediately activated, as indicated by the progress bar in the lower right corner of the
Management Application (this bar also displays synchronization activated from another
Management Application). The synchronization may take a few seconds to complete.
Viewing the Cluster Dashboard and Forensics

You can view Forensics for each of the AppWall Server nodes, just as you would for any regular
AppWall Server. See Working with Events for further details.
You can also view the Dashboard for the Cluster Manager as well as each of the AppWall Server
nodes. The only difference in information displayed is when selecting the Cluster Manager; the
Summary tab in the Dashboard is not available. See Working with the Dashboard for further details.
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.
Backing up the Cluster Configuration

Performing a regular backup of your Cluster configuration is recommended as standard operational
procedure. Backup, and restore, of your Cluster Manager Server can be performed as per any
regular AppWall Server, as described in the Backing up an AppWall Server Configuration and
Restoring an AppWall Server Configuration sections.

AppWall User Guide
However, due to the Cluster Manager’s role as the distributor of any Security Policy modifications to
other cluster nodes, it is important to ensure that when an AppWall Server node, or the Cluster
Manager itself, fails or is out of action for any length of time, the relevant server is updated with the
last known configuration by using the Restore feature.
Note: When updating a specific node’s configuration through the Management Application, the
next synchronization process run by the Cluster Manager will override the node’s
settings.
Managing Users
For each AppWall Server, you can grant access to users by assigning them to a user group. The user
group determines the tasks a user can perform when logged on to an AppWall Server.
This section includes:
• User Types and Privileges, page 70.
• Locally and Centrally Managed Users, page 70.
• Adding and Deleting Users, page 72
• Changing a User Group Assignment–for Administrators Only, page 73
• Unblocking a User, page 73
• Configuring Default Password and Login Settings, page 74
• Recovering the AppWall Password, page 74
User Types and Privileges

This section details the available user types and privileges for users logged in to an AppWall Server.
Table 9: User Types and Privileges
Type Privileges
Administrators Full administrative rights to the AppWall Server.
Viewers View the AppWall Server configuration and change your own password.
Application Owner Make changes only to the assigned Web Application
Viewer and Make changes only to the assigned Web Application and view properties of
Application owner all objects under the AppWall Server
Application Viewer View the Web Application assigned to the user.
Note: The first user added to the users list must be assigned to the Administrators group.
Locally and Centrally Managed Users

In AppWall, you can either create local users or manage them centrally through remote RADIUS or
LDAP authentication servers. Both Active Directory and OpenLDAP are supported through the LDAP
servers.
This section includes:
• User Authentication with LDAP and RADIUS, page 71
• Adding a RADIUS Server, page 71
• Authenticating a Group User with LDAP, page 71

AppWall User Guide
• Adding an LDAP Server, page 71
User Authentication with LDAP and RADIUS

RADIUS and LADP authentication schemes are supported for AppWall administrative users, letting
them associate AppWall users with LDAP or RADIUS users. The username and password are
validated against the external authentication server and are not stored or verified locally in the
AppWall server.
To manage your AppWall users through the remote authentication server, you must first configure
the LDAP or the RADIUS server.
Adding a RADIUS Server
To add a RADIUS server
1. In the Configuration view, open Management > Authentication Servers.

2. From the RADIUS tab, click Add to add a RADIUS server.
3. In the RADIUS Server dialog box, set the RADIUS server parameters.
4. Click OK.
Authenticating a Group User with LDAP

When authenticating users with an LDAP server, you can either authenticate a specific user or
associate an LDAP group with a group of AppWall users. Any user who is a member of the LDAP
group is handled according to the user type associated with the LDAP group.
For example, if you have an LDAP group named AppWall_Admins and you create an AppWall
group user named admin associated with AppWall_Admins, any LDAP user who is a member of
AppWall_Admins has administrator credentials after successful authentication.
Adding an LDAP Server
To add an LDAP server
1. In the Configuration view, open Management > Authentication Servers.

2. From the LDAP tab, click Add to add an LDAP server.
3. In the LDAP Server dialog box, set the LDAP server parameters.
4. Click OK.
Notes
>> The LDAP client-side module is integrated with the Active Directory.
>> AppWall can retrieve the membership of user groups (including contained groups) from
the LDAP server.
>> The AppWall LDAP client supports primary and secondary LDAP hosts.
>> The LDAP client-side module supports Global Catalogue binding.

AppWall User Guide
Adding and Deleting Users

This section describes how to add and delete users that have access to the AppWall Server.
Adding a User
To add a user
1. In the Configuration view, open Server Group > AppWall Server > Management and select
the Administrative Users node.
2. Click Add in the Content Area.
3. In the Add a New User dialog box, specify the following parameters:
Parameter Description
User Name Name of the user.
Group Set the group type. User privileges are based on the group type.
Values:
• Administrators—Full administrative privileges to configure the AppWall
Server.
• Viewers—Privileges to view the AppWall Server configuration and
change the viewer’s password.
• Application Owner—Privileges to change only the Web Application
assigned to the user.
• Viewer and Application Owner—Privileges to change only the Web
Application assigned to the user, and unrestricted Viewers privileges.
• Application Viewer—Privileges to view the Web Application assigned to
the user.
Type • Local
• LDAP Group—When you select LDAP Group, you must also select your
previously configured LDAP Server and use the LDAP Browser to select
your user or group.
• LDAP User—When you select LDAP Group, you must also select your
previously configured LDAP Server and use the LDAP Browser to select
your user or group.
• RADIUS
Password By default, passwords are strict. Passwords must have a length of 7 to 32
characters and must contain at least one letter, a digit, and a symbol,
~!@#$%^&*+=?<>. Simple passwords require only that the password
have a length of 7 to 32 characters.
Confirm Password Same as Password.
4. Click OK.

AppWall User Guide
Deleting a User
To delete a User
the Administrative Users node.
2. In the right pane, right-click the User and select Delete.
3. In the confirmation dialog box, click OK.
Changing a User Group Assignment–for Administrators Only

Change a user’s group to provide more/less access to the AppWall Server.
To change a User Group Assignment
the Users node.
2. In the right pane, right-click the User and select Change Group.
3. In the Change Group dialog box, select the group from the Group drop-down list.
4. To assign the user to either the Administrators or Viewers group, select the group and click
OK.
5. To assign the user to the Application Owner, Application Viewer, or Viewer and
Application Owner group, assign applications to the user.
6. Select an application from the List of Available Applications.
7. Click the right arrow to move the application to the List of Assigned Applications.
8. Click OK.
Unblocking a User
If a user login fails after a number of attempts, the user is “blocked” and cannot gain access until
the account is unblocked. Only Administrators can unblock a user.
To unblock a User
the Users node.
2. In the right pane, select the user and click Unblock.
Note: Administrators can configure the maximum number of login attempts after which a user
is blocked. For details, see the following section.

AppWall User Guide
Configuring Default Password and Login Settings

Administrators can change the default settings for password convention and the number of
unsuccessful login attempts before the system blocks users.
To configure default Password and Login settings
the Users node.
2. In the right pane, click the Advanced tab.
3. Modify the Block User After field.
4. Select the Simple or Strict password convention option and click OK.
To change a User Password
To change any password other than your own, you must belong to the Administrators group.
Users belonging to a Viewer Group can change only their own password.
To change any Password
the Users node.
2. In the right pane, right-click the User and select Change Password.
3. Complete the Old Password, New Password, and Confirm Password fields.
4. Click OK.
Note: By default, passwords are strict; they must have a length of 7-32 characters and must
contain at least one letter, a digit, and a symbol, ~!@#$%^&*+=?<>.
5. If the current password cannot be ascertained, delete the user and create a new one.
Recovering the AppWall Password
Symptoms
Unable to login to the AppWall Management Console.
Possible Reasons
1. Incorrect password
2. Account is locked
Solution
1. Use the administrator account to reset the account password.
2. Use the administrator account to unlock the locked account.

AppWall User Guide
When the Administrator Account is Locked Out

When the administrator account is locked out and there is no other account with administrative
privileges, do the following:
1. Reboot the AppWall and chose “AppWall maintenance mode" in the menu.
2. Login with 'root' user (generally the default password is 'Radware').
3. Stop AppWall Service.
4. Rename users.cfg file under /opt/Radware/Gateway/Config directory to
users.cfg.org.
5. Copy users.cfg file from /opt/Radware/Gateway/Backup/Default to Config
directory.
6. Start AppWall Service.
7. Login to AppWall Server using Security Console.
8. Create administrator account.
9. Create another account with administrative privileges.
10. Remember the administrator account password but use the second account created!
Note: When the AppWall device is a Cluster Manager, the folder is "DefianceCluster" and not a
"Defiance Gateway".
Managing Web User Roles

AppWall enables defining various types of Web-user roles:
IP Address and Geo-Location-based Roles, page 75
LDAP Roles, page 76
Combining Radius and IP Address-based Roles, page 77
Combining LDAP and IP Address-based Roles, page 77
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.
Examples:
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 > Management > IP Groups menu. 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.

AppWall User Guide
Figure 31: 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.
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.

AppWall User Guide
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 32: Add Role Window
Examples:
1. 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.
2. 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).
3. You can also configure a “monitor only” policy for administrators when accessing from trusted
remote geographies (e.g., from the UK).
4. You can prohibit access to your application for any user (including LDAP “Admin” users) who is
accessing from a non-trusted location (e. g., from North Korea).

AppWall User Guide
Working With Certificates

This section describes how to work with certificates, which are used to verify the authenticity of the
sender of a request. Certificates are issued from a trusted Certificate Authority (CA). The CA issues
the certificate containing the subject’s public key and some other information, such as name and
address of both the CA and the subject.
Note: You can import/export/ certificates to a file to transfer them between AppWall Servers.

• Viewing Personal Certificates, page 78
• Creating Certificates, page 79
• Importing and Exporting Certificates, page 79
Figure 33: Configuring Certificates
Viewing Personal Certificates

The Personal – Server node represents a store that includes certificates and associated keys. These
certificates include server certificates and authorization certificates.

AppWall User Guide
To view a list of all personal certificates
1. In the Configuration View select the Server Group > AppWall Server > Management >
Certificates > Personal Server node.
2. Select the Certificates tab. A list of all personal certificates is displayed. Each row of the list
represents one certificate. The columns in the list are as follows:
Issued By The issuing authority of the certificate.
Issued To The entity to which the certificate was issued.
Expiration Date The expiration date of the certificate.
Serial Number The serial number of the certificate.
3. Double-click a certificate to see more information about that certificate, including General
information, such as the serial number and start/end date, and Issuer information, such as the
country and locality of the issuer.
Creating Certificates
To create a new certificate
1. Click Create while on the Certificates tab.

2. Enter the certificate common name in the dialog box that appears.
3. Click OK. The new certificate is added to the certificates list on the Certificates tab.
Deleting Certificates
To delete a certificate
Right-click the certificate and click Delete. Certificates currently used by Tunnels cannot be
deleted.
Importing and Exporting Certificates
To export a certificate
1. Select a certificate while on the Certificates tab.

2. Click Export. An Export dialog box appears.
3. Select the file format for the exported certificate. If you select Personal Information
Exchange - PKCS # 12 format, you must also enter and confirm a password for the certificate.
4. Enter the file name for the certificate. The file name must be a simple file name without a path.
The file will be saved in the AppWall Server certificates export directory /Certificate/export.

AppWall User Guide
5. Click OK when you are finished.
To import a previously exported certificate
1. Click Import while on the Certificates tab. An Import dialog box appears.
2. Select the format of the certificate you are importing.
3. If you select Personal Information Exchange - PKCS # 12, you must also enter the
password that was entered when saving the certificate. Otherwise, you must enter the path and
file name of the private key data file.
4. Enter the path and file name of the certificate file. The import can be done from a file on the
local machine or the server machine (in the Certificate/Import directory).
5. Click OK to finish.
Creating a New Authorized Certificate

To request a new certificate from a Certificate Authority (CA), you must create a full request, and
then pass your request information to the CA. After receiving the certificate information from the
CA, you complete the certificate by loading the certificate information.
To create a new authorized certificate:
1. Click the Certificate Request tab.

2. Click Create a Certificate Request. A new request form appears.
3. Select the desired encryption format and key size. Enter all other information as required,
including the common name for your company.
4. Click OK. A file name, and possibly a request string are displayed in a dialog box.
5. Copy and send this information to the CA according to whatever renewal instructions they
provide.
6. After the CA sends to you the certificate information, store the information in a file on the server
machine, and then load the information by selecting the request entry and clicking Process the
Pending Request.
7. Enter the location of the file and click OK.
Renewing an Authorized Certificate

When a certificate expires, you can renew the certificate using the AppWall Management Application.
The system applies the original request details in the application for renewal. You can only renew the
certificate when there is no other pending SSL request.
To renew a certificate
1. Select the certificate and click Renew. A renew dialog box appears.
2. Select the format for the renewed certificate and click OK. A file name and possibly a request
string, are displayed in a dialog box.
3. Copy and send this information to the CA according to whatever renewal instructions they
provide.

AppWall User Guide
4. After the CA sends to you the certificate information, store the information in a file, and then
load the information by selecting the request entry and clicking Process the Pending
Request.
5. Enter the location of the file and click OK.
Importing and Exporting Validation - Authorization Certificates

The Validation - Authorization certificates are certificates for which you do not have a key.
To export a Validation - Authorization certificate:
1. Select the certificate and click Export. An Export dialog box appears.
2. Select the file format for the certificate. If you select Personal Information Exchange - PKCS
#12 format, you must also enter and confirm a password for the certificate.
3. Enter the file name for the certificate. The file name must be a simple file name without a path.
The file will be saved in the AppWall Server certificates export directory /Certificate/export.
To import a Validation - Authorization certificate:
1. Click Import while on the Certificates tab. An Import dialog box appears.
2. Select the format of the certificate you are importing.
3. If you select Personal Information Exchange - PKCS # 12, you must also enter the
password that was entered when saving the certificate. Otherwise, you must enter the path and
file name of the private key data file.
4. Enter the path and file name of the certificate file. The import can be done from a file on the
local machine or the server machine (in the Certificate/Import directory).
Deleting a Validation - Authorization Certificate
To delete a Validation - Authorization Certificate:
1. Right-click the certificate and click Delete. Certificates currently being used by Tunnels cannot
be deleted.
Managing Certificate Revocation

The certificate revocation feature allows you to import certificate revocation lists which refine client
certificates.
To import a certificate revocation list
1. Click the Certificate Revocation List node under Management > Certificates.
2. Click Import.

AppWall User Guide
3. In the dialog box that appears, select the format and file location, and click OK.
To export a certificate revocation list
1. Select the certificate revocation list and click Export.

2. Select the format and enter a file location and click OK.
To To delete a certificate revocation list
1. Select the certificate revocation list and click Delete.
Certificate Requests
• Requesting a Demo Certificate, page 82
• Processing a Pending Certificate Request, page 83
• Show the Pending Certificate Request, page 83
• Delete a Certificate Request, page 84
Requesting a Demo Certificate

To request a new certificate from a Certificate Authority (CA), you must create a full request, and
then pass your request information to the CA. After receiving the certificate information from the
CA, you complete the certificate by loading the certificate information.
To request a demo certificate
2. Click the Certificate Request tab.
3. Click Create a Certificate Request. A new request form appears.
4. Select the desired encryption format and key size and enter all other information as required,
including the common name for your company.
Format Values:
• Base-64 encoded X.509 (PEM)
• DER encoded binary X.509 (.ASN1)
Key Size Larger key sizes offer an increased level of security. We recommend that
certificates have a key size of 1024 bits or more. Using a certificate of
this size makes it extremely difficult to forge a digital signature or decode
an encrypted message. Select from (Bytes):
• 512
• 768
• 1024
• 2048

AppWall User Guide
Country Organization country.
State State or province.
Locality Name of the city.
Postal Code Postal Code of organization.
Telephone Telephone number of organization.
Email Address Any email address that you want to include within the certificate.
Organization Name of the organization.
Organization Unit Department/ Unit within the organization
Common Name The domain name of the organization. For example, www.radware.com
Processing a Pending Certificate Request
To process a pending certificate request
2. Click the Certificate Request tab. A list of existing certificate requests will appear.
3. Click the Process the Pending Request tab. A dialog form appears.
4. Enter the file location.
Figure 34: Process the Pending Request Dialog
Note: Please verify that the path entered in File location includes the file name.
Show the Pending Certificate Request
To show a pending certificate request
2. Click the Certificate Request tab. A list of existing certificate requests appears.
3. Click the Show the Pending Request tab. A Request Information pane appears.

AppWall User Guide
Figure 35: Certificate Request Information
Delete a Certificate Request
To delete a pending certificate request
2. Click the Certificate Request tab. A list of existing certificate requests will appear.
3. Click the Delete the Pending Request tab. A confirmation is displayed as shown here.
Figure 36: Pending Request Removed

AppWall User Guide
Generating SSL Certificates using AppWall Certificate Request
To create a Certificate Request
1. Go to Management > Certificates > Personal Server > Certificate Request. The Request
Information dialog appears.
2. Backup the Configuration.
3. Copy the file into /Certificate folder in the AppWall file system.

AppWall User Guide
4. Process the Pending Request as described.
5. Get the Status Message.

AppWall User Guide
6. Perform Apply Changes and Refresh.The generated certificate appears under the
Certificates tab.
Working with Tunnels

This section describes how to manage Tunnels via the Configuration view. You can add three types of
Tunnels: HTTP, HTTPS, and TCP. This section includes the following:
• Adding a Tunnel, page 88
• Modifying HTTP and HTTPS Tunnel Properties, page 90
• Modifying TCP Tunnel Properties, page 105
• Setting Tunnel Operation Modes, page 107

AppWall User Guide
• Viewing and Changing the Current Operation Mode of a Tunnel, page 107
Adding a Tunnel
This describes how to add a new HTTP, HTTPS or TCP Tunnel.
To add a new Tunnel
1. In the Configuration view, expand Server Group > AppWall Server > Tunnels.
2. Right-click the HTTP/HTTPS/TCP Tunnel node and select Wizard.
3. Complete the wizard fields using the table shown here.
Tunnel Type Choose the Tunnel type: HTTP, HTTPS, or TCP
Name Name of the Tunnel to be displayed in the console.
Codepage Encoding Name of the language codepage. If using a different language, select the
Scheme (HTTP or appropriate codepage from the drop-down list. For details, see Code
HTTPS) Pages, page 283.
Note: This option is not available for TCP Tunnels.
Untrusted Zone Properties
Listening IP Address Enter the listening IP address and port on which the AppWall tunnel
and Port listens. In a standalone deployment it will usually be the web application
public IP, while in ADC deployments, it will be the internal AppWall real
server IP.
Note: You can only enter an IP address that has been previously defined
for a device interface using either the CLI Manager (see Address
Management), or AppWall for Web Based Management. If you do not see
the IP address defined for the device interfaces in the drop-down list,
click Load IPs at the bottom-right of the window to refresh the displayed
IP list.
Trusted Zone Properties
Forwarding Address Enter the private IP address of the internal NIC interface of your AppWall
Server. This interface is used to forward the request to the Web Server if
the request is not blocked.
Note: You can only enter an IP address that has been previously defined
for a device interface using either the CLI Manager (see Address
Management), or AppWall for Web Based Management. If you do not see
the IP address defined for the device interfaces in the drop-down list,
click Load IPs at the bottom-right of the window to refresh the displayed
IP list.
Protected Entity The entity designated to be protected by the AppWall Server.
Protected Type Select the Protected Type (Web Server or Web Farm) from the drop-down
menu. TCP Tunnels only support Web Servers.
Protected Object Select the object (name of the Web Farm or Web Server) from the drop-
down menu. Click New to add a new Web Server.
Note: You can only add Web Servers with a protocol setting that
matches the Tunnel type, e.g. in an HTTP Tunnel you can only add Web
Servers with HTTP protocol setting.

AppWall User Guide
Virtual Hosts (HTTP Host values included in the HTTP header of a request (Host: HostName).
or HTTPS only) 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.
SSL Tunnel Mode The SSL Tunnel mode.
(HTTPS only) Values:
• SSL-Clear—Indicates that after decrypting a request, the request is
passed to the Web Server unencrypted.
• SSL-SSL—Indicates that a decrypted request is re-encrypted before
being passed to the Web Server.
Certificate (HTTPS Select the certificate to use from the available list of certificates, if any
only) have been defined.
Max Pending Maximum number of incoming requests that can wait for an available
Connections session.
Max Active Maximum number of active connections (network sessions) at one time.
Connections
Idle Session Amount of time an inactive session can remain idle before being dropped.
Timeout
4. Click Save, and on the AppWall Management Application toolbar, click Apply Changes.
5. The service restarts in the background. For HTTP, the service restart is transparent; the client is
not affected unless the restart causes a browser timeout. For HTTPS, the service restart causes
a renewal of the handshake process.
6. After a Tunnel has been created you can then set default values used by all newly created HTTP
or HTTPS Tunnels.
To set default Tunnel values
1. In the Configuration view, expand Server Group > AppWall Server > Tunnels and select the
desired Tunnel type.
2. In the right pane, click the Default Client Request or Default Server Request tab and
modify the values used to set the maximum on message components. For example, you can set
the maximum length allowed for a request (URL) or status line, or the maximum length of the
entire HTTP Header of a request.
Note: For further information regarding the settings available, refer to the Online Reference
guide (accessed by pressing F1 from within AppWall Management Application).
3. To set limits on a specific header, click Add and then specify the header name and maximum
size.
4. Click Save, and on the AppWall Management Application toolbar click Apply Changes.

AppWall User Guide
Modifying HTTP and HTTPS Tunnel Properties

You can change the various properties of a Tunnel. This is ideal if IP configurations need to be
updated or if you want to disable the Default Web Application support for all requests received on a
Tunnel's connection.
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, expand Server Group > AppWall Server > Tunnels > Tunnel
Type and select the Tunnel to be modified.
2. In the right pane, click each tab and modify the Tunnel properties as required.
a. TCP Properties tab—Modify settings as required, such as the Listening Address and TCP Port
for the Untrusted Zone properties.
b. General Properties tab—Modify settings as required, such as the name of the tunnel or
enable/disable Auto Policy Generation.
c. Host Name tab—Modify settings as required, namely the Host (Virtual Host) names which
are name values used in the HTTP Header: Host=HostName
d. SSL Properties (HTTPS only) tab—Modify settings as required, namely the Server certificate
and connection properties.
e. Client Certificate (HTTPS only) tab—Modify settings as required, such as whether or not to
use a client certificate.
f. HTTP Properties tab—Modify settings as required, such as enabling the support of High-
ASCII Characters (127-255).
g. Parsing Properties tab—Modify settings as required, such as Ignore empty header names.
h. HTTP Message Size tab—Contains Client Request and Server Reply settings where you can
modify the line, the body, headers or a single header.
i. Security Bypass tab—Modify settings as required, such as the file extensions that indicate
file types for which this feature should be applied.
TCP Properties
You can change the various properties of a Tunnel. This is ideal if IP configurations need to be
updated or if you want to disable the Default Web Application support for all requests received on a
Tunnel's connection.
Type and select the Tunnel to be modified.
2. In the right pane, click each tab and modify the Tunnel properties as described in the tables
below.
Tunnel Mode
Transparent Original source IP address of the client is preserved and forwarded to the
(Preserve Client IP) web server.
Note: For Application processing or logging, enabling the Transparent
mode will enable retrieval of the original source IP from the TCP
connection.

AppWall User Guide
Reverse Proxy Source IP address of the TCP connection from AppWall to the web server
(default) will be the Forwarding IP address defined in the tunnel.
Note: For web server logging only purposes you can also activate the
X-Forwarded-For header setting to add the client source IP
address.
Name (TCP Tunnel Name of the Tunnel to be displayed in the Console.
only)
Listening Address The public IP address on which the AppWall Server listens. This is the
published IP address of the Web Server, and in actuality is the public NIC
interface of the AppWall Server.
Listening TCP Port The public IP port on which the AppWall Server listens.
This is the published port of the Web Server (usually port 80), and in
actuality is the port for the public NIC interface of the AppWall Server.
Note: You can only enter an IP address that has been previously
defined for a device interface using either the CLI Manager, or
AppWall for Web Based Management.
Max Pending Maximum number of incoming requests that the Tunnel can queue for an
Connections available session.
Max Active Maximum number of active connections (network sessions) at one time.
Connections
Network Threads Number of network threads allowed.
(TCP Tunnel only)
Forwarding Address The private IP address of the AppWall Server used to forward unblocked
requests to the Web Server.
Idle Session Amount of time an inactive session can remain idle before being dropped.
Timeout
Protected Entity
Protected Type Select the Protected Type (Web Server Interface or Web Farm) from the
drop-down menu.
TCP Tunnel only supports Web Server Interfaces.
Protected Entity Select the object (name of the Web Farm or Web Server Interface) from
the drop-down menu. Select New from the drop-down menu to add a
new Web Server Interface.
For TCP Tunnels you can only select Web Server Interfaces.

AppWall User Guide
General Properties
General
Include this Tunnel When enabled, instructs the Tunnel to use the Default Web Application to
in the Default Web evaluate requests. By definition, any requests not matching those
Application specified by existing definitions (Virtual Host, Application Path) are
evaluated by the Default Web Application.
Note: The Web Application itself must be enabled to receive the
requests that are rolled-over. If the Tunnel has not been added
to the Default Web Application, or if the Default Web Application
is disabled, the request is treated as invalid. New Tunnels are
automatically added to the Default Web Application.
Auto Tunnel Settings The tunnel object has different settings that require optimization and
Optimization 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: Note: Auto Discovery must be enabled for the Auto Tunnel
Settings Optimization to function.
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 This setting determines how the AppWall Server 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, the AppWall Server 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 the AppWall Server 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.

AppWall User Guide
Maximum Active Maximum number of active connections (network sessions) at one time.
Connections
X-FORWARDED-FOR This allows the user to add the IP Address of the client to the request
Header header.
Notes: 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.
In order to activate this functionality the next line should be
added to the <InternalParams> section in the comm.cfg file,
where the header name from which to retrieve the client IP is
the element value (in this example X-Forwarded-For):
<GetUserIPFromHTTPHeader>X-Forwarded-For</
GetUserIPFromHTTPHeader>
Action Check the box to add the X-FORWARDED-FOR header and delimiter to
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. e.g. *.micro*.*
SSL Properties (HTTPS only)
Server Certificate Properties
SSL Tunnel Mode The method in which the Tunnel handles the request after decrypting.
Possible values are:
• SSL-Clear indicates that after decrypting a request, the request is
passed to the Web Server unencrypted.
• SSL-SSL indicates that a decrypted request is re-encrypted before
being passed to the Web Server.
If you have chosen a certificate, you can also:
• View more information about the certificate: click View Certificate.
• Change the certificate, if more than one is available: click Change
Certificate, select a new certificate, and click OK.
• Send various certificates that compose a certificate chain from the
Certification Authority: select Build Certificate Chain.
SSL Connection Properties

AppWall User Guide
Cipher Strength Set the level of encryption used by selecting the encryption level from
the drop-down list.
Initialization String This setting which allows blocking of Cipher suites by selecting the
desired Cipher suite from the list has been added to HTTPS Tunnels. This
new setting also allows selecting the Cipher Strength for the SSL
connection from a drop-down list. Options are: All, Export, Low, Medium,
and High. In addition this setting allows entering a customized Cipher
string instead of selecting it from the Cipher Strength drop-down list.
Additional explanations on custom Cipher Strength settings and their
meanings, refer to:
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
Disable Support for You can disable support for any of the listed SSL protocols by selecting
the following the check box. You can then check the configuration by clicking Check.
protocols:
Client Certificate (HTTPS only)
Use Client Allows you to choose a certificate for the client. If you select this option,
Certificate select a certificate from the list in the window that appears and click OK.
You may also view or change a client certificate. If you have chosen a
certificate, you can also:
• Apply an existing certificate revocation list to the certificate, and set
the monitor to regularly check for updates by monitoring a CRL file.
• Automatically validate the client certificate based on some of the
certificate information, including country and organization.
• Specify a header name in the HTTP request in which to include the
client certificate properties.
Use Existing CRL Allows you to use the existing Certificate Revocation List.
Check for CRL Select this in order to define the amount of time (in seconds) to check for
update every.. CRL updates.
A CRL Update File dialog is opened allowing you to enter the location of
the CRL Update file. The name of the CRL update file is displayed in the
following field.
Validate Client Check this to display the Properties Validation dialog box.
Certificate According Fill in the following information so they may be used to validate the
to Selected certificate.
Properties
• Country
• State
• Locality
• Organization
• Organization Unit
• Extended
Forward Client Select this field in order to distribute the Client Certificate properties in
Certificate the HTTP header. The following field allows you to enter the name of the
Properties in HTTP HTTP header.
Header

AppWall User Guide
HTTP Properties
General HTTP Properties
Allow High ASCII When enabled, the AppWall Server allows High-ASCII Characters (127-
Characters 255) in any 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.
Action Enable/Disable from the drop-down menu or double-click and check/
uncheck box.
Only Use Codepage When selected, the AppWall Server performs text-normalization using
Encoding for URL the Tunnel codepage instead of UTF-8. Enable this setting when an HTTP
and Parameter request includes codepage-encoded characters that may be mistaken for
Screening UTF-8. 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, the AppWall Server allows messages containing
Parameter Values parameter values that cannot be fully-normalized to Unicode to pass
that Failed Text- unchanged in value and treats them as a stream of bytes when
Normalization evaluated. This occurs if 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, the AppWall Server allows Quick-Click Refinements on
Refinement for events generated for requests that cannot be matched to an enabled
Adding New Application Path. This can only occur if the Tunnel does not support the
Application Paths Default Web Application or if the Default Web Application is disabled.
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.
Request Message
URL Query String Specifies the character used in query strings to delimit the beginning of
Delimiter query parameters.
Action Double-click the text field and enter the delimiter.

AppWall User Guide
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.
Action 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.
Action 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, instances
_NAME of values 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 Server 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
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 (e.g. 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.
Allow Non-RFC When enabled, the AppWall Server does not enforce the RFC
Compliant HTTP requirements as stated 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/).

AppWall User Guide
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 the AppWall Server 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 you
added by selecting the header and clicking Edit or Remove.

AppWall User Guide
Action To add a header:
1. Click Add.
2. Enter the Header Name, Delimiter (typically “:”), and initial Free Text
for the header.
3. Following the free text, you can have any of the following added to
the header by leaving the checkbox for this item checked: Message
Date Time, Client Port, Client IP, Forwarding Port, Forwarding IP,
Session Date Time.
4. Click Preview to see the header as it will appear in the request.
Note: Note: A complete document explaining the X-FORWARDED-FOR
Custom Header is located in the Support folder of the AppWall
Server.
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.

AppWall User Guide
Action 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.

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 extra spaces before or after the protocol version but
not before the URI.
uncheck box.
Reply Message

AppWall User Guide
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 in
Control the client’s browser.

uncheck box.
Replace the HTTP Allows you to remove or replace the standard HTTP reply messages with
Reply Messages with custom messages of your choice. You can change the replies according to
Custom Messages one or more ranges of status numbers. If replacing the message, place
the new message into a file and include the file using the interface.

AppWall User Guide
Action To Enable:
1. Double-click the property and click Add 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 and 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.
1. On the URL screen, 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 screen, mark in the value boxes which properties you wish to
apply to the URL.
Property Allows parsing criteria.
Value Mark as appropriate for parsing.
4. Click Add to add values and then OK to exit. Your values are saved.

AppWall User Guide
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 screen should look like the following example.

AppWall User Guide

AppWall User Guide
7. By selecting the Parsing properties name, you can view more detail and edit if required.
8. Click Save to save your changes or Revert to discard them and revert to your previous settings.
HTTP Message Size
Request Line Length Maximum length allowed for a request (URL) line. Note: This setting
Allowed should account for path and query parameters.
Total Headers Maximum length of the entire HTTP Header of a request. This value
Length Allowed 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 Maximum Header Entry
Length Allowed setting (see next).
Total Body Length Maximum length of the entire body of a request message. Because Files
Allowed > 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.

AppWall User Guide
HTTP Headers - Maximum length of a single Header entry. This entry should be greater
Maximum Header than or equal to the largest value in the Header Name list (see next).
Entry Length
Allowed
HTTP Headers - Headers by name and maximum value for each Header Name added to
Header Name list the list. The maximum size should be less than or equal to the Maximum
Header Entry Length Allowed (see above) 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
This feature allows you to indicate certain file types and/or parameters that may be requested
without any additional validation.
There are many file types and/or 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.
Enable File-Type Select to enable this feature.
Security Bypass
All Extensions Select the file extensions that indicate file types for which this feature
should be applied and click the right arrow.
You can select multiple extensions by clicking the extensions while
holding the Ctrl key.
Add Extension / To add an extension not on the list:
Delete Extension • Click Add Extension, enter the extension, and click OK.
To delete an extension, select the extension in the list:
• Click Delete Extension, and click Yes in the confirmation dialog
box that appears.
Parameters Security To add a Parameter not on the list:
By-Pass • Click Add, enter the parameter, and click OK.
To edit a Parameter not on the list:
• Click Edit, enter the parameter, and click OK.
To delete a Parameter, select the parameter in the list:
• Click Delete and click Yes in the confirmation dialog box that
appears.
Modifying TCP Tunnel Properties

TCP Tunnels have only a few configuration settings.

AppWall User Guide
To change the settings for a TCP Tunnel
1. In the Configuration view, expand Server Group > AppWall Server >Tunnels > TCP and
select the Tunnel to be modified.
2. In the right pane, modify the Tunnel properties as described here.
Tunnel Mode
Transparent (Preserve Original source IP address of the client is preserved and forwarded to
Client IP) the web server.
Note: For Application processing or logging, enabling the
Transparent mode will enable retrieval of the original source IP
from the TCP connection.
Reverse Proxy Source IP address of the TCP connection from AppWall to the web
(default) server will be the Forwarding IP address defined in the tunnel.
Note: For web server logging only purposes you can also activate
the X-Forwarded-For header setting to add the client source IP
address.
Listening Address This is the IP address on which the tunnel will be listening. In
standalone deployment it will usually be the web application public IP,
while in ADC deployments, it will be the internal AppWall real server IP.
Listening TCP Port The IP port on which the AppWall Server listens. (This is usually port
1025).
Note: You can only enter an IP address that has been previously
defined for a device interface using either the CLI Manager (see
Address Management), or AppWall for Web Based Management. If you
do not see the IP address defined for the device interfaces in the drop-
down list, click Load IPs at the bottom-right of the window to refresh
the displayed IP list.
Forwarding Address Enter the private IP address of the internal NIC interface of your
AppWall Server. This interface is used to forward the request to the Web
Server.
Idle Session Timeout Amount of time an inactive session can remain idle before being
dropped.
Protected Web Server
Name Name of your defined TCP tunnel.
Protected Type Select the Web Server from the drop-down menu. Web Farms are not
supported for TCP Tunnels.

AppWall User Guide
Protected Web Server Select the object (name of the Interface) from the drop-down menu.
Click New to add a new Web Server.
Note: You can only add Web Servers with a protocol setting that
matches the Tunnel type, e.g. in an HTTP Tunnel you can only
add Web Servers with HTTP protocol setting. Web Farms are
not supported for TCP Tunnels
Web Servers List List of your defined web servers showing the name of the Protected
Web Server, the Listening TCP port and the Forwarding Address IP.
Setting Tunnel Operation Modes

AppWall Servers can run in one of several modes of operation as shown in the following table:
Mode Server Types Description

Bypass Gateway Running, but no intrusion detection or interception.
Passive Gateway Full intrusion detection.
Active Gateway Full intrusion detection and interception.
Using AppWall Management Application, you can view and change the operation mode of each
defined AppWall Server.
Viewing and Changing the Current Operation Mode of a Tunnel
To view current Operation mode
The current operation mode of the Tunnel is displayed in the General Properties tab of the Tunnel.
Type > Tunnel Name.
2. Select the Tunnel name. A list of properties tabs appear for the tunnel.
3. 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.

AppWall User Guide
Figure 37: General Properties Tab
To globally change Tunnel Operation modes
1. Right-click the Server node, select Escalation Settings.

2. Select Set Mode to [new mode].
Defining Console-Server Connections

The AppWall Server can be configured to accept remote console connections. You can configure
connection settings for the following:
Remote Connection For standard TCP connections, AppWall Management Application can
connect through the specified IP addresses to the AppWall Server.
Encrypted Remote AppWall Management Application can securely connect through the
Connection specified IP addresses to the AppWall Server for SSL connections
between the AppWall Server and AppWall Management Application.
Certificate Server For the SSL connection and encryption, AppWall Management
Connection Application uses a certificate for a Secure Remote Connection. This
certificate connection is not related to the certificate stores and is not
visible in the Certificates node.
The following diagram shows the AppWall Management Application and AppWall Server connections
using masks Allow Mask:10.0.0.* and Deny Mask:10.0.0.115.

AppWall User Guide
Figure 38: AppWall Management Application and AppWall Server connections
If the remote AppWall Server Listener subnet mask permits changes to the AppWall Server settings,
you can modify the subnet mask and change which AppWall Management Application is permitted or
denied access to the AppWall Server.
Any IP address not defined in the net result of these two settings will not be allowed.
Allowed Mask 10.0.0.* defines the IPs Denied subset removed from Allowed Subnet Mask. The
result is a subset of permitted IP addresses. If the Allowed list is 10.0.0.* and IPs 10.0.0.17 and
10.0.0.32 have been defined in the Deny list, the result of permitted IPs will be everything in the
10.0.0.* range, except for 10.0.0.17 and 10.0.0.32.

AppWall User Guide
Managing Remote Connections

Use the following procedure to add, modify, or remove a remote connection. This procedure requires
administrator permissions.
To manage a remote connection
1. In the Configuration view, expand the Management node and click Console-Server
Connections.
2. In the right-pane, right-click the Connections Table and select Add, Edit, or Delete.
3. Complete the Server Properties dialog box according to the table below and click OK.
Tab Parameter Description

General Server IP Select the IP address of the AppWall Server.
Admin Port Port number used for Administration purposes.
Maximum Remote Maximum number of AppWall Management
Connections Application clients that can connect to the AppWall
Server at a time.
Use an Encrypted Remote For SSL connections, allows AppWall Management
Connection Application to securely connect through the
specified IP addresses to the AppWall Server.
Allow/Deny Allowed Remote Console Click Add and enter the submask that specifies
SubMask which IP addresses will be permitted; do not include
any that are specified in the Deny Remote Console
Subnet Mask.
Deny Remote Console Click Add and enter the submask for one or more IP
SubMask connections that excludes IPs from the Allowed
Remote Console Subnet Masks.
4. Click Save.
5. Restart the AppWall Server process.
Configuring the Publisher

This section describes how to configure the AppWall Publisher and includes the following:
• Managing Publisher Connections to AppWall Servers, page 110
• Setting Publisher SMTP Settings, page 112
• Setting Publisher OPSEC ELA Settings, page 112
• Setting Publisher SNMP Trap Settings, page 113
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.

AppWall User Guide
To manage Publisher connections
1. Make sure the AppWall Publisher service is running.

2. In the Configuration view, open Server Group > AppWall Server > Services and select the
Publisher node.
3. In the right pane, complete the fields as described below.
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.
Make a Key Opens a dialog enabling you to create an OPSEC Authentication
password. Fill in the Object Name and Key Password and click OK.
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
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.

AppWall User Guide
Setting Publisher SMTP Settings
To set Publisher SMTP settings

2. In the Configuration view, open Server Group > AppWall Server > Services > Publisher
and select the Recipients node.
3. In the right pane, complete the fields on the SMTP tab as described in the following table.
Enable Clear to disable feature.
From (Friendly Name) Sender name appearing in the messages From field.
From (Email Address) Sender email address.
To (Email Address) Recipient email address.
Email Subject Message subject text.
SMTP Server IP address of the mail server (SMTP) to which the event notifications
are sent.
SMTP Port IP Port of the SMTP server.
Forwarding Address IP address that connects to the mail server (SMTP) and from which the
event mail notification is sent. Enter the address or use the drop-down
list.
SMTP Authentication Authentication information for connecting to SMTP server.
4. Click Test Settings to check the settings.

5. Click Save. The Publisher automatically restarts when the configuration is saved.
Setting Publisher OPSEC ELA Settings

Use this procedure to configure Publisher to distribute events to a CheckPoint Firewall-1 log.
To set Publisher OPSEC ELA settings
1. Be sure the AppWall Publisher service is running.

Enable Checks to enable registration of an event in CheckPoint FireWall-1 log and
fill in the remaining fields.
IP Address Specifies IP Address to which the event is sent.
Port Specifies Port number to which the event is sent.
Connection Type Displays the type of connection between AppWall Server and the
CheckPoint FireWall-1.

AppWall User Guide
5. All fields in this table are read-only (except for Enable).
Note: You must also configure the ELA proxy server and CheckPoint Firewall-1 before the
logging works on the firewall.
Setting Publisher SNMP Trap Settings

Use this procedure to enable the forwarding of SNMP traps when events occur.
AppWall Publisher supports sending traps over SNMP versions 1, 2c, or 3.
To set Publisher SNMP Trap settings

3. In the right pane, click the SNMP tab and complete the following fields.
Enable Clear to disable feature. Select to enable an event to send an SNMP trap
and fill in remaining fields to specify where to send the trap.
Forwarding Address IP address sending the trap.
Version SNMP version.
Values: 1, 2c or 3
Community SNMP community field for SNMP version 2c.
SNMP version 3 • Security Level—Sets the security level. Used for SNMPv3 messages
fields (noAuthNoPriv|authNoPriv|authPriv). You must provide the
appropriate passphrases when using any level higher than
noAuthNoPriv.
• Security Name—Sets the security name used for authenticated
SNMPv3 messages.
• Authentication Protocol—Sets the authentication protocol (MD5 or
SHA) used for authenticated SNMPv3 messages.
• Authentication Pass Phrase—Sets the authentication passphrase
used for authenticated SNMPv3 messages.
• Privacy Protocol—Sets the privacy protocol (DES or AES) used for
encrypted SNMPv3 messages. Currently, AppWall supports DES only.
• Privacy Pass Phrase—Sets the privacy passphrase used for
encrypted SNMPv3 messages.
• Context Engine ID—Sets the authoritative (security) engine ID used
for SNMPv3 REQUEST messages. It is typically not necessary to
specify this as it is discovered automatically.
• Context Name—Sets the context name used for SNMPv3 messages.
The default context name is the empty string "".
Destination/Port IP address and Port number where the trap is sent. Use Add, Edit, or
Remove to manage this setting.

AppWall User Guide

Configuring SysLog Notifications

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

3. In the right pane, click the SysLog tab and complete the following fields.
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.

Configuring ODBC
Use this procedure to configure where Publisher will send events to ODBC-compliant databases.
To set ODBS settings

3. In the right pane, click the ODBC tab and complete the following fields.
Enable Clear to disable feature. Select to enable sending events to a database
and fill in remaining fields to specify where to send events.
Data Source Name ODBC data source name.
Username User name of the account used to write to the database.
Password Password of the account used to write to the database.
Automatically Complete the table name field.

AppWall User Guide
Create Table Name of table to create.
Attributes Mapping Click to custom-map the database field headers. Then:
• In the Attribute field, double-click the attribute name, enter the
alternate name in the dialog box that appears, and click OK.
• Repeat this step for each attribute to assign an alternate name and
click OK.

Notes
>> you must set ODBC connections settings in the web interface or CLI before setting the
ODBC in the publisher.
>> You can configure the Publisher to publish ODBC notices to a database for one or more
AppWall Servers.
>> You must determine "Publisher Rules" in order to send events.
Defining the Escalation Server List

The Escalation Server List allows the user to define a list of AppWall Servers upon which to apply
Escalation rules. To do so, the user can Add, Edit, and Delete AppWall Servers to/from the list. When
you click Add, the following fields are displayed:
Table 10: Escalation Server List
Add the Local Server Select to automatically detect the Local Server information. This may
require name and authentication details.
Name A name to identify the Server.
Server IP The IP Address of the Server.
Admin Port The connection port of the Server.
Username Server credentials.
Password Server credentials
Use an Encrypted Select the check box if the Server is using an SSL connection.
Connection
Server Type Select the type of the server.
Check Checks that the settings are correct.
Deployment Planning
AppWall Servers can be deployed in a number of scenarios including:
• Stand-alone Gateway to all “protected zone” Web Applications on corporate intranets.
• Pre-deployment “testing” device for Web Application firewall policies.

AppWall User Guide
When planning your deployment of AppWall Servers, you should note that AppWall Gateway Servers
provide different solutions:
• The AppWall Gateway can stop or redirect messages that violate the established security rules.
• AppWall Virtual Appliance, page 124.
AppWall Gateway Deployment

The following illustration provides an exemplary deployment configuration of the AppWall Gateway,
on the network, in relation to the central components of AppWall Threat Management System.
The illustration displays the route of all inbound HTTP traffic to your Web Application. The AppWall
Gateway intercepts all traffic directed to and from the Web Application. The AppWall Gateway checks
that the client request is legal and does not include malicious content, based upon security policies
created in the AppWall Management Application, and that the response from the Web Application
does not include information that is not intended to be displayed.
The AppWall Gateway can be employed to protect multiple Web Applications using different Security
Policies to match the security requirements of each Web Application.
Figure 39: Typical AppWall Gateway Deployment
AppWall supports the following deployment modes:

• Reverse Proxy Deployment, page 116
• Transparent Proxy Deployment, page 117
• Bridge Deployment, page 117
You set the operational mode at the tunnel level under the TCP properties.
To configure a tunnel to work in Transparent Bridge mode, you must first set the relevant network
interface segment to Bridge mode in the Web interface.
Reverse Proxy Deployment

The following illustration provides an example Reverse Proxy deployment configuration of the
AppWall Server.
When deploying AppWall in Reverse Proxy Mode, AppWall creates a TCP connection with the back-
end web server from a single IP address defined as the Forwarding IP in the tunnel.
This deployment mode provides the highest security as all traffic is terminated in AppWall, all TCP
connections are accepted by AppWall and all traffic is only forwarded to the web server following
security policy compliance inspection. When deploying the AppWall Server, you should consider the
best location on the network for listening to the Tunnels (IPs).

AppWall User Guide
Figure 40: Typical Reverse Proxy Deployment
Transparent Proxy Deployment

When deploying AppWall in Transparent Proxy Mode, AppWall functions as a Reverse Proxy with the
ability to preserve original client IP addresses in the connection with the back-end server.
For Application processing or logging purposes, enabling the Transparent mode enables you to
retrieve the original source IP from the TCP connection in the web server. For web server logging
only purposes, you can also activate the X-Forwarded-For header setting to add the client source IP
address. The Transparent Proxy mode still functions as a Reverse Proxy and only traffic directed to
the listening IP and port as defined in the tunnels will be accepted and processed. All other non TCP
traffic will not be forwarded to the back end servers.
When AppWall is deployed in bridge mode, the AppWall must be deployed between the default
gateway which is configured in the protected web server and the protected server. This will enable
all traffic from the web server to be sent back to AppWall and process all the traffic from the secured
application, even though some of the traffic was sent from a spoofed external IP address and not
from AppWall's IP.
Bridge Deployment
When deploying AppWall in Bridge Mode, AppWall functions as a Transparent Network Device:
• All non HTTP traffic is transparently forwarded to the destination
• All HTTP traffic which is not defined to be secured (no tunnel defined for that web server in
AppWall) is transparently forwarded to the destination
Similar to Transparent Proxy mode, in the secured HTTP/S traffic, the source IP address of the TCP
connections from AppWall to the back-end servers is the original client address.
When AppWall is deployed in Bridge mode as a transparent network device with no listening IP
addresses and ports, a fail over device (either internal or external) can be applied to bypass the
traffic in case of internal failure or power down.
Note: This deployment option is offered on ODS-VL platforms where the internal bypass relays
are applied and is configured to offer a fail-open system for maximum transparency.
When deployed in bridge mode, AppWall can be configured to one of two modes:
• Fail open to bypass traffic in case of system failure
• Fail close for blocking traffic on system failure or power down.
This deployment option is common when AppWall is deployed as a standalone device.
The Fail open/close mode is configured at the segment level.
There are two network interfaces which are grouped as segments: G1 (ethSRV1) and G2 (ethSRV2).
When the device is set to bridge mode and both interfaces in a segment are set to bridge mode
(when the machine is set to bridge mode, the interfaces might still be in proxy mode), the segment
Bypass settings are enabled. These settings enable or disable bypass by user operation with
immediate effect and help to define the segment failure state operation: either to function as fail
open or as fail close.

AppWall User Guide
When a segment is set to bypass on, all traffic from one interface in the segment will be redirected
to the other interface and vice versa. As a result, the link LED will not be illuminated.
Bypass cannot be set for the other interfaces: G3 (ethSRV3), G4 (ethSRV4), G5 (ethSRV5), G7
(ethSRV7) and G8 (ethSRV8).
When AppWall is deployed in bridge mode, the AppWall must be deployed between the default
gateway which is configured in the protected web server and the protected server. This will enable
all traffic from the web server to be sent back to AppWall and process all the traffic from the secured
application, even though some of the traffic was sent from spoofed external IP address and not from
AppWall's IP.
Figure 41: Bridge Deployment
Cluster Deployment
AppWall is enabled to work with two types of cluster deployment, Transparent Proxy and Bridge
Deployment.
You can deploy AppWall Servers in a Cluster arrangement (as shown in the illustration below). From
a single Management Application, which is connected to the AppWall Cluster Manager, you can
manage relevant changes to your Security Policy across a number of AppWall Servers.
The AppWall Cluster Manager is suited to an Enterprise employing AppDirector, where it allows
AppWall Servers to work together as a cluster, ensuring a reduction in management overheads and
potentially hazardous manual adjustments to security configurations. The AppWall Cluster Manager
ensures that critical updates to an Enterprise’s Security Policy are no longer susceptible to human
error and potentially damaging system downtime, but are efficiently and automatically applied over
the entire cluster.
Figure 42: Cluster Deployment
The AppWall Cluster Manager enables the virtualization of the multiple servers in the cluster,
managing the configurations and Security Policies of all the AppWall Servers in the cluster. The
settings of each AppWall Server cannot be modified and are displayed as read-only when accessing
via other Management Applications; in fact, only those users with access to the main Management
Application can apply changes to the Servers, which are applied via the Cluster Manager.
The AppWall Cluster Manager also ensures that the distributed configuration data is forwarded to
each Server individually and is correctly applied before continuing to the next Server.

AppWall User Guide
Adding a Cluster Manager and Gateways to Your Deployment
Note: Different hostname licenses must be accompanied by the same user names.
When configuring your Cluster deployment and adding an AppWall Cluster Manager and AppWall
Gateways, a number of factors should be taken into consideration:
• Ensure there is connectivity between the AppWall Cluster Manager and its AppWall Server
nodes.
• You should work with at least two separate network interface cards; one for management
purposes and one for the AppWall Cluster service and traffic.
• If connecting directly to a Cluster node from AppWall Management Application, Radware
recommends that you refrain from editing any of the nodes’ details as any modified settings will
be overridden by the next synchronization process run by the Cluster Manager. This method of
working is only recommended in emergency scenarios, such as when the Cluster Manager is
down or damaged.
You can also install the Cluster Manager to function as one of the Gateways in the Cluster. This is
especially useful for better utilization of the hardware.
Cluster Deployment with Auto Policy Generation

With the ultimate aim of an Enterprise’s IT department being able to automatically configure a
Security Policy without all the management overhead entailed, this additional Cluster deployment
option, with the Cluster Manager working as a Gateway in the cluster set with Auto Policy Generation
running, brings that vision a big step nearer. Because of the all-too-common human factor in
defining a security configuration, such as unavoidable human error or lack of requisite knowledge
and skills to successfully implement a configuration, this Cluster deployment provides the perfect
answer.
As in the regular Cluster deployment, one Management Application has access to the AppWall
Cluster Manager. Auto Policy Generation is enabled and learns all the refinements required to define
the Enterprise’s Security Policy.
Requirements for AppWall Cluster Environment

Before implementing an AppWall Cluster environment, check the following:
• Ensure that there is MNG interfaces connectivity between the AppWall Cluster Manager and its
AppWall Server Nodes (Ping can be done via AppWall web interface).
• Ensure that the AppWall Devices Host Names are unique (different hostnames for different
devices)
• Both the Cluster Manager and its nodes must use the same Users Name and Passwords.
Note: Both the Cluster Manager and its nodes must have Authenticated license (AppWall
Cluster Manager has a different license than AppWall Server nodes).
Deploying AppWall in an ADC Environment

In certain production environments where AppWall is installed, the client may have several Web
Servers, and several AppWall Servers protecting them. These environments usually include an
AppDirector or Alteon load balancer installed in front of the AppWall Server.
Typically when deploying AppWall in an Application Delivery Controller ADC environment, the
preferred deployment node is either Reverse Proxy or Transparent proxy. Deploying AppWall in these
modes enables you to define AppWall health monitoring in the ADC and bypass policy.

AppWall User Guide
Do not forget to define the web servers as a backup in the AppWall farm in case the AppWalls are
down, this enables the backups to become active.
Multiple Web Server/Web Farm Deployment

In certain production environments where AppWall is installed, there might be several Web Servers,
and several AppWall Servers protecting them. These environments usually include an AppDirector or
Alteon load balancer installed in front of the AppWall Server.
AppWall provides the ability to define multiple destination Web Servers for each Tunnel. This consists
of two entities, which are the “Web Server” and the “Web Farm”.
• Web Server—The Web Server is the address (IP and Port) of the Web Server (or Web Server VIP)
that the AppWall Server is designated to protect.
• Web Farm (not AppDirector)—The Web Farm is a collection of one or more Web Servers under
the same entity that can provide a basic load balancing functionality.
This feature provides the following advantages:
• Helps avoiding multiple tunnel definitions for the same Web Application deployed on multiple
Web Servers. Simply define all the Web Servers in a single tunnel.
• Delivers Tunnel Level Load Balancing. The client is provided with a 2 level Load Balancing
functionality, which allows for better redundancy and built-in high-availability between the
different Servers. To achieve highest availability, each server must have all Web Servers defined
in each of its Tunnels. Failure of a server will result in continuation of service by other active
Servers, for all Web Servers.
• If no AppDirector or Alteon is used in the production environment, and only a single Server
exists in front of multiple Web Servers hosting the same Web Application, this feature provides
the ability to balance the traffic load between those Servers using a single server.
Notes
>> A Tunnel may include one Web Server or one AppDirector Web Farm.
>> These entities are defined prior to the definition of the Tunnel and are used as part of
the AppWall configuration.
Adding a Secure Web Server
To add a new secure Web Server
1. Select the Web Server node from the Protected Entities folder in the Configuration View.
2. Click Add to add a new Web Server. The following dialog is displayed:

AppWall User Guide
3. Enter the Name, Description, IP address, Port and Protocol used by the Web Server.
4. Click Check to mark the connection to the specified Web Server.
Adding a Web Farm

This section describes how to add a Web Farm which will be protected by the AppWall Server.
To add a new Web Farm:
1. Select the Web Farm node from the Protected Entities folder in the Configuration View.
2. Click Add to add a new Web Farm. The following dialog is displayed:
Escalation
AppWall has the following Escalation options:
• For AppWall Gateway—Passive, Bypass and Active mode
AppWall Gateways are deployed in-line for intrusion prevention. They offer multiple modes of
operation:

AppWall User Guide
• 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 Server whose Tunnels’ Operational mode you wish to change (Escalation
settings).
2. Right-click the AppWall Server and from the menu select Escalation Settings X Set Mode to
Bypass/Active/Passive for AppWall Gateways.
3. Click Yes to change the Tunnel operational mode.
Load Balancing
This section describes the following Load Balancing deployment topologies:
• Single AppWall Gateway – Multiple Web Servers, page 122
• Multiple AppWall Gateways in a Web Farm, page 123
Single AppWall Gateway – Multiple Web Servers

In this deployment scenario, one AppWall Gateway is deployed with several Web Servers. The
AppWall Gateway acts as a simple Application Layer Load Balancer, and manages the traffic to each
of the connected Web Servers.

AppWall User Guide
Figure 43: Single AppWall Gateway with Multiple Servers
Multiple AppWall Gateways in a Web Farm

In this deployment scenario, multiple AppWall Gateways are deployed with multiple Web Servers in
a Web Farm. An AppDirector is deployed and the AppWall Gateways are connected to the Web
Servers through the AppDirector.
As part of the Radware Application Delivery Controller (ADC) solution, AppWall, in conjunction with
AppDirector, can perform traffic redirection and application acceleration in addition to Web
Applications security.
This deployment can support various configurations, such as:
• Environments where both load balancing and SSL offloading are required. In such an
environment, AppDirector performs traffic redirection, SSL offloading, caching, and
compression, after which AppWall will inspect clear HTTP traffic.
• Environments where encryption must be maintained throughout the connection between the
client and the Web servers. In this environment, AppDirector performs traffic redirection, SSL
offloading, caching, and compression, and then sends traffic re-encrypted to AppWall. AppWall
then decrypts the traffic, inspects it, and opens a secure encrypted connection to the Web
servers.
For the specific procedures and examples of implementing this scenario, refer to the Radware
Application Delivery Controller (ADC) Implementation using AppDirector and AppWall Solution
Guide.
Figure 44: Multiple AppWall Gateways

AppWall User Guide
AppWall Virtual Appliance

AppWall Virtual Appliance (VA) is designed to provide maximum agility through download of a single
virtual appliance file (.ova), upload of license file, and swift initial configuration, for multiple
environments including:
• virtualized data centers
• private and public cloud environments
• enterprise virtualized data centers
• testing and staging environments
• training, demonstration and POCs
AppWall Virtual Appliance and AppWall Appliance Offering the Same Management
Application and Features
AppWall VA and AppWall appliance use the same AppWall Management Application to manage the
security policy and to configure the devices. You can also define a VA as a node in a form factor
based AppWall Cluster manager. Both platforms offer the same feature set and enable seamless
policy distribution.
Easy Migration from Test Environments to Production

AppWall VA is a useful tool for lab, testing, and demo environments, where network, security, and
application teams can quickly deploy it to test how applications and networks will respond in a
production environment when managed by an AppWall device. Once testing is concluded, you can
either deploy the application and the AppWall VA in the production environment or easily migrate
from the AppWall VA policy to the AppWall Appliance production environment, since AppWall VA is
identical in features and capabilities to the form factors. This approach simplifies the integration
between the developed application and AppWall VA and shortens the deployment time of new
applications and services in the virtualized and cloud data centers.
Alternatively, AppWall VA can be deployed in the production environment, where its advanced Auto
Policy Generation tools can be utilized to generate tailored policies for the protected application.
Differences between AppWall VA and AppWall Appliance
License
While in AppWall Appliance the license is based only on the MAC address of the management
interface, in AppWall VA the license is based on the HostID which is a more complicated host
identifier.
The HostID can be generated from the AppWall Management Application -> Configuration
View -> Management Licenses -> HostID
Radware technical support (Support@radware.com) will be able to generate a license for you, based
on this HostID.
APSolute Vision Reporter

APSolute Vision is Radware’s closed SEM (Security Event Management system) used for AppWall
Logging and Reporting. AppWall can send all generated events to this external SEM, for the purpose
of 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.
APSolute Vision Reporter was introduced in AppWall version 5.0.1. To activate the APSolute Vision
Reporter, you need to configure the IP address and port to which the AppWall events will be sent in
the Configuration view under the Services folder in the APSolute Vision Reports. The events are sent

AppWall User Guide
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 (with APSolute Vision 1.09.03
version) 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 screen.
Prerequisites
• Using the AppWall Management Application, you should login to the AppWall server using a valid
user. If no users are defined in AppWall and the AppWall Management Application user logged-in
without providing a username and password, attempts to launch the APSolute Vision reporter
will fail as it will not be possible to validate the AppWall Management Application user.
• The Allowed Remote Console SubMask should enable the APSolute Vision Reporter to connect to
AppWall. Ensure that the mask is not preventing the APSolute Vision Reporter from accessing
the AppWall server.
For further details see the APSolute Vision Reporter User Guide.

AppWall User Guide
Figure 45: Vision Reporter
To access the APSolute Vision Reporter from AppWall
1. Go to AppWall Servers > [My Server] > Services and select APSolute Vision. The APSolute Vision
setup window appears defaulted to the Reporter tab.
2. Enter the default Vision Reporter (IP) Address
3. Enter the communications port to use, (default Port is 2214).
4. Select the Protocols that you will be using for: PCI, Security, Audit and Default as either TCP or
UDP. Defaults are TCP except for Audit (UDP).
5. Click the Vision Reporter button located at the top right of your window. You are taken to the
Security Certificate window for the APSolute Vision address that you specified in setup.
6. Follow the on-screen instructions including user/password authentication where appropriate.
The Vision Reporter window is now displayed.
To configure sending Audit events with the APSolute Vision Reporter
From the Audit tab, audit events that generate an access log for HTTP/S transactions can be
configured by:
• Host
You can configure logging HTTP transactions only to a specific URL, to all transactions to an
application sub-tree or to log all transactions to a specific host (by entering "*" for the host).

AppWall User Guide
Figure 46: Vision Reporter Audit
SNMP Agent
An SNMP agent runs on AppWall devices (physical appliances only), enabling remote monitoring of
the device resource utilization, including CPU memory and traffic volume information. The
compatible MIB file which should be used for SNMP agent monitoring is delivered along with the
AppWall device, and can be downloaded from the radware.com Web site.
The SNMP agent can be configured using the AppWall web interface to support SNMP versions 1, 2c,
or 3 along with additional settings.
For more information on configuring the SNMP Agent, see Configuring AppWall SNMP Agent,
page 257

AppWall User Guide

AppWall User Guide
Security Tools
Chapter 4 – Security Tools

This section describes the various security tools and security features available in AppWall, and
• Working with Security Filters, page 129 - describes how to work with the AppWall Security
Filters, and includes a description of each of the Filters.
• Security Filters in Detail, page 134 - gives a general overview of each of the Security Filters.
• Web Application, page 184 - describes how to work with a Web Application, the logical model for
defining your Security Policy.
• Application Path, page 194 - describes how to work with Application Paths
• Defining Your Security Policy, page 206 - describes the main scenarios in which AppWall is used
to implement an Enterprise’s Security Policy.
• Auto Policy Generation, page 218 - describes how to work with the Auto Policy Generation
feature including how to work in Learn Mode.
Working with Security Filters

This section describes the out-of-the-box Security Filters supplied when an AppWall Server is
installed. It describes both the threats that the Filters screen and protect against, as well as how
each Security Filter works, and its default running status. For information on how to configure each
of the Security Filters, refer to the Online Reference guide (accessed by pressing F1 from within
AppWall Management Application).
• Security Filter Overview, page 129
• Threats the Security Filters Protect Against, page 130
• Setting Security Filters, page 131
• Activating a Security Filter, page 132
• Setting the Security Filter Run Mode, page 132
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 Server initial installation. The
Security Filters node in the Configuration view allows you to establish global configuration settings
for Security Filters that the AppWall Server can use when these Security Filters are assigned to an
Application Path.
When a request does not conform to a Security Filter definition, the AppWall Server generates an
event. By configuring and assigning Security Filter definitions to various application segments, or
paths, the AppWall Server 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 (for further details, see Auto Policy Generation, page 218). 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 131.

AppWall User Guide
Security Tools
Threats the Security Filters Protect 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 the
AppWall Server mitigates.
Table 11: 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 via 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 Manipulation Exploits vulnerabilities inherent in web services formats, structure, and
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 (Unicode, UTF-
8, UTF-16, etc) 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) A CSRF attack forces a logged-on victim’s browser to send a forged
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.
Brute Force Attacks Attempts to guess the Username and/or Password of an authorized
user by employing various automated tools.

AppWall User Guide
Security Tools
Table 11: Examples of Security Threats
Threat Description
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.
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 (e.g. 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 via 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 Server 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.
For further information, see the appropriate section.

AppWall User Guide
Security Tools
The AppWall Server’s base security protection is the Default Web Application, which serves as an
“umbrella” security policy. This guarantees that any request is subject to this minimum set of
checks. Security Filters provide additional, unique security protection, depending on the Filter used.
For example, use the AllowList Security Filter to specify which paths or file types can pass without
detection, or use the FilesUpload Security Filter to specify the location where files can be uploaded.
For specific details about how to configure each Security Filter, refer to the Online Reference guide
(accessed by pressing F1 from within AppWall Management Application).
Activating a Security Filter

This section describes how to globally activate a Security Filter.
To activate a Security Filter
In the Configuration view, expand the Filters node and select the required Security Filter.
1. Select or clear the required checkboxes on the tab. Where relevant, ensure that Enable Log,
Quick-Click Refinement, and Manage Refinement Usage Frequency are selected.
2. In the Security Policies view, click on an Application Path to display the Settings tab in the right
pane. Click on the Automation Level tab and set the Security Filter to Active (or any other
mode, as described in the following section). See Auto Policy Generation, page 218 for
information on how to determine the level of automation.
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).
• Learn mode records traffic that would trigger the Security Filter if it were enabled, allowing you
to later configure the Security Policy based on this information.
• 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 218.
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 134 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 > 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 the Automation Level tab, and then select
Active, Passive, Learn or Disable in the Mode column (Note that this action is only available if
the Manual option is selected) according to the requirements of your Web Application.
In addition, you can select an Automation level, such as Auto Refinements (for AllowList,

AppWall User Guide
Security Tools
Parameters, and Database Filters) to work with the selected Filter mode. For example, selecting
Active and Auto Refinements ensures that while traffic triggered by the Filters is stopped, the
Auto Refinements option works in the background and will still generate refinements. Similarly,
selecting Learn and Auto Refinements ensures that while traffic is still recorded and potential
security risks identified, the Auto Refinements option still generates refinements.
3. Click Save in the Content Area, and click Apply Changes on the toolbar.
Refining Security Filters

There are three 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 the AppWall Server from continuing to issue events
of this type with the AppWall Server’s Quick-Click Refinement feature. This feature is available
on most Security Filters. See the procedure below.
• Refinements Tab—Most Security Filters provide a Refinements tab to allow you to manually
control events issued by the AppWall Server. 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 218.
To enable Quick-Click Refinements
1. In the Configuration view, expand the Filters node and select the specific Security Filter to
display in the right pane.
2. In the right pane, Quick-Click Refinements field, select the check box to enable refinements.
Enable the Log check box first.
4. Double-click the event that you no longer want reported or click a button at the bottom of the
table. The Event Properties window appears.
5. In the Event Properties window, click Refine.
6. Click Apply Changes 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 is displayed 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, expand the Filters node 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. Right-click an entry and select Edit.
5. On the dialog box that displays, modify the properties and click OK.

AppWall User Guide
Security Tools
6. Right-click the entry again and select Add.

7. Click Save on the right pane.
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.
For information about basic configuration and procedures for each of the Security Filters, refer to the
• AllowList Security Filter, page 134
• BruteForce Security Filter, page 139
• Database Security Filter, page 144
• FilesUpload Security Filter, page 146
• GlobalParameters Security Filter, page 148
• HTTPMethods Security Filter, page 151
• Logging Security Filter, page 154
• SafeReply Security Filter, page 157
• WebServices Security Filter, page 161
• XMLSecurity Security Filter, page 164
• Parameters Security Filter, page 168
• PathBlocking Security Filter, page 174
• Session Security Filter, page 175
• Vulnerabilities Security Filter, page 181
Caution: The filters are listed in a specific order.
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 132)
to enable refinements to be automatically added to the AllowList Security Filter. Refer to AllowList
Auto Policy Generation Refinements, page 222 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.

AppWall User Guide
Security Tools
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 12: 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
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.
Examples of permitted requests

GET /trashfire.mpeg HTTP/1.1
GET /images/image01.gif HTTP/1.1
GET /images/webhelp/15267.jpg HTTP/1.1 PUT /PostDestination/MyFile.txt
HTTP/1.1 HEAD /BackUpPages/JANold/admin.htm HTTP/1 .1 PUT
PostDestination/banner.png HTTP/1.1
Examples of prohibited requests

PUT /images/innocent.exe HTTP/1.1
GET multimedia/news real/trashfire .mpeg HTTP/1 .1 GET /NewPages/
specialoffers .htm HTTP/1 .1 OPTIONS /NewPages/ HTTP/1.1
POST /Portfolio/Orders.asp HTTP/1.1
GET /DB/students.dbf HTTP/1.1

AppWall User Guide
Security Tools
Configuring 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
To configure the AllowList Security Filter
1. In the Configuration view, select the AllowList Security Filter under the Filters node.
2. Ensure that Enable Log, Quick-Click Refinement, and Manage Refinement Usage Frequency are
selected. If not, select these fields and click Save and Apply Changes.
AllowList Security Filter — Global Settings and Refinements
To set the AllowList Security Filter Global Settings and Refinements
1. In the Security Policies View, select the AllowList Security Filter under the Filters node.
2. Right-click on the page and select Add or right-click an existing entry and select Edit to modify
it.
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.
4. Click Save and Apply Changes.

AppWall User Guide
Security Tools
Table 13: AllowList Options
Field Description
Application Path Select whether to apply only to a single Application Path or to all Application
Level Paths.
Refinement/
Global
Refinement
Web Application Web Application containing the Host.
Tunnel Tunnel containing the Host.
Host Host containing the Application Path(s) 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 begin with a forward slash ( “/” ) and end with either an extension or
a forward slash.
Use Regular Select to enable use of a regular expression in the Page definition. You must add
Expression a valid regular expression and escape all necessary characters.
Recurse to Sub Allows requests below the path specified. When disabled, only the pages and files
Directories 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.
>> 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.

AppWall User Guide
Security Tools
To accept or lock refinements to/from the AllowList Security Filter
1. In the Security Policies View, select the AllowList Security Filter under the Filters node. A list of
URIs currently permitted is displayed in the AllowList tab.
2. To move a refinement to the Locked list (in the Auto Policy Generation Locked tab), 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 Save and Apply Changes). 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 Save and Apply Changes).
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
AppWall Server, 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.
To enable the feature
1. In the Configuration View, select the Filters node.

2. Select the AllowList Security Filter and check the Manage Refinement Usage Frequency
checkbox.
3. Click Save.
To view refinements not matched by client requests
1. In the Security Policies View, select the Filters node.

2. Select the time frame to sort the list from the drop-down menu in the View refinements not
matched by client requests field. You may select All refinements, refinements from the past 1
month, 3 months, 6 months, 1 year, or by selecting a specific date.

AppWall User Guide
Security Tools
AllowList Security Filter Learn Mode

For general information about Learn Mode, see Working in Learn Mode, page 226.
AllowList refinements support Learn Mode, which provides ready-to-use configuration of the
different paths and pages of a Web Application.
When running in Learn Mode, all requests not defined in the Security Filter specifications are
automatically appended to the list of allowed path requests. They can be viewed on the Refinements
page in the Security Policies View. Appended requests are indicated by the Learn Mode icon in the
Tips column.
If you accept a Learn Mode specification, it will attain the status of Accepted. AllowList Learn Mode
entries can be edited during configuration, although the refinement contains a complete
specification that matches the request and can be accepted “as is” provided it is a request you want
to make available.
Because a Learn Mode entry comes from a specific Application Path, it is automatically attached to
the correct AppWall Server, Web Application, Tunnel, and Host.
Learn Mode entries should be reviewed prior to acceptance, because even invalid or manipulated
requests are re-registered in Learn Mode.
If your Web Application contains pages that are called from locations not falling under the scope of
the Application Path, Host, Tunnel, or Web Application, a configuration for these requests must be
considered. Often this can be the default Web Application. If you do not support the Default Web
Application, you must define additional security objects.
Learn Mode entries are saved to file to be used at a later point in time. After accepting the desired
entries, they are saved automatically. Click Apply Changes. All Learn Mode entries are saved to a
“.lrn” file to be available for future use. Individual learned entries cannot be deleted. All Learn Mode
entries can be deleted at once.
To delete all Learn Mode entries, click Clear Learned Entries in the Filter Node Popup Menu. All
Learn Mode entries are deleted.
Note: If a Learn Mode entry was edited before accepting and saving it to a file, the original
Learn entry will still appear in the refinements. Only Learn Mode entries that were
accepted as-is will not be displayed in the refinements as "Learn".
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.

AppWall User Guide
Security Tools
Based on these replies, in the event of a Brute Force attack, the number of Bad replies from the Web
Server (due to bad username, incorrect password, etc.) triggers the BruteForce Security Filter to
monitor and take action against the attacker.
All users connected through the same Proxy Server (e.g. 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 Full Auto Auto Policy Generation 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.
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.
For further information about basic configuration and procedures for the BruteForce Filter, refer to
the Online Reference guide (accessed by pressing F1 from within the Management Application).
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 14: 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 Shared in the Shared IP list. This can be used if the user wishes to treat all IP addresses
IPs as regular IPs.

AppWall User Guide
Security Tools
Table 14: BruteForce Security Filter Global Settings
Field Description
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 is displayed 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, scanners, etc.).
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 (wildcard cannot be first or be followed by anything
other than a wildcard).
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.
To configure the BruteForce Security Filter
1. In the Configuration View, select the BruteForce Security Filter under the Filters node.
2. Ensure that Enable Log and Quick-Click Refinement are selected. If not, select these fields and
click Save and Apply Changes.
3. In the Security Policies View, select the BruteForce Security Filter under the Filters node.
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 Add 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, click Add/Edit/Delete IP addresses that the Security Filter will not check
for Brute Force attacks (use this for known IPs, such as Administrators, Scanners, etc.).
10. Select the Profile to use to define thresholds for potential Brute Force attacks.

AppWall User Guide
Security Tools
To Manually add an IP to the Shared IP list
1. Click Add in the Shared IPs pane.

2. Follow the settings as described in the table below.
Table 15: 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 Add in the Ignored IPs pane.

Table 16: Ignored IP settings
Field Description
IP Enter the address of the Ignored IP.
Description Enter a description for the Ignored IP.
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 Add in the Profiles pane.

Field Description
Name Enter the unique name of the profile.
Description Enter a description for the Profile.

AppWall User Guide
Security Tools
Field Description
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.
To configure the BruteForce Security Filter Refinements
1. In the Security Policies View, expand the Filters node and select the BruteForce Security Filter.
2. Select the Refinements Tab and click Add.
3. Complete the fields using the table below and click OK.
4. Click Save.
5. On the AppWall Management Application toolbar, click Apply Changes.
Table 17: BruteForce Security Filter Refinements
Field Description
Web Application Web Application containing the Tunnel.

AppWall User Guide
Security Tools
Table 17: BruteForce Security Filter Refinements
Field Description
Host Host containing the Application Path(s) 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 Add.

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.
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 132)
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 User Guide
Security Tools
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.
For further information about basic configuration and procedures for the Database Filter, refer to the
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 and Learn Mode functionality, ready-to-use specifications are
generated that identify the rule that trigger the generation of an event or learned entry. Information
about the Rule ID can be found in Event Log Properties dialog box of the Security Log, which is
accessed by double-clicking the log entry.
By accepting the Learn Mode specification or 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
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.
To configure the Database Security Filter
1. In the Configuration view, select the Database Security Filter under the Filters node.
3. In the Security Policies View, select the Database Security Filter under the Filters node.
4. In the Settings Tab, click Add to add a rule ID to the Unscreened Rules List at the Global Level.
You can also edit or delete a rule using the Edit or Delete buttons.
5. Select the Refinements tab.
it.
7. Select either Excluded Parameters or Excluded Rules.
8. Complete the fields as described in the table below.

AppWall User Guide
Security Tools
Table 18: Database Security Filter settings
Field Description
Apply to Other When selected, the Security Filter will evaluate requests to undefined pages
Pages under the Application Path.
entry must begin with a forward slash (“/”) and 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 133.
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.
• 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.

AppWall User Guide
Security Tools
Example
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 Auto Policy Generation mode is not available for this Security Filter.
For further information about basic configuration and procedures for the FilesUpload Filter, refer
to the Online Reference guide (accessed by pressing F1 from within the Management
Application).
Configuring the FilesUpload Security Filter
To configure the FilesUpload Security Filter
1. In the Configuration view, select the FilesUpload Security Filter under the Filters node.
2. Ensure that Enable Log is selected. If not, select this field and click Save and Apply Changes.
3. In the Security Policies View, select the FilesUpload Security Filter under the Filters node.
it. You can also add extensions in the Settings tab.
5. Click Enable POST or Enable PUT to specify the valid upload type for this definition.
6. Click the General tab and complete the fields using the table below.
7. Click 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.
9. Click Save.
Table 19: FilesUpload Security Filter options
Field Description
Post Acceptor
Web Application 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.
Post Destination
Web Application Web Application that contains the script where the action is submitted.
Tunnel Tunnel used to monitor the upload destination.

AppWall User Guide
Security Tools
Table 19: FilesUpload Security Filter options
Field Description
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...
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
Post Destination. It is recommended that this setting be enabled.
Using PUT
Web Application 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...
Example Using POST

The following diagram represents the three possible locations involved in a POST transaction. Each
box represents a separate directory. Only the CGI directory and Upload Files Directory are
considered when configuring files uploading for the POST method.
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.
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 Bypass Parameter Flag, page 170.

AppWall User Guide
Security Tools
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: The Full Auto Policy Generation mode is not available for this Security Filter.
Example
For this 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.
Using the Default Expressions functionality, characters that are not valid for the database field
values are detected and the requests that contain them are stopped from reaching the Server.
In this example, the Security Filter is configured as follows:
— Default Expression settings restrict parameters to a length of 256 characters and allow word
characters, periods (.), commas (,), character (@), 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's parameters are first checked by the Global Regular Expression. Because the
request is not invalidated by the Global Regular 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:
Table 20: 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.

AppWall User Guide
Security Tools
Table 20: Parameter Types for GlobalParameters Security Filter
Type Description
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, i.e. 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 do this, in the
Security Policies View, select the GlobalParameters Security Filter under the Filters node and in the
right pane, select the Analyze All Participating Parameters field. Then click Save and Apply Changes.
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.
To validate parameters passed to the server
1. In the Configuration view, select the GlobalParameters Security Filter under the Filters node.
3. In the Security Policies View, select the GlobalParameters Security Filter under the Filters node.
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 Global Parameters Filter check box if required.
6. Select Force additional security validation by GlobalParameters Filter to assign the parameter a
Bypass Flag. For more information about the Bypass Flag, see Bypass Parameter Flag.
7. Click the Settings tab.
8. Right-click in the Parameter Validations area in the page click Add or right-click an existing
entry and select Edit to modify it. Then complete the fields using the table below.

AppWall User Guide
Security Tools
9. Click the Refinements tab to open the Configure Page Settings dialog box.
Table 21: 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.
Regular (Expressions only) Enables the use of a regular expression in the Page definition.
Expression You must add a valid regular expression and escape all necessary characters.
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 All Select to always check all parameters and ignore Bypass credentials.
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.
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.

AppWall User Guide
Security Tools
Default Status
The HTTPMethods Security Filter is enabled by default for all Application Paths under the AppWall
Server. Initially, only GET and POST methods are defined as valid. Any request containing another
HTTP method results in an event and blocks the request.
Example
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
To configure this 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
To set the HTTPMethods Security Filter defaults
1. In the Configuration view, select the HTTPMethods Security Filter under the Filters node.
3. In the Security Policies View, select the HTTPMethods Security Filter under the Filters node.
5. Use Add, Edit, or Delete to specify the default methods.
6. Click Save.

AppWall User Guide
Security Tools
HTTPMethods Security Filter Refinements
To set the HTTPMethods Security Filter refinements
1. In the Security Policies View, expand the Filters node under the AppWall Server and select the
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, right-click anywhere in the page and select Add, or right-click an entry and
select Edit to modify one.
4. On the Configure Page Settings dialog box complete the fields using the table below and click
OK.
5. Click Save.
— Header—Description
— Tips—Displays icons that appear if the Security Filter is operating in Learn Mode.
— Web Application—Web Application containing the Host.
— Tunnel—Tunnel containing the Host.
— Host—Host containing the Application Path(s) where the Security Filter should be used.
— Application Path—Application Path where the Security Filter should be used.
— 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
begin with a forward slash (“/”) and 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:
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 22: 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

AppWall User Guide
Security Tools
Table 22: HTTPMethods example
Path HTTP Methods Definition

WebPages/Main/Public/JJ/ GET, DELETE, COPY, /Main/Public/JJ/
PUT
WebPages/Main/Public/JJ/ upload.asp POST only /Main/Public/JJ/upload.asp
HTTPMethods Security Filter Learn Mode

When running in Learn Mode, the HTTPMethods Security Filter logs all requests containing HTTP
methods not already specified in the Default HTTP Methods list. This applies to all Application Paths
where the HTTPMethods Security Filter is in Learn Mode.
From Learn Mode entries you can process the registered methods and accept those you want to
keep. Learn Mode specifications contain specifications up to the directory level and will not
automatically include file names in the refinement configuration.
For general information about Learn Mode, see Working in Learn Mode, page 226.
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,
select the Application Path in the Security Policies View 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 23: 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 Request Header Disabled
Log Request Body Disabled

AppWall User Guide
Security Tools
Example
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
Example 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##
e /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
Example 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

AppWall User Guide
Security Tools
Response:
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
To configure the Logging Security Filter
1. In the Configuration view, select the Logging Security Filter under the Filters node.
3. In the Security Policies View, select the Logging Security Filter under the Filters node.
4. Modify the request/reply properties as required.
5. Click Save.
Table 24: 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

AppWall User Guide
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 (Visa, MasterCard,
Discover, American Express, etc.)
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 for-mat
such as an account or form number.
Any response message containing numbers not conforming to the Security Filter con-figuration will
be blocked and generate an event.
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 further information about basic configuration and procedures for the SafeReply Filter, including
the credit card / social security number types and ranges supported, refer to the Online Reference
guide (accessed by pressing F1 from within the Management Application).
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 (e.g. MS Excel files), the ICAP
server will modify the file. In cases where the file cannot be modified (e.g., 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.

AppWall User Guide
Security Tools
Figure 47: SafeReply Filter Enabling
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
To configure the SafeReply Security Filter
1. In the Configuration view, select the SafeReply Security Filter under the Filters node.
3. In the Security Policies View, select the SafeReply Security Filter under the Filters node.
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.

AppWall User Guide
Security Tools
9. In the Custom Pattern List area, click Add to add a custom pattern or select a pattern and click
Edit to modify an existing one. You may also delete a pattern or use the check box in the
Enabled and Expression columns to enable/disable it.
10. On the dialog box that displays specify the pattern using the table below and click OK.
11. Click Save.
Table 25: 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, expand the Filters node and select the SafeReply Security Filter.
2. In the right pane, right-click in the page and click Add or right-click an existing refinement and
click Edit.
3. Complete the fields using the table below and click OK.
4. Click Save.
Field Description
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
forward slash.
Pathname Specify the relative URL to the page.
Pattern List Pattern to which the refinement applies the exemption.

AppWall User Guide
Security Tools
Field Description
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

Table 27: 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, 648- NM
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

AppWall User Guide
Security Tools
Table 27: SSN Types and Ranges
Range Area Range Area Range Area

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.
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 Auto Policy Generation
mode is not available for this Security Filter.
Example
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

AppWall User Guide
Security Tools
<?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.
For further information about basic configuration and procedures for the WebServices Filter,
refer to the Online Reference guide (accessed by pressing F1 from within the Management
Application).
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 the WebServices Security Filter under
the Filters node. Ensure that Enable Log is selected. If not, select this field and click Save and
Apply Changes.
• 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.
• Operation Name—Validates XML and ensures that requests use allowed operations.
• Operation name and Structure—Validates the XML and Operation name, and that the
WebServices message complies with all WSDL requirements, such as enforcing parameter order,
operation sequence, etc.
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

AppWall User Guide
Security Tools
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 28: 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.
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.
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 and Structure—Validates the XML and operation name,
and that the message complies with all WSDL requirements.
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.

AppWall User Guide
Security Tools
Managing WSDL Files

Use the following procedures to manage your WSDL files.
To import a WSDL file
1. In the Security Policies View, expand the Filters node and select the WebServices Security Filter.
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/xmlContent-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.
Example
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).
Assume also that the following HTTP request message is received with an XML body:

AppWall User Guide
Security Tools
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.

AppWall User Guide
Security Tools
Table 29: Parameter Names and Values
Name Value
xml//catalog/book/title “War and Peace”
xml//catalog/book/price 20
xml//catalog/book/price/ EUR
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”
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
To configure the XMLSecurity Security Filter
1. In the Configuration view, select the XMLSecurity Security Filter under the Filters node.
3. In the Security Policies View, select the XMLSecurity Security Filter under the Filters node.
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.
7. Click Save.

AppWall User Guide
Security Tools
Table 30: 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.
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.
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 XML These are page definitions that will be included in the parsing and 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 XMLSecurity 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 XMLSecurity Security Filter. This includes Adding, Deleting
and Editing Settings, such as modifying Include and Exclude pages, Re-curse functionality and more.

AppWall User Guide
Security Tools
To manage the XMLSecurity Security Filter Specifications
1. In the Security Policies View, select the XMLSecurity Security Filter from the Filters node.
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. Right-click in the page and click Add to add or select an existing entry and click Edit to modify
one.
5. On the Configure Page Properties 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 Save and Apply Changes for your settings to take effect.
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 con-figuration. 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, mailing address, etc.
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 218) to enable
refinements to be automatically added to the Parameters Security Filter. Refer to Parameters Auto
Policy Generation Refinements, page 223 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.

AppWall User Guide
Security Tools
Table 31: 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.
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, i.e. 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: Evaluates the parameters you specify and generates an event when a
parameter does not conform to requirements. Requests containing other parameters are not
evaluated and no events are generated by these requests.
Restricted Parameters with Validation: Evaluates the parameters you specify and generates an event
if the evaluated parameter does not conform to requirements. Also generates an event when a
request contains any parameter that you have not specified.
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.

AppWall User Guide
Security Tools
Example
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.
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.
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.
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 that the Parameters Security Filter checks all parameters that pass the GlobalParameters
Security Filter checks. It does not accept the bypass credentials.

AppWall User Guide
Security Tools
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
To configure the Parameters Security Filter
1. In the Configuration view, select the Parameters Security Filter under the Filters node.
2. Ensure that Enable Log, Quick-Click Refinement and Auto Policy Generation are selected. If not,
select these fields and click Save and Apply Changes.
3. In the Security Policies View, select the Parameters Security Filter under the Filters node.
4. In the right pane, complete the fields using the table below.
5. Click Save.
Table 32: 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.
GlobalParameter When not selected, parameters will be evaluated, if required, by subsequent
s 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 (e.g., start.cgi) or
multiple pages.
To set query parameters
1. In the Security Policies View, expand the Filters node and select the Parameters Security Filter.
3. In the right pane, click the Page tab.
4. To add a parameter, right-click anywhere in the Page area and select Add. To edit an existing
parameter, right-click it and select Edit.

AppWall User Guide
Security Tools
5. Complete the Manage Parameters - Query Parameters dialog box using the table below.
6. In the Parameters List area, click Add to add a parameter definition for the page or select an
existing definition and click Edit to modify one.
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.
8. To prevent the page and all its parameter(s) from being modified by Auto Policy Generation, click
the Lock checkbox. A padlock icon is inserted next to the parameter(s).
9. Click OK.
10. On the AppWall Management Application Console toolbar, click Apply Changes.
Table 33: 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.
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
parameter(s).
Setting Path and Cookie Parameters
To set path and cookie parameters
1. In the Security Policies View, expand the Filters node and select the Parameters Security Filter.
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, right-click anywhere in the Path/Cookie area and select Add. To edit an
existing parameter, right-click the parameter and select Edit.
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 Add to add a parameter definition or select an existing
definition and click Edit to modify one.
7. On the dialog box that displays, complete the fields on the Name and Value tabs and click OK.

AppWall User Guide
Security Tools
8. Click Save.
Table 34: 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 35: 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
Parameters Auto Policy Generation Refinements

The Auto Configuration option collects traffic and statistical data in order to determine the automatic
refinement of Security Filters. For an overview of the Auto Configuration feature, see Auto
Configuration.
Note that in order to globally implement the Auto Configuration option for the Parameters Security
Filter the Auto Configuration checkbox in the Configuration View, when selecting Parameters from
the Filter node, should be selected (it is selected by default). If not selected, the Auto Configuration
option will be disabled when accessing from alternative views (for example, when accessing the
Filters or an Application Path in the Security Policies View).
When enabled, the refinements listed in the Refinements tab (accessed from the Security Policies
View) are automatically generated by the Auto Configuration 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.

AppWall User Guide
Security Tools
Parameters Security Filter Learn Mode

When operating in Learn Mode, the Parameters Security Filter registers all parameters contained in
user requests and displays them in the Parameters Security Filter in the Security Policies View.
Because enabled Security Filters are automatically sequenced before Learn Mode Security Filters,
verify that all enabled Security Filters are properly configured or disabled before operating Learn
Mode. Events generated by enabled Security Filters will not be learned.
Note: Learn Mode does not provide refinements for parameters using the Expressions value
type.
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
that the Full Auto Auto Configuration mode is not available for this Security Filter.
Example
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
To configure the PathBlocking Security Filter
1. In the Configuration view, select the PathBlocking Security Filter under the Filters node.

AppWall User Guide
Security Tools
3. In the Security Policies View, select the PathBlocking Security Filter under the Filters node.
4. Right-click anywhere in the page and click Add to add a path. Or right-click an existing entry
and click Edit to modify a path.
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.
6. Click Save.
Table 36: 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 Configuration module
prevents “Predictable Resource Location” Attacks on the protected application.
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:

AppWall User Guide
Security Tools
• 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 the AppWall Server 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)

The Session Security Filter prevents remote users from submitting modified parameter values stored
in HTML Forms by the application.
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
multi=select 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.
For further information about basic configuration and procedures for the Session Filter, refer to the
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.

AppWall User Guide
Security Tools
Session Security Filter Global Settings
To configure the Session Security Filter
1. In the Configuration view, select the Session Security Filter under the Filters node.
3. In the Security Policies View, select the Session Security Filter under the Filters node, and select
the Settings tab.
4. Use the table below to complete the fields in this tab and click OK.
5. Click Save.
Global Cookies Settings

Deny Requests with This setting blocks the HTTP Request and sends a security page if the
Untrusted Cookies cookie is deemed invalid. When disabled and the cookie is deemed invalid,
the Security 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
Ownership (Client IP client IP that it was issued to. If it is not, the cookie will be considered
Binding) invalid.
Default Mode: Allow Selecting this mode automatically encrypts all cookies in undefined/
Cookie Auto Protection disabled Application Paths.
– All Cookies are
Encrypted
HTTP Reply Body
Do not parse HTTP When the flag is set, the filter will encrypt protected links even if they
Replies across appear in Application paths that do not have the session filter activated. For
Application Paths example, in Application path \Sale\ , all parameters to sale.aspx are
requesting to be protected. Links to: /Sale/sale.aspx will be protected even
if they exist in any other folder. There is a material effect on performance
as ALL text/html responses need to be parsed.
Cookies Secured This mode preserves the original value but adds a new signature. It does
Mode not hide the original value of the parameter / cookie and thus the level of
security is decreased but it is required when client side applications process
the parameter / cookie value as part of their legitimate functionality.
Values: Sign or Encrypt
Parameters Secured This mode preserves the original value but adds a new signature. It does
Mode not hide the original value of the parameter / cookie and thus the level of
security is decreased but it is required when client side applications process
the parameter / cookie value as part of their legitimate functionality.
Values: Sign or Encrypt
Prefix
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.

AppWall User Guide
Security Tools
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 is displayed 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 the Session Security Filter under the Filters node.
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.
4. Click Add to add refinements, or right-click an existing entry and select Edit to modify it.
5. Complete the fields and click OK.
6. Click Save and on the AppWall Management Application Console toolbar, click Apply Changes.
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(s) 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 are displayed (disabled). Host cookie definition will only be added to the
Application Path if the Validation and Encryption mode are the same.
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).
Refinement Level
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.
Protected Cookies
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.

AppWall User Guide
Security Tools
Field Description
All Except for By enabling the Session Security Filter in All Except for Listed Cookies operational
Listed Cookies 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.
Host Host containing the Application Path(s) where the Security Filter should be
applied.
Application Path Application Path where the Security Filter should be applied.
Tips The Tips column displays an icon representing refinements generated from Learn
Mode entries.
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.
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.
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
Protected URLs
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.
applied.
Mode entries.
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.

AppWall User Guide
Security Tools
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
Protection Mode
Hide Select this option to hide the real parameter values and instead display random
characters according to the number of characters in the value. For example, a
bank account number with 9 characters is displayed with 9 random characters.
In this mode, the values cannot be modified.
Protect Select this option to block a user from modifying a value. Default.
Protected Parameters
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.
applied.
Mode entries.
Name Displays the name of the Parameter.
To configure Session Security Filter Application Path refinements
1. In the Management Application Policies View, select the Session Security Filter under the
Application Path. The following displays:
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 Add to add an Application Path refinement (in order to add multiple refinements to an
application path, click an existing entry and select Edit to add additional refinements to the
Application Path).
5. Complete the fields and click OK.
6. Click Save and on the AppWall Management Application Console toolbar, click Apply Changes.

AppWall User Guide
Security Tools
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.
Examples
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 prettypark.exe, prettypark.bat, etc.
— 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&pass-word=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 the Vulnerabilities Security Filter under the Filters node.
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 Save and Apply Changes.
4. Right-click in the page and click Add to add a pattern or right-click an existing pattern and click
Edit to modify one.

AppWall User Guide
Security Tools
6. To add a Custom Pattern.

7. Click Save.
Table 37: 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
To configure the Vulnerabilities Security Filter
2. In the left pane, select the Settings tab.
3. Right-click in the page and click Add to add a pattern or right-click an existing pattern and click
Edit to modify one.
4. Ensure that Enable Log and Quick-Click Refinement are selected. If not, select these fields
and click Save and Apply Changes.
6. In the Custom Patterns - Active patterns Panel click Add. An Add a Custom Pattern dialog box
opens as shown here.
7. Mark the expected location checkboxes as required.
8. Enter a pattern from the drop-down list that includes the following:
.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.

AppWall User Guide
Security Tools
Table 38: 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 and select the Refinements
tab.
2. Right-click the 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.
4. Click Save.
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.
>> 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 CTRL+A and CRTL+C 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.

AppWall User Guide
Security Tools
>> 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 Add. 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.
To facilitate monitoring and protection, AppWall Management Application employs a special instance
of a Web Application named the Default Web Application. The Default Web Application can be set to
evaluate all traffic on all Application Paths not defined in existing Web Application definitions. One
Default Web Application exists for each AppWall Server and can be enabled or disabled as needed.
Table 39: 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.

AppWall User Guide
Security Tools
Figure 48: 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 49: 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.

AppWall User Guide
Security Tools
Table 40: 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.
To allow for the monitoring and protecting of web resources not covered under your existing Web
Applications, the AppWall Server uses the Default Web Application, which automatically monitors
and protects all application paths not covered within the Web Applications you have configured. One
Default Web Application exists for each AppWall Server and each can be enabled or disabled as
needed.
Creating a Web Application

The AppWall Management Application includes a wizard for creating a Web application. The wizard
lets you assign an existing tunnel and host or to create new ones, and select whether to enable Auto
Policy Generation for the Web application.
To create a Web Application
1. In the Security Policies view, select the AppWall Server Group > AppWall Server > Web
Applications node.
2. Right-click the Web Applications node and select Wizard. The Web Application Creation dialog-
box displays.
3. Provide a name for the Web application.
4. Select one of the available tunnels from the Available Tunnels drop-down list.
5. Select an available host.
6. Provide a security page, which can be either a relative or absolute path to the page returned to
a client for an invalid (blocked) request. Application paths define the base application path of
your new Web application.
7. Select the Auto Policy Generation mode (rapid or enhanced):
Rapid— This mode 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 as defined in the Web Application
Wizard.
— 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 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.

AppWall User Guide
Security Tools
Enhanced—A policy generated by this mode includes the following characteristics:

— The automatic generation of application paths where the base application path is defined in
the Web Application wizard.
— 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 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.
• Parameters
• Global Parameters
• Session
8. Select a Traffic Analysis profile. For additional information on Traffic Analysis profiles, see
Security Filters in Detail, page 134.
9. On the Management Application toolbar, click Apply Changes.
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. If the Default Web Application is enabled, it will monitor and
protect any Application Paths not defined in other existing Web Applications objects.
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 Save in the Content Area.
4. Click Apply Changes on the toolbar.

AppWall User Guide
Security Tools
Deleting a Web Application

The procedure allows you to delete a Web Application. The Default Web Application cannot be
deleted.
To delete a Web Application
1. In the Security Policies View, right-click the Web Application and select Delete Web
Application from the right-click menu. A confirmation dialog box appears.
2. Click Yes in the confirmation dialog box.
Adding Tunnels, Hosts, and Application Paths

There are two ways to configure a Web Application’s child objects.
• Right-click an object in the hierarchy and select Add, Edit, or Remove.
• Select a Web Application and use the Web Application wizard as described below.
To add Tunnels, Hosts and Application Paths
1. In the Security Policies View, right-click the Web Application and select Wizard.
2. Complete the wizard fields using the table below.
Available Tunnels Select an existing Tunnel from the drop-down list or click Add a New Tunnel
to create one.
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.
3. Click Save in the Content Area.

4. Click Apply Changes on the toolbar.
Notes
>> You cannot remove the last remaining Tunnel definition without deleting the Web
Application security object.
>> Removing a Tunnel also removes all subordinate definitions of the Tunnel within the Web
Application.

AppWall User Guide
Security Tools
>> Removing a Tunnel from a Web Application does not remove the Tunnel from the
AppWall Server configuration displayed in the Configuration View.
>> 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>. When not using <Any
Host>, all undefined hosts will attempt to rollover to the Default Web Application.
>> You cannot delete anything from the Default Web Application. If you disable the Tunnels
inclusion in the Default Web Application, you can eliminate rollover functionality and all
undefined virtual hosts will be considered invalid. This setting is performed from the
Configuration View in the Tunnel Properties field.
Hosts
Each host added to the tunnel (Configuration > 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)
• Authentication and User Tracking Properties (set under the host)
• Adding Web roles and setting their properties
User Tracking, Authentication, and Single Sign-On

AppWall includes a user tracking, authentication enforcement, redirection to login page, and single
sign-on mechanism in your secured application.
Note: Redirection to the login page will be enforced when a “public” (non-authenticated) user
attempts to access a resource prohibited for public users. The AllowList and Path
Blocking security filters enable creating a 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
will be 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.
To set user tracking settings
1. Select the Host object in the Security Policy view. In the Authentication tab, enable the
authentication mechanism.
2. In the Login Properties section, click Add and set the Login URI, Method, Username Field, and
Password Field.
3. Optionally, in the Logout Properties section, click Add to add Logout URIs.
4. Optionally, in the HTTP Session Tracking section, configure the relevant cookie name for correct
user tracking in case of an unsuccessful login.

AppWall User Guide
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.
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 user only after authentication. For
example, if the Public role can access only the /public/ folder and access to all other folder is
prohibited, only authenticated user 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 or RADIUS), 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).
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, 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.
To configure redirection to local login page (under the same domain)
1. In the Security Policy view, select the Host object.

2. In the User Tracking and Authentication tab, enable the authentication mechanism.
3. In the Redirect to Login combo-box, select Local.
and Password Field.

AppWall User Guide
Security Tools
To configure Single Sign-On (for sub-domains and cross-domains)
1. In the Security Policy view, in the Single Sign-On host, select the Host object.
2. In the User Tracking and Authentication tab, enable the authentication mechanism.
3. In the Redirect to Login combo-box, select Is Single Sign On Server.
and Password Field.
8. In the host which uses the Single Sign-on services on the other host, in the Redirect to Login
combo-box, select Use Single-Sign-On.
9. In the Login URI you have the option to select from a list of URIs of the different Single Sign-on
servers you have already configured. Select the URI to which the users will be redirected when
trying to access secured application content.
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 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 211.

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. They very least you should activate is the SafeReply Filter,
while the more Filters activated for folders of this type, the better.
Role-Based Security Policies for LDAP Managed Users

AppWall lets you define different policies for different Web Application roles. After you have
configured an LDAP server, defined Web roles, and specified host authentication settings, you can
add the defined roles to your host. You can add to each role its own application paths with their own
security filters and refinements.

AppWall User Guide
Security Tools
The Public role is assigned with pre-defined application paths if you are adding a new role. Roles
other than Public require proper user authentication and association to that role.
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
To add a new role-based security policy
1. Right-click the Host object in the Security Policy view, and select Add User Role.
2. Right-click a role object, and select Add to add a new application path.
To add a shared application path across roles
For easier role-based policy management, you can define an application path to be shared
across multiple roles. This lets you define a policy once and be able to refer to it from different
roles.
1. Create the application path under any role.
2. Right-click a role object, and select Add Shared Application Path to share an already existing
application path across roles.
Web User Roles

Having configured your authentication server, you are now ready to define a web user role.
To configure a web user role
Web User Roles.
2. In the Add Role dialog box, specify the parameters using the table below.
3. Click OK.
Table 41: Web User Role options
Field Description
Name Name of the role
Type Set the authentication type.
Values:
• LDAP
• RADIUS
• IP-based
Authentication The authentication server configured for the authentication type you selected
Server displays.
Members Add members associated with this Web role.

AppWall User Guide
Security Tools
IP-Based Role
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:
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:
Examples:
1. 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.
2. 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).
Security Page
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
(e.g. transaction ID) or to present different messages depending on the type of violation.
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>

AppWall User Guide
Security Tools
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.
Changing the default value to javascript (as in the example below) will enable the setting.
<InternalParams>
...
<InsertEventDataIntoPage>javascript</InsertEventDataIntoPage>
...
</InternalParams>
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.
This section refers how to distribute a configured Application Path to other AppWall Servers. For
information on how to add an Application Path to a Web Application, see Adding Tunnels, Hosts, and
Application Paths, page 188 in the previous section.
Distributing an Application Path to other AppWall Servers

Use the Application Path Policy Distribution wizard to:
• Distribute an Application Path configuration to other AppWall Servers.
• Export an Application Path to a File.
• Import an Application Path configuration.
This section describes how to use the Application Path Policy Distribution wizard to perform these
tasks.
Distributing an Application Path configuration to other AppWall Servers
To distribute an Application Path configuration to other AppWall servers
1. In the Security Policies view, right-click the AppWall Server that contains the configuration files
you want and select Distribute Application Path. The Application Path Policy Distribution
wizard is displayed.
2. Click Next to begin.

AppWall User Guide
Security Tools
3. In the Options dialog box, choose Distribute to one or more AppWall Servers and click Next.
4. In the AppWall Server List dialog box, select an available Server from the list and click Next.

AppWall User Guide
Security Tools
5. Select the destination Tunnel and Host to which the policy is to be copied, and click Next.
6. Select whether to Override Existing Application Path in Server or to Manually Define Web
Application Assignment and click Next.
7. In the Summary dialog box click Next to accept the properties of the distribution.

AppWall User Guide
Security Tools
8. Select the Backup Server Configuration checkbox to create a backup of the Server
configuration and enter a name for the backup.
9. Click Next to continue.
10. To end the distribution wizard, click Finish.
Exporting an Application Path Configuration to a File

you want to export and select Distribute Application Path. The Application Path Policy
Distribution wizard appears.
3. In the Options dialog box, choose Export to a File and click Next.

AppWall User Guide
Security Tools
4. Select the name of the directory to contain the configuration backup and a description of the
backup.
6. To end the backup procedure, click Finish.
Importing an Application Path Configuration File

you want and select Distribute Application Path. The Application Path Policy Distribution
wizard appears.
3. In the Options dialog box, choose Import File to Distribute and click Next.

AppWall User Guide
Security Tools
4. In the Import Format dialog box, select Server or Tunnel distribution and click Next.
5. In the Import from a File dialog box, select a configuration from the list or browse to the
appropriate directory and click Next.
6. In the Summary dialog box, confirm the import properties and click Next.

AppWall User Guide
Security Tools
7. Select the Backup Server Configuration checkbox to create a backup of the Server
configuration and enter a name for the backup.
9. To end the Import file wizard click Finish.
When Not to Use Policy Generation

• When the AppWall accepts connections only from a single IP address as source IP (e.g. due to a
Reverse Proxy installed in front of AppWall)
• When the AppWall IP-Blocking feature is in use. IP blocking might impact statistical processing.
• When a caching system is used and implemented in front of AppWall, as it might impact the
statistical calculations.
• When the web application is static.
• When full control over Security Policies is required.

AppWall User Guide
Security Tools
Managing Security Filters at the Application Path Level

This topic provides an overview of using AppWall Server 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 Learn
• Working with Auto Policy Generation Profiles
• Refining Security Filters Definitions
Security Filter Overview

The AppWall Server 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.
The AppWall Server’s base security protection is the Default Web Application, which serves as an
“umbrella” security policy. This guarantees that any request is subject to this minimum set of
checks.
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 Learn
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).
• Learn mode records traffic that would trigger the Security Filter if it were enabled, allowing you
to later configure the Security Policy based on this information.
• 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 218.
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 Generation Profiles for information on working with Auto Configuration
profiles, which provide a pre-defined configuration.

AppWall User Guide
Security Tools
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 the Automation Level tab, and then select
Active, Passive, Learn or Disable in the Mode column (Note that this action is only available if the
Manual option is selected) according to the requirements of your Web Application.
In addition, you can select an Automation level, such as Auto Refinements (for AllowList,
Parameters, and Database Filters) to work with the selected Filter mode. For example, selecting
Active and Auto Refinements ensures that while traffic triggered by the Filters is stopped, the
Auto Refinements option works in the background and will still generate refinements. Similarly,
selecting Learn and Auto Refinements ensures that while traffic is still recorded and potential
security risks identified, the Auto Refinements option still generates refinements.
3. Click Save in the Content Area, and click Apply Changes on the toolbar.
Note: For instructions on using Learn mode for a Security Filter.
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.)

AppWall User Guide
Security Tools
• 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.
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 (e.g., 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.
This mapping will enable the internal AppWall web crawler to access the relevant web server when
being provided with a start crawling URL.
To map hosts to web servers
1. In the Gateway, click on the Configuration view. Select Hosts.

2. The Hosts to Web Server Bindings window appears.
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

AppWall User Guide
Security Tools
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 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.
The CSRF protection is set at the host level in the Host section.
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.
By default the protection is enabled for POST messages only.
You can configure a list of excluded URIs for the CSRF inspection.

AppWall User Guide
Security Tools
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 (e.g. 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 (e.g., 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 (e.g., /EmailSignature/image/).
To access Hotlinking
1. Go to Security Policies tab, then Gateway and select Hosts > [A Host]. The Host window
appears.
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.
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.

AppWall User Guide
Security Tools
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.
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 206
• Defining Enterprise Requirements, page 207
• Setting a Security Policy, page 209
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.
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 (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 42: What needs Protection?
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

AppWall User Guide
Security Tools
Table 42: What needs Protection?
Requiring Protection
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 Learn or Passive mode with the Auto Refinements option
enabled where relevant. Once AppWall appears to have learnt 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 132.
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 184 provides an overview of a typical Web Application and some of
the security considerations that may offer some guidance to your own security requirements.
What Are My Enterprise’s Requirements?
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 209.
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 209. It is
also recommended to run the Full Auto Auto Configuration option. If your knowledge is expansive,
Radware recommends you look at additional sections in this Guide or the Online Reference Guide
(accessed by pressing F1 from within AppWall Management Application) 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 Configuration
(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.

AppWall User Guide
Security Tools
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 Configuration 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 209. 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.
Example 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.
Figure 50: Web Application Example
This folder (which could also be called /images) 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.
This folder contains a shopping cart script, as well as a login page. These are Dynamic pages, which
require user input via parameters. There is also a backend database and cookies, which both need
protecting.
This folder might contain 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.

AppWall User Guide
Security Tools
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
• Default Web Application
• 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 129.
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.
Table 43: Filters affecting Performance
Filter Effect on Performance

AllowList Minimal, though if Auto Configuration is activated, performance can be
affected.
BruteForce Minimal
Database Minimal-Medium, though if Auto Configuration is activated,
performance can be affected.
FilesUpload Minimal
GlobalParameters Minimal
HTTPMethods Minimal
Logging High
Parameters Minimal, though if Auto Configuration 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

AppWall User Guide
Security Tools
Recommended Filters
The following table provides a basic guideline on what Filters you can apply, according to what you
need to protect.
Table 44: Recommended Filters
Filter Recommended for Static Recommended for Recommended for

Pages Dynamic Pages Admin Content
AllowList x ? ?
Only if the
PathBlocking Filter is
not activated
BruteForce Usually not required ?
Login pages only
Database If you require high ? ?
performance, do not
activate this Filter
FilesUpload x Only where relevant
GlobalParameters Recommended only when there are Global Parameters
HTTPMethods ? ? ?
Logging x x x
Parameters x ? ?
Only if the
PathBlocking Filter is
not activated
PathBlocking Only where relevant for folders or Web Applications ?
that should not be accessed
SafeReply x If you require high ?
performance, do not
activate this Filter
Session ?
Only when cookies are being protected
Vulnerabilities ? ? ?
WebServices Usually not required ?
Only when Web Services are in use
XMLSecurity Usually not required ?
Only when XML is in use
Default Web Application

The default Security Policy that comes built-in with AppWall is implemented via the Default Web
Application. This default Policy depends on whether you are working with an AppWall Gateway, but
ensures a basic level of security that allows minimal maintenance. However, if you want to improve
security and ensure that your Security Policy also proves beneficial to your Web Application’s
performance, Radware recommends you use, as a minimum, the guidelines in the following
sections.
Default AppWall Gateway settings include the following:
• Dynamic Pages, page 211
• Static Pages, page 214

AppWall User Guide
Security Tools
• Administrator Related Content—User Specific, page 216

Security Filters set to Active:
• Vulnerabilities
• HTTPMethods
• Session
• Database
• SafeReply
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. From the Configuration View, create the Tunnel that represents the Web Application.
2. In the Security Policies View, add a new Web Application (or use the Default Web
Application) and Application Path that represent the structure of your Web Application (see
Logical Objects, page 185).
3. When adding a new Web Application with the Web Application wizard, you can select the Create
Application Paths Automatically option 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.
4. In the Security Policies View you can select the required Security Filters to apply to the
Application Path, though refer to Step 6 for further information on the Security Filters required.
By default, when working in Manual mode rather than with Auto Configuration enabled, the
Vulnerabilities, HTTPMethods, Session, Database, and SafeReply Security Filters should be set to
Active for the Application Path.
5. Map out your site to display folders with relevant properties – media files, login pages,
administrator files/folders – via the Web Application wizard in which you can select the Create
Application Paths Automatically option, or by using Auto Discovery (see Auto Discovery,
page 228). 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.
6. 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 218) and that you are manually applying your Security Policy. The following
list is a general list of the options available for dynamic pages. See Step 7 for details on which
mode to apply the Security Filters and Step 8 for details on how to apply the most effective
order to your Security Filters.

AppWall User Guide
Security Tools
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.
Note: 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.
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 HTTP Properties for the
Tunnel by selecting the ‘Analyze Path Parameters’ checkbox. Path Parameters are
embedded parameters in the request message URL (e.g. 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.
d. 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 Configuration, 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.
e. 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.
f. XML— If you are working with XML pages, activate the XMLSecurity Filter, which has
minimal impact on performance.
g. 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.
h. 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.
• 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.
• 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.

AppWall User Guide
Security Tools
• 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.
7. After determining the Security Filters required in Step 6, you can apply the Filter mode via the
Automation Level tab, as shown below, according to your requirements and, more importantly,
your environment. Listed below are some basic guidelines. For additional information, see the
appropriate section.
Figure 51: Automation Level Tab
If you are working with the following Filters, Radware recommends you use them in Active mode,
rather than Learn mode. Note that Learn mode should never be used in a Production environment,
as the Web Application is not protected in this mode, while the Learn mode’s impact on performance
can often be high.
• SafeReply
• Database
• Session
• Vulnerabilities
• HTTPMethods

AppWall User Guide
Security Tools
If you are working with the following Filters and are in a Test environment, you should use them in
Learn or Passive mode, together with Auto Configuration 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 Configuration enabled. After ensuring via refinements and the event log
that events are being generated only for blocked files, you should move to Active mode, with Auto
Configuration still enabled.
8. 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, as shown in the image in Step
7).
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.
9. 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 184, 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.
To create your Security Policy for static pages

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.

AppWall User Guide
Security Tools
User Tracking and Host Authentication

AppWall includes a user tracking and authentication enforcement mechanism in your secured
application.
If you enable User 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
2. In the Login Properties section, click Add and set the Login URI, Method, Username Field, and
Password Field.
3. Optionally, in the Logout Properties section, click Add to add Logout URIs.
4. 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.
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
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).
To configure the authentication settings
and Password Field.
3. In the Logout Properties section, click Add to add Logout RUIs.
4. 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.

AppWall User Guide
Security Tools
5. 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).
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 184,
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

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.
Defenses Properties
This section contains the following topics:
• Landing Pages, page 216
• Bot List, page 217
• Search Engine Referer, page 217
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.
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.

AppWall User Guide
Security Tools
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.
The default values on the Bot list are the different values of ‘user-agent’ header in HTTP transactions
sent for all the known search engine bots. Additional values can be added to the list.
AppWall uses the ‘user-agent’ HTTP header to prevent from non-legitimate clients from accessing
our web application. As part of Hot-link attack mitigation, AppWall will ignore HTTP requests with
‘user-agent’ header values which are listed in on the bot list.
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.

AppWall User Guide
Security Tools
Auto Policy Generation

The Auto Policy Generation feature provides AppWall administrators with the best tool for
automatically generating application paths using the required security filters, and for configuring
security filters that 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.
You can select one of the Auto Policy Generation modes as part of the Web Applications Wizard. Auto
Discovery lets you automatically discover the structure of a web application (see Auto Discovery,
page 228), while at the same time Auto Configuration sets the relevant security filters for each of
the Web Application’s directories.
This section contains the following topics:
• Rapid Auto Policy Generation Mode, page 218
• Extended Auto Policy Generation Mode, page 218
• Security Filter Auto Policy Generation Tools, page 219
• Working in Learn Mode, page 226
• Auto Discovery, page 228
• Web Crawler, page 231
Rapid Auto Policy Generation Mode

Rapid auto policy generation mode 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 as defined in the Web application
wizard.
• Tunnel Auto policy generation automatically adjusts the HTTP message sizes and generates
• 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.
Extended Auto Policy Generation 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 an
advanced mode automatically-generated policy is higher, and the time for generation of such a
policy is longer, than for simple mode.
A policy generated in this mode includes the following characteristics:
• The automatic generation of application paths where the base application path is defined in the
Web application wizard.
• The Tunnel Auto policy generation automatically adjusts the HTTP message sizes and generates
• The following filters are used and configured by automatically adding refinements:

AppWall User Guide
Security Tools
— 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
Working with Auto Policy Generation Profiles

This topic describes how to select an Auto Configuration Profile. A Profile is a pre-defined
configuration that defines how refinement probabilities are generated.
To select a Profile
1. In the Security Policies View, click on the AppWall Server to display Server properties in the right
pane.
2. In the Auto Policy Generation Properties section, select the relevant Profile from the drop-down
list:
— Production - Automatic—Analyzes traffic properties from the production environment and
builds a dynamic network profile for a specific site according to which the Auto Configuration
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)- Manual Crawling—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-At Once—Suitable only for demonstration purposes in an attack-free environment.
Do not use in production environments. Generates a policy within matter of minutes.
3. Click Save, and click Apply Changes on the toolbar.
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 220
• Auto Enabled, page 221
• Auto Refinements, page 222

AppWall User Guide
Security Tools
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, Learn,
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 223.
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, please refer to Appendix E.
There are also other occasions where full Auto Policy Generaiton 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 Generaiton but not both.
Warning: IP Blocking should not be used when Auto Policy Generaiton 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.

AppWall User Guide
Security Tools
To activate Full Auto
1. If you have yet to create your Web Application, refer to Creating a Web Application.
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.
2. 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 Generaiton 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 are displayed via the Active Protection Level tab under the Settings tab, with
the relevant mode you defined; Active/Disabled/Passive/Learn.
3. Under the Settings tab, in the displayed list of Filters, select the Full Auto option button where
relevant.
4. 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 learnt 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.
5. Click Save and then Apply Changes.
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 a specific Security
Filters (AllowList, Parameters, 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.

AppWall User Guide
Security Tools
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 via 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.
For information on how to work with Auto Refinements in the AllowList and Parameters Security
Filters (for the Database Security Filter refinements are displayed only and cannot be managed), see
AllowList Auto Policy Generation Refinements, page 222 and Parameters Auto Policy Generation
Refinements, page 223.
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.

AppWall User Guide
Security Tools
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 the AllowList Security Filter under the Filters node. A list
of URIs currently permitted is displayed 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 Save and Apply Changes). 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 Save and Apply Changes).
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.
Figure 52: Parameters Auto Policy Generation Refinements
Creating Application Paths Automatically

When creating your Web Application via the Web Application wizard (see also Creating a Web
Application, page 186), you can select to automatically create Application Paths for the Web
Application. This is especially useful if you are not familiar with your Web Application’s structure.

AppWall User Guide
Security Tools
Upon completion of the wizard, the Application Paths recognized by AppWall and defined in the
wizard are automatically displayed and the relevant Filters assigned and activated, as determined by
the Auto Policy Generation feature. Additional Application Paths may be revealed when traffic hits
those specific Application Paths. Similarly, Security Filters are automatically assigned and activated
for those Application Paths.
If you selected to manually add Application Paths in the Web Application wizard, you can select the
Create Application Paths Automatically checkbox (displayed in the Automation Level tab) at any time
to ensure that from that moment on, Application Paths will be created.
In addition, you can also determine whether or not Application Paths are created automatically from
the Web Applications screen, 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 220).
2. Select the Create Application Paths Automatically checkbox, click Save and then click
Apply Changes, or
3. In the Security Policies View, select the Web Applications main folder. In the right pane a list
of your Web Applications is displayed.
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 are
displayed.

AppWall User Guide
Security Tools
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.
• Initial Deployment in a Testing Environment

AppWall User Guide
Security Tools
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, and with all the
relevant filters in “Learn” mode. 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,
Working in Learn Mode
Note: This section assumes that you are manually configuring your Security Policy and not
working with the Auto Policy Generation feature.
Learn mode enables an enterprise to work in a test environment and to analyze the network traffic
that would normally trigger the Security Filter in a Production environment. This allows the
enterprise to later configure the Security Policy based on this information.

AppWall User Guide
Security Tools
Traffic requests not defined in the Security Filter specifications are automatically appended to a list
of refinements. They can be viewed on the Refinements page in the Security Policies View.
Appended requests are indicated by the Learn Mode icon in the Tips column.
Figure 53: Learn Mode
Learn mode is currently available for the following Security Filters:

• AllowList
• Parameters
• Database
• HTTPMethods
• Session
Note: If a test environment is not available, the enterprise should work in Passive mode before
deploying AppWall to a production environment.
Accepting Learn Mode Entries

If you accept a Learn Mode specification, it will attain the status of Accepted. Learn Mode entries
should be reviewed prior to acceptance, because even invalid or manipulated requests are re-
registered in Learn Mode.
Because a Learn Mode entry comes from a specific Application Path, it is automatically attached to
the correct AppWall Server, Web Application, Tunnel, and Host.
If your Web Application contains pages that are called from locations not falling under the scope of
the Application Path, Host, Tunnel, or Web Application, a configuration for these requests must be
considered. Often this can be the default Web Application. If you do not support the Default Web
Application, you must define additional security objects.
Learn Mode entries are saved to file to be used at a later point in time. After accepting the desired
entries, they are saved automatically. Click Apply Changes. All Learn Mode entries are saved to a
“.lrn” file to be available for future use. Individual learned entries cannot be deleted. All Learn Mode
entries can be deleted at once.
To delete all Learn Mode entries, select the Security Filter, Application Path, Host, Tunnel, or Web
Application, and select Clear Learned Entries from the right-click menu, which will clear all Learn
Mode entries for that level and all levels under it.
Note: If a Learn Mode entry was edited before accepting and saving it to a file, the original
Learn entry will still appear in the refinements. Only Learn Mode entries that were
accepted as-is will not be displayed in the refinements as "Learn".

AppWall User Guide
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 (Web Server down, etc.).
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 suspended 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 218 for further information.
Notes
>> You can also discover the structure of your Web Application automatically when adding
the Web Application itself in the Security Policies view. See Creating Application Paths
Automatically, page 223 for further information.
>> The Auto Discovery module creates a single XML document, where all of the discovered
information is held. The XML document is located in Program Files\Radware\AppWall
Gateway\AD.
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 (or use the Default Web Application)
and Application Pat<XREF>h that represent the structure of your Web Application.
4. 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.
5. On the main toolbar click Apply Changes. 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.
6. In the Auto Discovery View, double click the Server node. The structure of the Application
displays.

AppWall User Guide
Security Tools
Note: The numbers in brackets represent the number of children (files, folders, parameters,
etc.) under the specific parent.
Selecting a folder, file or page from the Auto Discovery tree displays the full path to the selected
object below the Management Application toolbar as displayed in the following image:
The table below provides an explanation of the icons displayed in the image above:
Table 45: Explanation of Symbols in the Auto Discovery View
Icon Description
Represents URIs routed to the Default Web Application
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
and no Default Web Application defined for that tunnel.
{P} Path Parameter
{C} Cookie
{Q} Query Parameter
Auto Discovery Refinements

At the Application Path level, the list of Security Filters is displayed. Configuration of these Security
Filters is possible according to the requirements of the Web Application.
When the icons representing Routed to Default Web Application ( ) or Routed to Application Path
( ) are displayed 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.

AppWall User Guide
Security Tools
The Refinements tab of the Security Filters is configurable only when selecting the folder from the
Auto Discovery tree that represents the Application Path.
Auto Configuration 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 is displayed (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 descendents of a URI (descendents are indicated by
the number in parenthesis next to a URI in the Auto Discovery tree) select the Descendent 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 the Default Web Application or 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:
Figure 54: Application view in 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 or select Create New and click Next.
4. Enter a name for the new Web Application and click Next.
5. Define the security page and click Next.
6. Click Edit to edit the security properties of the Application Path, and click OK.
7. Click Next, and click Finish. In the Security Policies view, under the new Web Application, the
defined Application Path is now visible.

AppWall User Guide
Security Tools
Web Crawler
AppWall's internal web crawler enables an active process of mapping the protected web application
resources and structure to generate a security sitemap. The security sitemap is based on the format
defined by http://sitemaps.org/protocol.php with several additions.
Web crawlers access web applications to collect data from the application. The process initiated
when the crawler send an initial request to a landing page in the application (initial starting page).
By processing the response and analyzing the embedded links in the replied application’s resources,
the crawler would then send its consequent requests. This way the crawler can access all the linked
resources and pages in the application.
In AppWall, the internal web crawler enables mapping the folder structure, the resources and their
security attributes, by crawling through the application and generating a security sitemap file which
contains all the relevant information. The generated sitemap file is based on sitemaps.org xml
format.
To configure a web crawler process you need to define a Crawler Job. In the crawler job you would
define which web server which represents the web server IP address and port (defined in the
Protected entities section in the Configuration view) the crawler should be accessing, what is the
initial landing page for the crawler to start its process (e.g. http://www.google.com) and for how
long to keep the application crawling information in internal cache.
Once the crawler Job is completed, a site map file will be generated for the crawled application.
To access Crawler Jobs
1. Go to Security tab, then AppWall Servers > [My Server] > Gateway and select Auto Policy
Generation > Crawler Jobs.
2. Click the Add button.
3. Enter the default Crawler Job Name.
4. Select a host from a drop-down list of pre-configured hosts.
Hosts used by the crawler job are defined in Configuration view > Hosts > Hosts to Web Server
bindings.
5. Enter the start page URL.
6. Add URL limits. This defines the URL or host limits of the crawling.
If you want to crawl in a specific section of the application (e.g. in the /newapp/ sub tree of the
application), you can define www.myapp.com/newapp/ as limit URL.
7. Enter the capture interval in minutes.
8. Click OK. You are returned to the Crawler Jobs list.
In the Crawler Jobs list, you can add, edit or remove jobs in addition to starting and stopping
captures.
Using Crawler for Security Policies

Many web applications store sitemap.xml files to process search engines bots. Both AppWall
generated sitemap.xml and externally uploaded sitemap files can be processed by AppWall for the
purpose of automatic security policy generation.
Prerequisites
• Auto Discovery needs to be activated for the sitemap processing to succeed.
• A Web Application with auto policy set to on must be configured prior to sitemap processing.
• A compatible Host must be configured under the Hosts section in Configuration View.

AppWall User Guide
Security Tools
Having successfully processed a sitemap, a security policy will be generated automatically for all
tunnels which redirect traffic to the selected Web Service Interface in the crawling job.
Site Map List

In order to automatically generate policy for the crawled application, you should select the newly
generated sitemap.xml file and click the “process” bottom. Processing status is presented. For large
sitemap files (over 10 MB) processing might be a matter of many minutes.
Note: For the Sitemap Processing to be completed successfully server prerequisite conditions
are required:
• Auto Discovery must be activated

• A Web Application with the relevant tunnels, set to Auto Mode must be defined
An automatically Generated policy will be generated for all tunnels which redirect traffic to the Web
Server defined in the compatible Crawler Job.
Sitemap 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 (e.g. http://www.google.com/sitemap.xml). You can import
such external sitemap file for AppWall to process it for policy generation.
As the internally generated sitemap files are tailored for AppWall purposes, the quality of the policy
generated by AppWall generated sitemaps is expected to be higher.
Note: In the case of processing of externally imported sitemap file, for the Sitemap Processing
to be completed successfully, a crawler job with the URL which contains the hostname as
it is defined in the sitemap file must be defined. This mapping of hostname to Web
Server, enables mapping to AppWall tunnels prior to the process of policy generation.
Auto Policy Generation Properties

Use auto policy generation properties for profile and policy creation as shown here.
To access Auto Policy Generation
1. Go to Security tab, then AppWall Servers > [My Server] > Gateway and select Auto Policy
Generation. The Auto Policy Generation window appears.
2. Mark check boxes to
— Enable Auto Policy Generation
— Suppress Events When Auto Policy Generation Learns
3. Click to Reset Data as appropriate.
4. Select a profile as shown below.

AppWall User Guide
Security Tools
5. There is 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

An Auto Policy Generation progress bar shows the progress in
1. Dynamic profile generation: the first 50% of the progress bar. Relevant only for the Prod -
Automatic
2. Auto Policy Generation: the second 50% of the progress bar. Relevant for all the other profiles.

AppWall User Guide
Security Tools

AppWall User Guide
Best Practices
Chapter 5 – Best Practices

This chapter describes the Best Practices required to maximise your AppWall experience, and
• Working in a Staging Environment (from Test to Production), page 235, describes how to move
from a Test environment to a Production environment.
• Policy Changes and Their Effect on Performance, page 236, describes the effect any changes
made to a Security Policy will have on system performance.
• Working with Events, page 236, describes how to work with and analyze the events created
within AppWall.
• Working with the Dashboard, page 247 describes how to view and analyze real-time network
activity.
Working in a Staging Environment (from Test to

Production)
The most effective way of deploying AppWall is to work in a staging environment, which means
initially working in a Test environment before moving over to a Production environment.
The key benefit of working in a staging environment is that, apart from getting familiar with
AppWall, you can thoroughly test your Security Policy and therefore reduce potential errors and
‘false positives’ (where legitimate requests are blocked) before moving to a potentially hazardous
Production environment.
Note: If you have to initially deploy AppWall in a Production environment, Radware

recommends that you enable Filters in Passive Mode with Auto Policy Generation
enabled where relevant before moving to Active Mode.
Working in Learn Mode in a Test Environment

After you have defined your Security Policy and have deployed it within a Test environment, you
should use the Learn Mode of the Security Filters to ‘learn’ the application and its anticipated
traffic. Learn Mode assumes every request received by AppWall is valid and adds each request as a
refinement. This enables you to monitor each and every event generated by AppWall to verify its
validity.
Over a period of time, once the events generated appear to be only valid events, it is recommended
to move to Active Mode, but still within the Test environment.
For further information about working in Learn Mode and setting Filter modes, see the appropriate
sections.
Note: The Learn Mode should never be used when working in a Production environment, as in
this mode the Web Application is not protected.

AppWall User Guide
Best Practices
Working with Auto Policy Generation in Test and Production Environments

Auto Policy Generation can be used in both Test and Production environments. Note that Auto Policy
Generation can take time to learn a Web Application and its traffic, even up to a number of days for
especially large sites. For further information about deploying Auto Policy Generation in Test and
Production environments, see the appropriate section.
Moving From a Test to a Production Environment

Radware highly recommends working in a Test environment, initially in Learn Mode before moving to
Active Mode. Only then, after carefully reviewing the learned refinements and AppWall appears to
have learnt the Web Application and its traffic, should you move into a Production environment.
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 learnt 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 237
• Reviewing the Event Log, page 238
• Viewing Event Details, page 239
• Reading a Log, page 239
• Working with the Security Log, page 242
• Accessing the Security Log in the Forensics View, page 242
• Quick-Click Refinements From the Security Log, page 242
• Displaying Graphical Reports of Applications and Security Filters, page 243
• Viewing Security Events by Applications, page 244
• Viewing Security Events by Filters, page 245
• Viewing Security Events per Application, page 245
• APSolute Vision Reporter, page 246

AppWall User Guide
Best Practices
Viewing Events in the Forensics View

The Forensics view of AppWall Management Application allows you to examine and analyze AppWall
Server 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 learnt
your Web Application.
The Forensics view consists of a Forensics tree in the left pane that lists a set of AppWall Server logs
and an Event Viewer in the right pane that contains event records for each log.
Figure 55: 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 238.

AppWall User Guide
Best Practices
Table 46: 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 Server 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 the AppWall Server 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 possible security breaches for all Web
Applications being monitored.
Events by Application Displays a graphical pie chart depicting event types by Web Application.
Report
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: 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, open Server Group > AppWall Server and select the type of log node
you want to view: Administration, System, Initialization, Escalation, or Security. 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.

AppWall User Guide
Best Practices
Viewing Event Details
To display details about an event in the Event Viewer
1. Select the Event in the Event Viewer.

2. Click the Event Details arrow at the bottom of the page. The Event details are displayed in the
Event Details window below the Events display.
3. Select other events from the Event Viewers to view their event details.
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 47: Log Examples
Column Description
Severity Level The severity level of the event: Lowest, Low, Medium, High, or Critical.
Is 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.

AppWall User Guide
Best Practices
Table 47: Log Examples
Column Description
Title A short description of the event.
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.
Administration and Security Logs only.
User Name Name of the particular user.
Administration Log only.
Time Limit Maximum time allotted for the escalated security policy. Available on
Escalation Log only.
Is Manual The method of invoking the escalated security policy.
Values: Manual, Automatic.
Escalation Log only.
Action Action taken on the escalated security policy. Possible values are:
Escalation, De-Escalation.
Available in Escalation Log only.
New State The state of the tunnel after the escalated security policy is applied.
Possible values are: Bypass, Passive, Active.
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.

AppWall User Guide
Best Practices

AppWall User Guide
Best Practices
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.
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 > 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 239. 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.
Accessing the Security Log in the Forensics View
To access a Security Log in the Forensics view
1. In the Forensics view, open AppWall Server > 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 Server Group > AppWall Server > 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 243.
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.

AppWall User Guide
Best Practices
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 Server Group > AppWall Server > 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 Forensics View, you can refer to graphical reports when analyzing various aspects of your Web
Application security policy.
From the Forensics view, you can access three types of security reports. Each report is a graphical
pie chart that shows the distribution of security events.

AppWall User Guide
Best Practices
Table 48: 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
To view security events for all Web Applications combined
1. In the Forensics view, open Server Group > AppWall Server and select the Reports node.
2. Select Events by Applications. The Events by Applications pie chart is displayed.

AppWall User Guide
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
2. Select Events by Filters. The Events by Filters pie chart appears.
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
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 is displayed.

AppWall User Guide
Best Practices

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

Masking values of sensitive parameters (e.g. passwords, credit card and social security details)
In order to activate this functionality for an additional parameter, click Configuration > Events >
Security Event Logs > Security Log and select the Sensitive Parameters tab.
By default the AppWall would hide parameter names ‘password’, 'passwd', 'ccn', 'ssn',and ‘pin’.
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 patter 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 (e.g. 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.
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.

AppWall User Guide
Best Practices
Events can be filtered by clicking the Filter button in the Forensics event 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 Server
workplace. It allows you to:
• Watch current network activity to and from the Web Server.
• Monitor all AppWall Servers on the network from one place.
• View network activity pictorially, as a graph.
Selecting an AppWall Server in the Dashboard view provides the network statistics for that Server in
the Dashboard tree. You can display statistics about all Servers configured in your AppWall
Management Application by selecting the Server Group node from the Dashboard tree. Note that
when working with a Cluster configuration, the Summary tab is not available for the Cluster
Manager, but is displayed for the AppWall Server nodes.
You can also define the network statistics refresh rate, which by default is set at 5 seconds. To
change the refresh rate, right-click the Console, Server Group or Server and select Change Refresh
Rate, and then enter the relevant refresh rate value.
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 the AppWall
Server. It provides the Properties, Administrative Events, Server Activity, and Security Violations
related to the AppWall Server.
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 of the
AppWall Server.
• AppWall Server Activity — This tab provides the Status Details, Current Activity, and
Resource Usage of the AppWall Server.
• Tunnels — This tab provides the user with Tunnels information and Current Activity of the
Tunnels.
• Security Events – This tab displays the AppWall Server’s security-related events as they occur.
Summary Tab
From the Dashboard view, you can view connection details, general information, security events and
violations for the AppWall Servers as described below.

AppWall User Guide
Best Practices
Figure 56: Dashboard Summary Tab
The Summary tab is divided into the following sections:

• Properties — Provides information such as the name and IP address of the AppWall Server, as
well as the number of Tunnels defined for the AppWall Server.
• Administrative Events — Provides information such as the time frame for administrative
system events, and the number of logged Security Violation, Escalation, System and Console
events.
• AppWall Server Activity — Provides information such as the current server activity, including
the number of active connections and the rate of sent HTTP requests.
• 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 Server, including the
IP address and operating system of the machine running the AppWall Server and details of any
associated Tunnels.

AppWall User Guide
Best Practices
Figure 57: Properties Tab
AppWall Server Activity Tab

The AppWall Server Activity tab provides details about the selected AppWall Server, including its
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.

AppWall User Guide
Best Practices
Figure 58: AppWall Server Activity Tab
Tunnels Tab
The Dashboard view Tunnels tab provides details about the Tunnels configured for the selected
AppWall Server.
Figure 59: Tunnels Tab

AppWall User Guide
Best Practices
By default, the Graph displays only information about the AppWall Server’s 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 is displayed.
2. Select or deselect the name of the data-series to graph and click Close. The graph(s) refreshes,
reflecting these changes.

AppWall User Guide
Best Practices

AppWall User Guide
Additional Configuration Options
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), and includes the following:
• AppWall Server Configurations, page 253
• APSolute Vision Reporter, page 256
• Working with AppWall Services, page 256
• Watchdog, page 256
• SNMP Agent, page 257
• IP Blocking, page 258
• Signature Update Service (SUS), page 259
• OPSEC — Integrating AppWall Server with Check Point FireWall-1, page 260
• Events, page 270
AppWall Server Configurations

This describes how to work with existing Server configurations (or policies) and includes the
following:
• Backing Up an AppWall Server Configuration, page 253
• Restoring an AppWall Server Configuration, page 254
• Setting the Maximum Size of AppWall Server Configuration Files, page 254
• Distributing a Server Policy to other AppWall Servers, page 254
Backing Up an AppWall Server Configuration

A backup of each AppWall Server’s configuration settings is automatically performed when the
AppWall Server application starts. These settings include the AppWall Server's configuration
properties and all the Tunnels and Security Filters applied to the AppWall Server. This backup is
located in the Backup directory where the AppWall Server was installed, and named
Last_Used_Config. The default installation places the AppWall Server in the Radware directory.
Because backups can be used to reverse major configuration errors, perform backups before and
after software updates. If you are upgrading the AppWall Server, backup the AppWall Server’s
configuration settings and restore them after performing the upgrade.
To backup an AppWall Server configuration:
1. In the Configuration view, right-click the AppWall Server and select Backup.
2. On the Backup dialog box, enter a name/accept the default and click OK.
Note: The backup copies configuration files into the specified directory.

AppWall User Guide
Caution: If the name already exists, the directory is overwritten without prompting.
Restoring an AppWall Server Configuration

Use AppWall Management Application to restore AppWall Server configurations that were saved
during the previous backup. Restoring an AppWall Server configuration is useful to quickly return to
a reliable state in case the existing configuration is corrupted or deleted unintentionally.
Note: After installing a software upgrade, you must also update all configuration files before
restoring the AppWall Server’s configuration.
To restore an AppWall Server configuration
1. In the Configuration view, right-click the AppWall Server and select Restore. The Restore
Configuration Files dialog box displays existing backups.
2. Select the desired backup directory that you want to restore from the Backup List and click OK.
3. On the Restore Complete dialog box, click OK to return to the Management Application.
4. After Restore is complete, restart the AppWall Server process.
Setting the Maximum Size of AppWall Server Configuration Files

You may specify the maximum size of AppWall Server configuration files by manually editing
Admin.cfg located in the Config directory where the AppWall Server was installed. The default
installation places the AppWall Server in the Radware directory.
To specify the maximum size of AppWall Server configuration files
1. Open the file in a text editor and modify the following entries:
<MaxHeaderSize>2048</MaxHeaderSize>
<MaxBodySize>1000000</MaxBodySize>
Note: Both numeric values represent bytes of data.
Caution: Do not modify the tag name or delimiters.

2. After changes have been performed, restart the AppWall Server process.
Distributing a Server Policy to other AppWall Servers

Use the Policy Distribution wizard to:
• Distribute a Server Policy to other AppWall Servers

AppWall User Guide
• Export a Server Policy to a file

• Import a Server Policy file
This section describes how to use the Policy Distribution wizard to perform these tasks.
To distribute a Server Policy to other AppWall Servers
1. In the Configuration view, right-click the AppWall Server that contains the configuration files you
want and select Policy Distribution.
2. When the Policy Distribution wizard appears, click Next to begin.
3. In the Options dialog box, choose Distribute to one or more AppWall Servers and click
Next.
4. In the Export Format dialog box, select Server or Tunnel distribution and click Next.
5. If you selected Tunnel distribution, select the Tunnel from which to copy policies and click Next.
Otherwise, select the configuration modules to distribute and click Next.
6. In the AppWall Server List dialog box, choose which AppWall Servers to reconfigure: From the
list of Available Servers, move the desired AppWall Servers to the Target Servers field, or click
Add to add a server that is not in the list.
7. In the Distribution Summary dialog box, select Quick Distribution or Advanced Distribution
and click Next.
8. Modify the IP address and Port number as required, click Next and then click Finish.
To export a Server Policy to a File
want to export and select Policy Distribution.
3. In the Options dialog box, choose Export to a File and click Next.
4. In the Export Format dialog box, select Server or Tunnel distribution and click Next.
5. If you selected Tunnel distribution, select the Tunnel from which to copy policies and click Next.
6. Select the name of the directory to contain the configurations and click Finish.
Otherwise, choose which configuration modules to export and the name of the directory to
contain the configurations and click Finish.
To import a Server Policy File
want and select Policy Distribution.
3. In the Options dialog box, choose Import File to Distribute and click Next.
4. In the Import Format dialog box, select Server or Tunnel distribution and click Next.
5. In the Import File dialog box, select a configuration from the list or browse to the appropriate
directory and click Next.
6. In the Distribution Summary dialog box, select Quick Distribution or Advanced Distribution
and click Next.

AppWall User Guide
7. Modify the IP address and Port number as required and click Next and then Finish.

For more information please see APSolute Vision Reporter, page 124.
Working with AppWall Services

AppWall Management Application Services allows you to change configuration settings for the
Services provided with AppWall.
Table 49: Service Descriptions
Service Description
Publisher Lets you configure the AppWall Servers that are accepted by the
Publisher Server, including Allow and Deny lists.
SNMP Agent Lets you configure the SNMP Agent service.
Watchdog Lets you configure the Watchdog service. See Watchdog, page 256 for
further information.
IP Blocking Lets you configure the IP address allow/block service. See IP Blocking,
page 258 for further information.
Note: This feature is disabled for this version.
OPSEC ELA Lets you configure AppWall Management Application to register events
in a CheckPoint FireWall-1 log. See OPSEC — Integrating AppWall
Server with Check Point FireWall-1, page 260 for further information
Watchdog
The Watchdog is installed as a service that resides on each machine running an AppWall Server. It
maintains proper server operation, restarts the AppWall Server when necessary, and prevents
extended downtime.
Configuring AppWall Watchdog
To configure Watchdog
1. In the Configuration view, expand Services and select the Watchdog node.
2. Complete the fields in the right pane as described in the table below.

AppWall User Guide
Log Watchdog When selected, the Watchdog’s activities are recorded in the event log.
Activities
Log File Size Limit Maximum permitted size of the Watchdog log file (under the Events
directory).
CPU Usage (%) When selected and specified, maximum percentage of CPU that AppWall
Server is permitted to use without interruption during the time-period
specified in the Restart the Server After field.
MEM Usage (%) When selected and specified, maximum percentage of memory that
AppWall Server is permitted to use without interruption during the time-
period specified in the Restart the Server After field.
Restart the Server During the time period specified in this field, Watchdog will restart AppWall
(sec) Servers at pre-configured levels if either the CPU usage or MEM usage
remains without interruption.
Enable Safe Mode Select to start in safe mode if the AppWall Server fails to initialize due to
configuration problems. Under safe mode, the AppWall Server runs with
the bare-minimum components such as the Event Log and Event
subsystem. You can perform diagnostic and troubleshooting while running
in safe mode.
3. Click Save.
SNMP Agent
An SNMP agent runs on AppWall devices (physical appliances only), enabling remote monitoring of
the device resource utilization, including CPU memory and traffic volume information. The
compatible MIB file which should be used for SNMP agent monitoring is delivered along with the
AppWall device, and can be downloaded from the radware.com Web site.
Configuring AppWall SNMP Agent
To configure Watchdog
1. In the Configuration view, expand Services and select the SNMP Agent node.
Support SNMPv1/ Clear to disable support for SNMPv1 and SNMPv2c.
SNMPv2c
Community SNMP community field for SNMP version 2c.
Support SNMPv3 Clear to disable support for SNMPv3.
Security Name Sets the security name used for authenticated SNMPv3 messages.

AppWall User Guide
Security Level Sets the security level. Used for SNMPv3 messages
(noAuthNoPriv|authNoPriv|authPriv).
You must provide the appropriate passphrases when using any level higher
than noAuthNoPriv.
Authentication Sets the authentication protocol (MD5 or SHA) used for authenticated
Protocol SNMPv3 messages.
Authentication Pass Sets the authentication passphrase used for authenticated SNMPv3
Phrase messages.
Privacy Protocol Sets the privacy protocol (DES or AES) used for encrypted SNMPv3
messages. Currently,
AppWall supports DES only.
Privacy Pass Phrase Sets the privacy passphrase used for encrypted SNMPv3 messages.
Context Engine ID Sets the authoritative (security) engine ID used for SNMPv3 REQUEST
messages. It is typically not necessary to specify this as it is discovered
automatically.
Context Name Sets the context name used for SNMPv3 messages. The default context
name is the empty
string "".
3. Click Save.
IP Blocking
The AppWall Server 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.
Configuring IP Blocking
To configure IP blocking
1. In the Configuration view, expand Server Group > AppWall Server > Services and select the
IP Blocking node.

AppWall User Guide
Enable Click to enable or disable IP blocking.
Security Score / IP blocking gives suspect IP addresses a 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.
Enable Integration Select this if you want to integrate the IP blocking feature with Check Point’s
With CheckPoint FireWall-1 application.
FireWall-1 For more information on integrating with CheckPoint FireWall-1, see OPSEC —
Integrating AppWall Server with Check Point FireWall-1, page 260.
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.
Always Block These Use Add, Edit, and Remove to edit the list of IP addresses that should always
IPs be blocked. Each IP address can also have a description of why it has been
blocked.
Never Block These Use Add, Edit, and Remove to edit the list of IP addresses that should never
IPs be blocked. Each IP address can also have a description of why it is always
allowed.
Managing Blocked IP Addresses

The AppWall Server 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 Service Group > AppWall Server > Services and select
the IP Blocking node.
2. Click the Blocked IPs tab. This tab contains a list of all IPs that have been blocked.
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-attack signature update service through http://www.radware.com.

AppWall User Guide
Every registered device which is under an active support agreement is entitled to the attack
signature update service. You can schedule checks for new updates, or check manually on demand.
Every update includes a short description providing information on the updates that are available
with the new version. All signature files versions that are supported for the current device version
are displayed, enabling rollback to previous versions.
Auto Update service options include: Check Only and Check and Install.
OPSEC — Integrating AppWall Server with Check Point

FireWall-1
You can integrate an AppWall Server with Check Point FireWall-1, enabling the two security
components to coordinate security measures. The OPSEC ELA service allows an AppWall Server to
publish its events to a Check Point FireWall-1 log.
When integrating the Management Application with a firewall, you perform the following tasks:
• Configuring General FireWall Properties on the AppWall Server, page 260
• Editing the OPSEC Configuration File, page 261
• Registering AppWall Server in FireWall and Vice Versa, page 263
• Establishing an Authentication Key, page 263
• Generating an Authentication Key, page 263
• Verifying the Key Exchange Process, page 264
Configuring General FireWall Properties on the AppWall Server

When configuring the Check Point FireWall-1 properties on the AppWall Server, you specify the
FireWall’s IP address, listening, and version as described in the following procedure.
To configure FireWall-1 properties
1. In Configuration view, open Server Group > AppWall Server > Services and select the
OPSEC node. The Check Point FireWall-1 properties window is displayed.
2. Complete the FireWall settings as described in the table below.
FireWall-1® Address IP address of the Check Point FireWall that the AppWall Server will connect
to.
FireWall-1® Version Version of the FireWall: either 4.1 or NG.

AppWall User Guide
If 4.1 Version Choose connection type of your choice: auth_opsec, ssl_opsec, or clear
– no auth
If NG Version Choose connection type of your choice: clear – no auth, sslca,
asym_sslca, sslca_comp; sslca_rc4, sslca_rc4_comp,
asym_sslca_comp, asum_sslca_rc4.
Editing the OPSEC Configuration File

You must edit the fire FireWall’s OPSEC configuration file to specify the type of connection mode you
are using between the AppWall Server and the FireWall. Provide the settings for both the ELA proxy
server and the SAM server.
Settings differ depending on the FireWall version you have, 4.1 or NG, and what type of connection
mode you are using. Refer to the table below for configuration settings.
Note: If this is an sslca-based connection, you must edit the file. If you have an sslca
connection, the configuration file does not need to be edited.
To configure the ELA proxy server and SAM server in the OPSEC application
1. Open the conf/fwopsec.conf file on your FireWall.

2. Use the table below to add the entries to the configuration file.
3. Restart the FireWall service.
4. Establish the authentication key if using auth_opsec or ssl_opsec connection modes.
Table 50: ELA Proxy Server SAM Server
Connection Mode Version 4.1 Configuration NG Configuration

auth_opsec ela_proxy auth_port 18187 Not Applicable
(Recommended) ela_proxy auth_type auth_opsec
ssl_opsec ela_server auth_port 18187 Not applicable.
ela_server auth_type ssl_opsec
Clear, no auth mode ela_proxy port 18187 ela_server auth_port 0
(Not recommended) ela_server port 18187
SSLA connection Not applicable. No changes to configuration file
needed.
An SSLCA-based Not applicable. ela_server auth_port 18187
connection, other ela_server port 0 ela_server
than SSLCA auth_type [selected connection
type]
SAM Server

AppWall User Guide
Table 50: ELA Proxy Server SAM Server
Connection Mode Version 4.1 Configuration NG Configuration

auth_opsec sam_server auth_port 18183 Not applicable.
(Recommended) sam_server auth_type auth_opsec
sam_allow_remote_requests yes
ssl_opsec sam_server auth_port Not applicable.
18183
sam_server auth_type ssl_opsec
Clear, no auth mode sam_server port 18183 sam_server auth_port 0
(Not recommended) sam_allow_remote_requests yes sam_server port 18183
ela_server auth_port 0
ela_server port 18187
SSLA connection Not applicable. No changes to configuration file
needed.
An SSLCA-based Not applicable. sam_server auth_port
connection, other 18183
than SSLCA
sam_server port 0
sam_server auth_type
[selected connection type]
ela_server port 0 ela_server
auth_type [selected connection
type]
The text of the fwopsec.conf file for auth_opsec mode is shown below:
sam_server auth_port 18183
sam_server auth_port auth_opsec
ela_server auth_port ssl_opsec
ela_proxy fwd_machine localhost
#authenticated connections for servers

#server<server IP><service port>auth_opsec
server127.0.0.118182auth_opsec
server127.0.0.118181auth_opsec
Notes
>> The ELA proxy server must operate in the same mode as the SAM server.
>> If an authenticated communication mode is in use, you must also establish and generate
the authentication key as described in Establishing an Authentication Key, page 263 and
Establishing an Authentication Key, page 263.
For more information on configuring the FireWall, refer to your FireWall OPSEC documentation.

AppWall User Guide
Registering AppWall Server in FireWall and Vice Versa

Follow this procedure if you have the NG version of the FireWall to register the AppWall Server on
the FireWall and then to register the FireWall on the AppWall Server. When registering the AppWall
Server on the FireWall, you define the AppWall Server as a new OPSEC application.
To register AppWall Server in FireWall
1. In the FireWall Policy Editor, click the OPSEC Applications tab, Communication node.
2. In the Communication dialog box, specify a password to create a Secure Internal
Communication key.
3. Click Initialize. The dialog box displays the message, “Initialized but trust not established.”
4. In the FireWall Policy Editor, click the OPSEC Applications tab, OPSEC Application tree, and
double-click the AppWall Server node and copy its Domain Name (DN) name. This is the Client
DN.
5. Click the Network Objects tab, Network Objects tree, double-click the Firewall node and
copy its Domain Name (DN) name. This is the Server DN.
6. Return to the Management Application, open Server Group > AppWall Server > Services
and select the OPSEC node.
7. In the Check Point FireWall properties window, Client DN field, enter the Client DN from Step 4
and in the Server DN field, enter the Server DN from Step 5.
Establishing an Authentication Key

Follow this procedure only for version 4.1 of the FireWall and if the connection mode between the
AppWall Server and FireWall is either auth_opsec or ssl_opsec.
Note: If you have the FireWall NG version, this step is not required.
To establish an authentication key
1. Open the command shell (cmd.exe) on your FireWall.

2. Depending on the connection mode, enter the following command:
— auth_opsec—fw putkey -opsec -p PASSWORD IP
— ssl_opsec—fw putkey -opsec -ssl -p PASSWORD IP
where:
• — PASSWORD is a temporary password to connect to the FireWall and
• — IP is the IP address of your AppWall Management Application.
Generating an Authentication Key

Follow this procedure for both versions of the FireWall, 4.1 and NG, and if the connection mode
between the AppWall Server and FireWall is either auth_opsec or ssl_opsec.

AppWall User Guide
To generate an authentication key
1. In Configuration view, open the Server Group > AppWall Server > Services node.
2. Select OPSEC node and on the Management Application toolbar click Key.
3. In the OPSEC Authentication Password dialog box Password field, enter the same password
that you used when establishing the authentication key for the FireWall.
4. Click OK. AppWall Server generates the key.
Verifying the Key Exchange Process

Follow this procedure for both versions of the FireWall, 4.1 and NG, and if the connection mode
between the AppWall Server and FireWall is either auth_opsec or ssl_opsec.
To verify the key exchange process
Start your FireWall’s policy editor.
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 Escalation 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.

AppWall User Guide
To change the Event Map
1. In the Security Policies View, expand Service Group > AppWall Server > Security Events
Logs and select the Security Log node.
2. Click the Event Map tab. A list of all defined events is displayed. 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.
5. Click Save.
Table 51: 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
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
1. In the Security Policies View, expand Server Group > AppWall Server > Security Events
2. Click the Severity Rules tab. A list of all defined severity rules is displayed. A description of
each column in the list appears in Table 52 - Severity Rules Tab Fields.

AppWall User Guide
Table 52: 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 is displayed 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 52 - Severity Rules Tab Fields for details.
5. In the Rule Actions tab, select the new severity level according to the options described in
Table 53 - Rule Actions Fields, below.
Table 53: 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 the AppWall Server.
6. When you are finished, click OK.

7. Click Save in the AppWall Security Management Application Content Area

AppWall User Guide
Managing Publishing Rules

The AppWall Server 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,
OPSEC ELA, 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
Logs and select the Security Logs node.
2. Click the Publishing Rules tab. A list of all defined publishing rules is displayed, if any. A
description of each column in the list appears in Table 54 - Managing Publishing Rules, below.
Table 54: Managing Publishing Rules
Field Description
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 is displayed 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 54 -
Managing Publishing Rules for details.
5. In the Rule Actions tab, enter the fields according to Table 55 - Rule Actions Tab Fields, below.

AppWall User Guide
Table 55: 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 the event triggers.
Server
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
Log at Generates a log message to CheckPoint OPSEC.
CheckPoint
FireWall-1
(OPSEC ELA)
Send Using an Sends using an ODBC event.
ODBC
Send an Email Sends an email message to the specified recipient
Message To

7. Click Save in the AppWall Management Application Console content area.
Managing Escalation Rules

You can create escalation rules that escalate the state of a Server or Tunnel. Escalation is deployed
when you want to quickly or automatically turn on filtering for a server or tunnel that was not
previously actively using security filters.
Note: Managing Escalation Rules is only for Security events.
To manage escalation rules
2. Click the Escalation Rules tab. A list of all defined escalation rules is displayed. A description of
each column in the list appears in Table 56 - Managing Escalation Rules.
Table 56: Managing Escalation Rules
Field Description
Description A brief description of the rule.
Minimum Severity Level The minimum severity level required to invoke the escalation rule.

AppWall User Guide
Table 56: Managing Escalation Rules
Field Description
Maximum Severity The maximum severity level at which the escalation rule is invoked.
Level
Number of Occurrences The number of occurrences of a triggering event required to invoke the
escalation rule.
Occurred in (sec.) The maximum time interval between potential triggering events for the
events to be considered an escalation situation for the escalation 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 associated to the escalation rule.
Tunnel The Tunnel associated with the escalation rule.
Host The Host associated with the escalation rule.
Application Path The Application Path associated with the escalation rule.
Escalated Server The Server (or all Servers) for whose traffic the escalation rule is to be
applied.
Escalated Tunnel The Tunnel (or all Tunnels) for whose traffic the escalation rule is to be
applied.
Change State to The state of the server after the escalation rule is applied. Possible values
are: Active, Bypass, Passive.
Change State for (sec.) The amount of time for which the escalation rule is to be applied.
3. Click Add to add a new rule, or double-click a rule to edit the rule. An Add/Edit Escalation Rule
dialog box is displayed.
4. Enter the name and required originating source of the event to trigger this severity rule. Refer to
Table 56 - Managing Escalation Rules for details.
6. Click Save in the AppWall Management Application Content Area.

AppWall User Guide
Managing Log Files

You can change the behavior and location of the event log files.
To manage log files
Logs and select the Security Logs node.
2. Click the File Settings tab.
3. Enter new information into the fields according to Table 57 - Managing Log Files.
Table 57: 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 Archive files are stored indefinitely.
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
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
The AppWall Server 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
The AppWall Server 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.

AppWall User Guide
Changing Severity Setting Names
To change the severity setting names
1. In the Configuration view, expand Server Group > AppWall Server >Events and select the
Severity Settings node.
2. Double-click a severity setting, enter a new name for the setting, and click OK.
3. Click 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.
Resetting to Factory Defaults

If your AppWall appliance should ever experience complete failure, you can perform a recovery
operation to reset to the factory defaults. This operation resets the appliance configuration to zero,
enabling you to start your configuration from the beginning.
To reset factory defaults
1. Before you begin, download the AppWall upgrade and recovery image for your device version
and operating system from the Radware Web site.
2. In the Management Console, select System Configuration > Backup/Restore.
3. In the AppWall Upgrade/Repair section, click Upload.

AppWall User Guide
4. Select the Upload/Repair file that you downloaded from the Radware Web site, and click
Upload.
5. Choose the image file, and click Upgrade Image.
Note: If the image file does not appear in the list after upload completes, switch to another
window and then return to the Restore/Backup window.
6. The following window appears, requesting that you reboot the device.

AppWall User Guide
7. Connect to the machine console and reboot the device.

8. After rebooting, log in through the console window. The following window id displayed:
9. Select Temporary Upgrade boot, and press Enter. The following window is displayed:
10. Choose 2. Repair; then choose a repair option:

a. The entire device content, including the OS configuration, will be erased; the device will be
as a new device from the factory.
b. The AppWall configurations will be erased but the device OS settings will not be affected.
11. During the Reset to Factory Defaults process, the device license is reset. Please contact Radware
support to receive a copy of your device license. Follow the procedure in the Radware
Installation and Maintenance Guide to reinstall the license on the device.
12. After the procedure completes, reboot the device again, and reconfigure according to the
Radware Installation and Maintenance Guide.

AppWall User Guide

AppWall User Guide
Troubleshooting
Appendix A – Troubleshooting
This appendix lists some of the common issues that you may encounter when working with AppWall,
and is divided into the following sections:
• General Issues, page 275
• Filters and Configuration Issues, page 275
General Issues
This section provides solutions to general AppWall issues and includes the following:
• What TCP Ports Does AppWall Use?, page 275
• How Do I Backup the Auto Discovery Tree?, page 275
What TCP Ports Does AppWall Use?
Note: All AppWall ports are configurable.
Table 58: AppWall TCP Ports and Purpose
TCP Port Purpose

8200 AppWall Gateway's listener port for the AppWall Management Application.
8205 AppWall Gateway's Certificate Server Port (for encrypted traffic between the
Console and the Gateway).
8220 AppWall Publisher's port.
8270 AppWall Cluster Manager port.
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 always manually backup the
ADserial.dat file, which is located in the \AppWall Gateway\Config\State folder.
To restore the backup
1. Resume the Auto Discovery.

2. Apply changes.
3. Stop the Gateway.
4. Copy the file and then start the Gateway.
Filters and Configuration Issues

This section answers Filter and Configuration issues.

AppWall User Guide
Troubleshooting
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.
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.
What is Policy Distribution and can I do this Cross Platform (OS)?

One of the major AppWall features is its Policy Distribution mechanism (see the appropriate section).
You can export or import a configuration file or distribute your full policy or just one Application Path
to a different Gateway.
You can also perform these actions regardless of whether your OS is Win or Apache RH.
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 does the AppWall Load Balancing (‘web server farms’) work?
The web server farm is a very basic load balancer which cannot function as a real load balancer. The
algorithm is random but with a connection verification because AppWall analyzes the connection to
the web server. The Session stickiness is the source IP address.
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 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.

AppWall User Guide
Regular Expressions
Appendix B – Regular Expressions

The following table provides a quick reference of RegEx operations you can use to create a regular
expression.
Table 59: RegEx Quick Reference
Regular Expression 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
Example Expressions
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
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.

AppWall User Guide
Regular Expressions
Figure 60:
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).
Example
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.
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.

AppWall User Guide
Regular Expressions
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.
Examples
— “ba*” will match all of “b”, “ba”, “baaa” etc. “ba+” will match “ba”
— “baaaa” for example 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)*”
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.

AppWall User Guide
Regular Expressions
Example
“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 60: 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.
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.

AppWall User Guide
Regular Expressions
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”, “\1” refers to the first sub-
expression, “\2” to the second etc. For example 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.
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.

AppWall User Guide
Regular Expressions
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 61: 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.
\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

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

AppWall User Guide
Code Pages
Appendix C – Code Pages

Often client applications send requests that use special language characters (i.e. 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].”
Note: 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 as
follows: The following table lists the code page options available in AppWall:
Table 62: 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.

AppWall User Guide
Code Pages
Code Description
The following lists the code page options available in AppWall Server.
Table 63: AppWall Server 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)

AppWall User Guide
Code Pages
Table 63: AppWall Server Code Page Options
Code Description
cp1254: Microsoft Windows Codepage 1254 (Turk)
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 LatinCyrillic Alphabet
cp8859_6: ISOIEC 8859_6: 1999 LatinArabic Alphabet
cp8859_7: ISOIEC 8859_7: 1987 LatinGreek Alphabet
cp8859_8: ISOIEC 8859_8: 1999 LatinHebrew 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)

AppWall User Guide
Code Pages

AppWall User Guide
HTTP Status Codes
Appendix D – HTTP Status Codes

The following table provides a list of HTTP response codes that appear in the HTTP structure.
Table 64: 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

AppWall User Guide
HTTP Status Codes

AppWall User Guide
Extracting Original Source IP Address from an HTTP Header
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 (e.g., 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-basd
policies.
In order to activate this front-end functionality, in the Configuration > 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.

AppWall User Guide
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,

AppWall User Guide
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 assign, 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. 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, decompile,
reverse engineer or otherwise attempt to derive source code (or the underlying ideas,
algorithms, structure or organization) from the Software; or (c) remove any copyright notices,
identification or any other proprietary notices from the Software (including any notices of Third
Party Software (as defined below); or (d) 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 Section
3(d), 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 of 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.
4. 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.
5. 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

AppWall User Guide
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.
6. 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.
7. 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 3 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 3 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.
8. 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 3-11
shall survive any termination of this License Agreement. The License under this License
Agreement is not transferable and will terminate upon transfer of the Software.
9. Export. The Software or any part thereof may be subject to export or import controls under the
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.
10. Governing Law. This License Agreement shall be construed and governed in accordance with
the laws of the State of Israel.

AppWall User Guide
11. 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 IMMIDIATELY CEASE USING THE
SOFTWARE.
COPYRIGHT © 2012, Radware Ltd. All Rights Reserved.

AppWall Manual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

AppWall Manual

Hochgeladen von

Copyright:

Verfügbare Formate

AppWall User Guide

Software Version 5.6.1

2 Document ID: RDWR-APW-V561-UG1211

Document ID: RDWR-APW-V561-UG1211 3

4 Document ID: RDWR-APW-V561-UG1211

Document ID: RDWR-APW-V561-UG1211 5

OpenLDAP is a registered trademark of the OpenLDAP Foundation. Copyright 1999-2003 The

Notice traitant du copyright

6 Document ID: RDWR-APW-V561-UG1211

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

Document ID: RDWR-APW-V561-UG1211 7

STRICTE OU D’UN ACTE DOMMAGEABLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE), DÉCOULANT DE

8 Document ID: RDWR-APW-V561-UG1211

Figure 1: Electrical Shock Hazard Label

DUAL-POWER-SUPPLY-SYSTEM SAFETY WARNING IN CHINESE

Document ID: RDWR-APW-V561-UG1211 9

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

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

10 Document ID: RDWR-APW-V561-UG1211

VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS

Figure 3: Statement for Class A VCCI-certified Equipment

Translation of Statement for Class A VCCI-certified Equipment:

Figure 4: Statement for Class B VCCI-certified Equipment

Translation of Statement for Class B VCCI-certified Equipment:

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

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

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

Document ID: RDWR-APW-V561-UG1211 11

SPECIAL NOTICE FOR NORTH AMERICAN USERS

This marking or statement includes the following text warning:

12 Document ID: RDWR-APW-V561-UG1211

AC units for Denmark, Finland, Norway, Sweden (marked on product):

To connect the power connection:

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

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

Document ID: RDWR-APW-V561-UG1211 13

14 Document ID: RDWR-APW-V561-UG1211

DÉCLARATIONS SUR LES INTERFÉRENCES ÉLECTROMAGNÉTIQUES VCCI

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

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

Figure 10: Déclaration pour l’équipement de classe B certifié VCCI

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

Document ID: RDWR-APW-V561-UG1211 15

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

Cette marque ou remarque inclut l’avertissement textuel suivant:

16 Document ID: RDWR-APW-V561-UG1211

Pour brancher à l’alimentation électrique:

Document ID: RDWR-APW-V561-UG1211 17

Figure 13: Warnetikett Stromschlaggefahr

SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

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

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

18 Document ID: RDWR-APW-V561-UG1211

Figure 15: Erklärung zu VCCI-zertifizierten Geräten der Klasse A

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

Figure 16: Erklärung zu VCCI-zertifizierten Geräten der Klasse B

Übersetzung von Erklärung zu VCCI-zertifizierten Geräten der Klasse B:

Figure 17: KCC—Korea Communications Commission Zertifikat für Rundfunk-und

Document ID: RDWR-APW-V561-UG1211 19

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

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

20 Document ID: RDWR-APW-V561-UG1211

Anschluss des Stromkabels:

Altitude and Climate Warning