Day One Deploying Junos WebApp Secure

Transcription

Juniper Security Technologies
DAY ONE:
DEPLOYING JUNOS WEBAPP SECURE
®
It’s a dangerous world out there
and you must protect your assets
from exploitation and theft. Junos
WebApp Secure gives you the tools
to make your website secure.
Learn how, right here.
By Glen Kemp
DAY ONE: DEPLOYING JUNOS® WEBAPP SECURE
There are some very clever people out there trying to pick the virtual pockets of you
and your network. And the reality is that system administrators have an extremely
tough job detecting and combatting such attacks, even with expensive security tools
in place. In most attacks, the intruders are long gone before anyone has checked the
alarm console. And the attackers know that.
Fortunately there are also very clever people coming up with strategies and technologies to combat these attacks, and this book shows you how to deploy one of the most
ingenious tools at your disposal: Junos WebApp Secure.
Junos WebApp Secure protects your assets from exploitation and Day One: Deploying
Junos WebApp Secure shows you how to deploy the program and make it operational.
IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
Understand the problems solved by Junos WebApp Secure.
Understand the relationship between the Firewall, Junos WebApp Secure, the Load
Balancer, and the Web Application Server it is protecting.
Design a Junos WebApp Secure deployment in the context of your environment.
Deploy Junos WebApp Secure on VMware ESX.
Configure a back-end server.
Configure the login processor to protect key applications.
Test Junos WebApp Secure.
Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the
complete library at www.juniper.net/books.
Published by Juniper Networks Books
ISBN 978-1936779772
9 781936 779772
51800
07100170
Day One:
Deploying Junos WebApp Secure
By Glen Kemp
Chapter 1: The Threat Landscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2: Web Security Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3: Installing Web Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 4: Network and Application Integration. . . . . . . . . . . . . . . . . . . . . . 63
iv
© 2013 by Juniper Networks, Inc. All rights reserved.
Juniper Networks, the Juniper Networks logo, Junos,
and Junos WebApp Secure are registered trademarks of
Juniper Networks, Inc. in the United States and other
countries. Junose is a trademark of Juniper Networks,
Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property
of their respective owners.
About the Author
Glen Kemp is an Enterprise Security Architect and
Juniper Ambassador working for SecureData in the UK.
He has accumulated numerous Juniper JNCIS and
JNCIA qualifications while working in Network security
for the past 15 years. Glen is also a prolific blogger and
writer and works with many leading and bleeding-edge
technologies.
Juniper Networks assumes no responsibility for any
inaccuracies in this document. Juniper Networks reserves
the right to change, modify, transfer, or otherwise revise
this publication without notice. Products made or sold by
Juniper Networks or components thereof might be
covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent
Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051,
6,333,650, 6,359,479, 6,406,312, 6,429,706,
6,459,579, 6,493,347, 6,538,518, 6,538,899,
6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Author’s Acknowledgments
Glen’s Acknowledgements: I must thank my wife Jo and
son Samuel for their love and support. A massive thank
you must go to Zoe Sands for all her encouragement and
wisdom, without which this project could not have
happened. Thanks must also go to Jo James for putting
me in the right place at the right time and her patience
and encouragement. Many others have contributed with
knowledge and advice during this project: Geoff Bradley,
Keir Asher, Peter Nguyen, Patrick Ames, Julie Wider, the
Packet Pushers illuminati (Greg and Ethan), Rivka Little,
Chuck Moozakis, Kelly McDowell, and Paul Risk; all of
whom deserve massive thanks.
Published by Juniper Networks Books
Authors: Glen Kemp
Technical Reviewers: Keir Asher, Michael Parkin, Peter
M. Nguyen
Editor in Chief: Patrick Ames
Copyeditor and Proofer: Nancy Koerbel
J-Net Community Manager: Julie Wider
ISBN: 978-1-936779-77-2 (print)
Printed in the USA by Vervante Corporation.
ISBN: 978-1-936779-78-9 (ebook)
Version History: v1, August 2013
2 3 4 5 6 7 8 9 10 #7100170-en
This book is available in a variety of formats at: http://
www.juniper.net/dayone.
Welcome to Day One
This book is part of a growing library of Day One books, produced and
published by Juniper Networks Books.
Day One books were conceived to help you get just the information that
you need on day one. The series covers Junos OS and Juniper Networks
networking essentials with straightforward explanations, step-by-step
instructions, and practical examples that are easy to follow.
The Day One library also includes a slightly larger and longer suite of
This Week books, whose concepts and test bed examples are more
similar to a weeklong seminar.
You can obtain either series, in multiple formats:
Download a free PDF edition at http://www.juniper.net/dayone.
Get the ebook edition for iPhones and iPads from the iTunes Store.
Search for Juniper Networks Books.
Get the ebook edition for any device that runs the Kindle app
(Android, Kindle, iPad, PC, or Mac) by opening your device's
Kindle app and going to the Kindle Store. Search for Juniper
Networks Books.
Purchase the paper edition at either Vervante Corporation (www.
vervante.com) or Amazon (amazon.com) for between $12-$28,
depending on page length.
Note that Nook, iPad, and various Android apps can also view
PDF files.
If your device or ebook app uses .epub files, but isn't an Apple
product, open iTunes and download the .epub file from the iTunes
Store. You can now drag and drop the file out of iTunes onto your
desktop and sync with your .epub device.
v
vi
What You Need to Know Before Reading This Book
Basic knowledge of TCP/IP and sockets
An understanding of simple network routing and Ethernet
switching and web security
An intermediate knowledge on the functions of a web browser
and HTML code
Some hands-on knowledge of virtualization technologies
After Reading This Book, You’ll Be Able To:
Understand the problems solved by Junos WebApp Secure.
Understand the relationship between the Firewall, Junos
WebApp Secure, the Load Balancer, and the Web Application
Server it is protecting.
Design a Junos WebApp Secure deployment in the context of
your environment.
Deploy Junos WebApp Secure on VMware ESX.
Configure a backend server.
Configure the login processor to protect key applications.
Test Junos WebApp Secure.
Chapter 1
The Threat Landscape
This chapter attempts to show you how the online threats to
organizations and enterprises around the world have changed. It
discusses the economics of web hacking and the strategies that
can be used to combat it. It also breaks down a “typical” web
attack into its major phases and discusses the countermeasures
you can use to defend your network. Finally, it discusses where
Junos WebApp Secure fits into a layered approach to Enterprise
security.
Web Security
Traditionally, the focus of web security has been concerned with
script kiddies – archetypical teenagers using readily available
tools to attack and deface the websites of the unwary. The profile
of web hackers (or more correctly, attackers) has changed. The
script kiddies have graduated to become a serious threat. The
motives behind attacking websites have also changed, from
gaining peer prestige to earning cold hard cash.
The monetary value of a public-facing web server depends on the
perspective of the observer; there is the physical hardware and the
data at rest, both are potential targets for attackers and the
primary concern of this book.
Hacking web sites for profit is now a business, and a lucrative one
at that. Thus hacking is subject to basic principles of economics
the same as any other enterprise, legitimate or otherwise. Economic viability is key to an attack: time invested and resources
8
Day One: Deploying Junos WebApp Secure
committed must provide a return, otherwise the operation becomes
unsustainable. The laws of supply and demand also apply to those who
do not subscribe to the rule of law.
The goal of Junos WebApp Secure is to protect your assets from exploitation and theft using deceptive, non-traditional methods. For example, would-be attackers can be detected by laying and observing false
trails. Another method of protection is ensnaring attackers by placing
increasingly devious traps in their path. The aim is to make attackers
turn back and find some easier prey where they can achieve a quicker
return on the time and assets devoted to breaking in. Junos WebApp
Secure gives you the tools to make hacking your website uneconomical
for even the most determined professional cyber-criminals, and force
them elsewhere.
Intrigued? How does Junos WebApp Secure (JWAS) go about fighting
back? For a deeper understanding, let’s break down the basic anatomy
of a web attack.
The Anatomy of a Web Attack
Contrary to what popular culture and James Bond movies would have
you believe, the secrets of the Western World do not scroll across your
screen like a news ticker after a few minutes at the keyboard. The
reality is far more complicated, time consuming, monotonous, and
frankly much more of a day job, just like yours and mine.
The typical successful attack can be broken down into five phases.
Phase I – Reconnaissance
The first phase of the attack involves basic reconnaissance of the
target. Once upon a time this would have started with a NMAP TCP
SYN scan, a crude and easily identified attack by modern standards.
Now, the attacker accesses the target website in much the same way as
a standard user, but records the session using a combination of browser-based inspection tools and/or logging proxies. Once the attacker has
gathered sufficient information, a significant amount of time is spent
on offline analysis, examining the accessible scripts and middleware,
looking for hints about the logical or physical infrastructure. Many
web applications, especially small business online stores, use standard
templates that may have had minor customization before being put in
production. Off the shelf applications are a particularly rich source of
information as they may share common vulnerabilities and deployment errors with other sites in the hacker’s profile list. From this
information, the attacker can formulate a plan from which vectors are
likely to yield the desired economic results.
Chapter 1: The Threat Landscape
Phase II – Mapping the Target
After a decision to visit is made, an attacker will attempt to use what
was learned through reconnaissance to actively probe the target. This
is the first point where anything might be considered amiss from the
administrator’s perspective, because attackers make some effort to
disguise their physical locations by using a combination of obfuscation
techniques. The actual session traffic will be routed through “disposable” open proxies and virtual machines. Furthermore, attackers
employ basic security tools such as personal firewalls, anti-virus, and
locked-down browser security. Once they are satisfied they can not be
easily be traced if detected, attackers will start to map the application.
There are a variety of items on the virtual shopping list of attackers,
and at the top is input validation testing: by filling the input fields with
garbage they try to generate an error condition (error conditions are
used to reveal information that can be used to further the attack).
Attackers methodically take the reconnaissance information gathered
in Phase I and look at all the dynamic pages, input fields, and variables
until there is a sufficiently complete picture for their needs.
Administrators are likely to see an increase in the number of application server errors, but depending on traffic volumes, this may be barely
visible in the background noise of everyday transactions.
Once a set of likely candidates are gathered, our attacker systematically probes more deeply, trying to force the server to do something it is
not supposed to. For example, by inputting standard SQL statements
into the username fields, the attacker may get a response from the
back-end user database. Those results can then be used to craft a better
string, which reveals more information, or even system credentials.
While this might attract an attentive system administrator, or wellconfigured Intrusion Detection System (IDS), being detected is not an
issue. Attackers seek to identify if a web application is being protected
and it so, by what. If something is found, attackers will attempt to
identify the specific steps necessary to get detected. Conversely, attackers are also looking for what does not get detected and blocked; they
need know how far they can take an attack before getting caught.
When detected and actively denied access, attackers merely flip to the
next open proxy server and restart where they left off. This is possible
because the apparent source IP address bears no relation to an attackers actual location. Even a vigilant system administrator writing
custom IDS signatures on the fly cannot address every possible permutation of syntax. Attackers need to merely tweak the responses sufficiently so that they cease to be noticed and blocked by Man and
Machine.
9
10
The reality here is that a system administrator would have an extremely tough job of detecting and combatting such an attack, even with
expensive security tools in place. For most attacks, this phase is
completed long before anyone has checked the IPS alarm console. And
the attackers know that.
Phase III – Exploitation
Once the attack vector (i.e. specific vulnerability) has been established,
the attacker exploits it. The goal may be to siphon off user credentials,
steal credit card data, or to steal intellectual property that can be sold
on various markets. The damage is only limited by the amount and
kind of information held on the server.
NOTE
Attackers tend to deploy some sort of back-door (in order to make
their lives easier in the event of discovery), but back-door discovery is a
topic in its own right and provides a different set of challenges.
Phase IV – Automation
Once the manual part of the task is complete, the attacker automates
the process in order to maximize economic gain with minimum further
intervention. To automate, the attacker programs a network of “bots”
(Internet-connected computers no longer under the control of the
owner) to repeat the task Ad infinitum.
As an example, let’s say our attacker discovers a vulnerability in a
widely used Internet forum package, making it possible to replace the
revenue-generating embedded ad network with one that benefits the
attacker and not the site owner. To make this profitable, every new
post may need to be edited to ensure the alternative ad network is used.
Clearly a task best handled by an automated process.
The attacker is then free to concentrate on the next easy and profitable
target.
Phase V – Maintenance
Depending on the nature of the attack (targeted or random) the
intruder leaves the bots to keep exploiting the target. Should the target
notice that it is being abused, the attacker’s income may dry up as the
specific vulnerability (ies) are patched or fixed. Our attacker may
revisit the target and his original Phase I notes and attempt to find a
new exploit. Failing that, the attacker may give up and move on to a
new target.
In certain situations, the attacker may discover new techniques that
increase the revenue generated or just do it all more efficiently. Attackers are able to revisit and tweak their attacks at will, without worry.
NOTE
In some circumstances, this maintenance window has actually led to
attack discovery. A classic example of this was the Sony PlayStation
Network hack. The attack was only discovered after servers started
rebooting randomly when an update was botched by the attacker.
Strategies for Combatting an Attack
Clearly some very clever people are doing some ingenious things to
pick the virtual pockets of you and your network. Fortunately there
are also clever people coming up with strategies and technologies to
combat these attacks. Let’s visit some of the more commonly used techniques used in the context of web application security.
Signature-based Intrusion Detection System
Intrusion Detection Systems (IDS) and its more aggressive cousin,
Intrusion Prevention Systems (IPS), typically work on a signature basis
to detect inbound attacks. They inspect network flows (usually after
the Firewall) looking for known attacks. The major weakness of this
technology, when used alone, is the intensity of labor required to create
signatures after they have been witnessed in the wild.
IDS/IPS systems essentially look for known attacks that conform to a
very specific set of criteria. For example:
let’s say a common webserver has a bug that incorrectly handles file
name extensions, causing something bad to happen when a specific
URL is sent to a target webserver. A hacker figures out that if you send
the following URL to a web server…
http://targetserver/reallylongfilextension.12345
… the server reveals something useful about itself to the attacker such
as the location of a vital configuration file.
This event is observed in the wild by a network security company when
it is used to attack one of their honeypot hosts. A pattern file is created
that successfully matches the bad URL and blocks the traffic when
witnessed on a network inspection point. The software vendor might
even issue a patch to prevent the bad thing from happening whenever
the bad URL is sent to the web server.
However, until now, it’s not apparent that the same hacker also figured
out that when the following URL is sent to our web server…
11
12
http://targetserver/reallylongfileextension.123456789
..the bad thing happens again, except this time, the hacker saves
something special for when it is going to be most useful.
This whole exercise is a game of cat and mouse. And this is a very
simplified example of a buffer overflow attack and a zero-day exploit.
In reality the attacks and defenses are more sophisticated than the one
presented here. The key point is that IDS/IPS technology can only
detect and prevent an attack for which it has a matching signature - a
known vulnerability. Furthermore, the technology is only active at
Phase III of the attack exploitation, after the attacker has already
identified your site as a target and is actively trying to find a way in. At
this point, it is only a matter of time before a way is found to defeat the
pattern matching of even an aggressively configured IPS.
IDS and IPS systems are also prone to false positives. Unbeknown to
the administrator, minor application changes can easily trigger an IPS
signature to fire, blocking legitimate traffic that contains patterns
similar to those previously witnessed. Applications such as RPC and
HTTP are constantly evolving and somewhat defy standardization. As
a result, IDS/IPS vendors have to tune the signatures to ensure that the
legitimate traffic is not accidentally trapped, showing again that most
IDS/IPS technologies require significant manpower to implement and
maintain.
Web Application Firewall
A web application firewall is another security control that sits between
the web server and the end user. It can be integrated into the load
balancer, exist as a separate appliance, or be implemented in software.
While IDS/IPS systems work on the premise of blocking what is known
to be bad, Web Application Firewalls (WAFs) only permit what is
known to be good.
This works on a premise similar to IDS/IPS but in reverse. Rather than
maintain a database of previously known bad activity, the WAF learns
a narrow definition of client/server communication which can be
permitted.
A simple example is a Contact Me web-form. As part of normal
behavior a user completes some text fields such as Name, Address, and
phone number before submitting. Now it’s patently obvious that a
correctly filled out form should only contain a limited number of
alpha-numeric characters such as “A-Z”, “0-9”, and possibly some
punctuation such as hyphens, brackets, and full stops. If the server-side
application process blindly accepts whatever is submitted into the
form, it may be possible to overflow the application with a long strong
string that again causes the application to crash and do something bad.
At a simplistic level, Web Application Firewalls match data sent to, and
from, the protected server to ensure that it falls within specified
bounds. For example, “Name” fields should only contain alphabetical
characters and no special Unicode characters. Telephone numbers
should only contain digits 0-9 and only appear in certain formats.
Furthermore, the server-side responses should not contain anything
that looks like a password or credit card number.
From a security perspective, this strict enforcement of client-server I/O
provides an excellent level of protection. However, it is not without its
own pitfalls. Essentially, Web Application Firewalls force the web
application and network security teams to work together. With an
Active WAF in place, every small code change on a protected website
requires an update in the WAF policy. This requires a procedural
change that may be difficult to implement – usually for political or
business-related rather than technical reasons. Proper software quality
assurance also becomes very important. For example, you need to
consider what would happen when a legitimate user fills in a form
using a non-English alphabet. This can all be addressed with careful
application tuning and Unicode, but it adds a layer of complexity not
previously considered.
Web Application Firewalls are a powerful security tool and undoubtedly make life hard for the attacker, however, they also make it harder
for the Web Development and Security teams. WAFS are only effective
at Phase II target mapping and will give away their presence by
blocking or slowing the client IP addresses as the attacker probes the
deeper recesses of the application. WAFS can only frustrate rather than
foil the attacker at the crucial mapping stage. At this point, the attacker has already expended resources in compromising your system and
established it to be a viable, if difficult, target. It becomes a simple
calculation of effort versus reward for the attacker.
Web Intrusion Deception
The premise of Web Intrusion Deception (WID) is to game the system
by polluting the information gathered by the attacker. For many years
it has been standard practice to harden web servers by changing the
standard HTTP server headers to something misleading, in order to
confuse an attacker. The concepts of sticky honeypots have also been
around since at least 2003. The La Brea Tar Pit project is an early
example of software that provided an attractive target with the express
purpose of trapping would-be attackers.
13
14
Modern Intrusion Deception systems (and Junos WebApp Secure as
our case in point) “futz” with the communications between the client
and the server in ways that your common garden-variety web user
would never notice. However, to someone involved in the business of
making web servers do things they were never supposed to, it presents
a veritable smörgåsbord of attractive opportunities. Once the hackers
starts helping themselves to the pickled herring, they are flagged by
Junos WebApp Secure as an attacker. From this point forward, the
attacker is tracked across IPs and fed increasingly inaccurate responses. The goal is to waste the time and resources of the attacker on a
“ghost” of a web server to such an extent that further attacks are a
fruitless endeavor.
Because WIDs change the behavior of an application that would only
impact an attacker, they produce zero false positives; users who
attempt to screw around with debug code or hidden fields are not
going to have your best interests at heart. Crucially, WIDS are active
and effective at Stage 1 of the attack – they feed bogus and misleading
(but still plausible) information to connecting clients. While there is a
rationale that this might lead to more hacking attempts, given the
apparent attractiveness of the target, the goal is not to prevent the
attack as this is somewhat inevitable. The goal is to make all attacks,
sophisticated or otherwise, futile and frustrating without putting a
burden of maintenance on the system or system administrator.
Defense in Depth
Given that WID functions during the first phase of an attack, you’d be
mistaken thinking it was the only security technology needed. Although WIDS are another powerful weapon in the armory of the
system administrator, they do not replace other security technologies,
but rather complement the functionality of firewalls, IDS/IPS, and
Anti-Virus software.
There are compelling arguments that WID can be used as an alternative to “traditional” WAF solutions, but WIDS are designed to specifically combat attacks against Web applications. WIDs provide no
protection against other common attack vectors such as email malware, Wi-Fi password cracking, or physical security breaches.
Even in the world of Web applications, an active WIDS is not a security
panacea. An unsophisticated attack that skipped the first two stages
and attempted a buffer overflow against random hosts would not
necessarily be prevented. These kinds of attacks are best mopped up by
the firewall service gateway (SRX) or a dedicated IDS/IPS system such
as the Juniper IDP.
NOTE
Two common attacks skip past the analysis and go straight to Phase
III. The first is the older Worm type viruses that sequentially hunt
through connected net blocks trying to propagate. Using a very narrow
attack vector, they assume the Internet will deliver a vulnerable host
sooner or later. The second is automated penetration testing – the
traditional approach of testing web applications – where a third party
tests each host against a list of thousands of known vulnerabilities
using either commercial off-the-shelf or customized Open Source
Software. The logs on even an unsophisticated firewall will light up
like a Christmas tree when subjected to such a crude simulated attack,
and many will blacklist the originator IP addresses.
Fundamentally, penetration testing is an artificial process that provides
an artificial answer. It offers few guarantees against an actual exploit.
Reliance on penetration testing puts the administrator in the position
where the symptoms and cure validate each other, and yet the patient is
still sick – web servers still get hacked. It is clear that a new approach is
required.
Junos WebApp Secure defends against the techniques used by hackers
rather than the individual vulnerability or the artificial circumstances
of an automated penetration test. With Junos WebApp Secure deployed, you can almost certainly expect to “fail” an automated test.
That is not to say that penetration testing is worthless, but in essence
you get what you pay for. A quarterly quick scan that takes no more
than two days is going to achieve little more than a tick-box on a PCI
compliance assessment form. A two-week assessment with an open
remit will be far more revealing of your organization’s actual security
posture and is likely to be reassuringly expensive, but still a lot less
than a bushel of security appliances.
15
16
Chapter 2
Web Security Design
This chapter discusses the planning of a Junos WebApp Secure
Deployment, and the relationship between the basic components
of a typical web application deployment is broken down into its
constituent parts. The architecture of Junos WebApp Secure and
how it overlays into an existing environment is discussed. Finally,
the prerequisites are gathered to ensure sufficient preparation to
successfully complete implementation.
Web Security Design
When an organization deploys a new web application, the task
rarely falls to a single individual. Depending on the size and
complexity of an application, many specialists may be involved.
Inevitably this leads to a collective fuzzy understanding of how
the whole solution works. Each individual knows how a particular piece of the puzzle works, but has only a vague understanding
of the operation of the other system components. This becomes
an issue when Junos WebApp Secure is introduced, as it interacts
with the firewall, load balancer, and web server. To that end, it is
worth examining the function of each of these components to
better understand the end-to-end communication between web
browser and the application.
18
Web Application Deployment Components
User Browser
It is difficult to make assumptions about the connecting end user with
web applications – the nature of a standards-based Internet means our
user could be connecting from literally any location using any combination of operating system and hardware platform. For the sake of
simplicity, let’s assume our user is using a laptop computer with a
desktop operating system.
Layer 4 Edge Firewall
The job of the edge firewall is to screen bound connections to ensure
that only specific triplets (source network, destination network, and
application) of traffic are permitted. The Juniper SRX platform is one
of several next generation firewalls that can also perform Layer 7
inspection, looking deep into the application payload for security
threats. Essentially next generation firewalls incorporate elements of
Intrusion Detection and Prevention technology, which are beyond the
scope of this book. Let’s assume that the firewall is permitting traffic
inbound from any source traffic to a specific destination: the Layer 7
load balancer. Typically the standard TCP web application ports 80
(HTTP) and 443 (HTTPs) are used. Many firewalls in IPv4 networks
also perform Port and Network Address Translation (NAT) from
globally-routable addresses to Private RFC1918 address space.
In this context, NAT commonly performs two functions:
It allows many connected devices to share an exhausted IPv4
address pool.
It provides a basic level of network security – it is more difficult
for an attacker to map a network that is hidden behind a NAT
firewall.
Beyond network address translation (which changes the source
address, destination address, and destination port of the packet) Layer
4 firewalls do not typically alter the packet payload in transit.
Layer 7 Load Balancer
The primary task of the load balancer is take inbound connections and
redistribute them among one or more logical Web Application Servers.
The load balancer will usually “terminate” TCP sessions and establish
new connections to a pool of servers with a similar configuration. If a
Chapter 2: Web Security Design
failure is detected in one of the servers, the pool member is marked as
“down” and no further traffic is sent to the host. Load balancers also
create a positive performance impact by offloading processor-intensive
tasks such as TCP connection setup and SSL encryption.
As load balancers terminate or proxy the traffic between the connecting client and the web applications, the packet forwarded through the
firewall is different from the packet which is ultimately delivered to the
pool member.
The nomenclature differs between vendors, but for each load-balanced
service a Virtual IP (VIP) or Virtual Server (VS) is created. The VIP is
essentially an additional virtual IP address bound to a network
adaptor on the load balancer. Listening in on this IP address are virtual
sockets, one for each TCP or UDP application bound to the VIP.
Connections to the virtual sockets (usually forwarded via a firewall
NAT) are terminated and then forwarded to a pool member according
to availability and/or expected load.
NOTE
The term Application Delivery Controller (ADC) is used somewhat
interchangeably with load balancer. An ADC can be considered a load
balancer with an advanced set of Layer 7 features such as enhanced
caching and security. In the context of a Junos WebApp Secure
deployment, these features are not necessarily relevant and many web
application deployments utilize relatively straightforward load
balancing technology.
Web Server Pool
The Web Server Pool is a logical grouping of servers that all run the
same web application. In small environments this may only be a single
logical server with a backup; in large environments this may be many
logical servers located in different data centers that are dynamically
spun up on demand. The assumption is that each logical server is a
mirror of its peers with only minor configuration differences, such as
IP address. Differences in hardware and server performance are
managed by either weighting the inbound server connections or
performing response-time analytics. It is perfectly feasible that logical
servers may in fact run multiple web applications on the same infrastructure – this is a relatively standard configuration in a tenanted
environment.
Figure 2.1 shows the general flow of traffic from the user browser to
the back-end Web Server Pool.
19
20
Figure 2.1 Logical Connection Flow
Logical Architecture of Junos WebApp Secure
Junos WebApp Secure is typically deployed between the load balancer
and the Web Server Pool. Inbound connections are forwarded from the
load balancer to the Junos WebApp Secure Server. JWAS inspects the
traffic before establishing a new connection to a server in the Web
Server Pool. Once the server has processed the response, the traffic is
forwarded back through the Junos WebApp Secure Server where it is
inspected again and the payload is modified before being returned to
the load balancer. The load balancer then re-encapsulates the traffic
before forwarding it back down the return path. The return traffic
from the Web Server Pool always transits the Junos WebApp Secure
instance because the source address in all communications is the Junos
WebApp Secure Server.
Single Server Deployment
In a simple environment, one may only require a single instance of
Junos WebApp Secure to protect a single server. JWAS is usually
deployed after the load balancer for the following reasons:
Resilience: Typically the load balancer will be configured to
fail-through a failed instance of Junos WebApp Secure. In the
event of a system error or scheduled service update, the load
balancer automatically forwards failed connections to the “real”
backend server. This is sometimes referred to as a fail open
configuration. How this is achieved is discussed further in
Chapter 4 of this book, Network and Application Integration.
Performance: Load balancers tend to be highly optimized for
Network I/O and may include dedicated hardware for processing
tasks such as SSL encryption or HTTP compression. It is preferable that these tasks are handled by a dedicated appliance. While
While Junos WebApp Secure can process SSL traffic and has basic
load balancing features, better application performance will
inevitably be achieved by using a dedicated solution.
Filtering: Load balancers and firewalls also filter out non-HTTP
and HTTPs traffic to the Junos WebApp Secure Server, but can
also be used to intelligently forward specific HTTP traffic. If the
application consists of a large amount of static content (such as
stock photographs) it would not be desirable to have this traffic
inspected by JWAS. In this case, only the active portions of the
application, such as the shopping basket, need to be forwarded to
the Junos WebApp Secure Server, a function that can be achieved
by more advanced load balancers.
Figure 2.2
Single Server Deployment
You may find that in many cases the single server deployment provides
an insufficient level of resilience and performance for a production
environment. Let’s discuss your options.
One-to-One Deployment
One alternative is to deploy multiple Junos WebApp Secure Servers,
each of which has a one-to-one relationship with a specific Web Server.
This is relatively simple to deploy but is inefficient. In the event of the
failure of a single Junos WebApp Secure Server, an entire Web Server
also becomes unavailable.
Making performance-based load-balancing decisions also becomes
difficult in this scenario as inevitably there will be a performance
differential between each Junos WebApp Secure Server and the Pool
Member that it protects. This can be exacerbated by the fact that each
session will create different relative workloads on the paired servers.
Load balancers with Application Delivery Controller features are able
to query multiple backend servers to calculate the cumulative load on
each pair of servers. This should prevent traffic from being directed to
a server pair in the event of one member becoming overloaded, but
inevitably there is a waste of resources on either the Junos WebApp
Secure Server or the web server. Additionally, if the servers are de-
21
22
ployed as standalone devices, corresponding hacker and attack data
will be not consistent across the estate.
Figure 2.3 illustrates the relationship between Junos WebApp Secure
and the pool members in a one-to-one deployment scenario.
Figure 2.3
One-to-One Deployment
Many-to-Many Deployment
A more scalable solution is to utilize a many-to-many deployment,
essentially creating two separate pools: one of Junos WebApp Secure
Servers and another of Web Servers. This requires more planning than
either a single server or a one-to-one deployment, but ultimately it
creates a more efficient solution by utilizing multiple VIPs on the load
balancer.
The first VIP is bound to a pool of identically configured Junos
WebApp Secure Servers. Rather than point directly to an individual
Web Server, the backend server configuration points to another VIP on
the load balancer. In this scenario, each inbound connection is loadbalanced twice, once to select the best available Junos WebApp Secure
Server, and again to select the best available web server. In the event of
a failure of either a Junos WebApp Secure Server or Member Server, the
connections will be automatically redistributed to the remaining
member servers.
In most cases, a separate or second deployment of load balancers will
not be necessary. This has an impact on capacity planning, however, as
the load balancer has to deal with double the number of connections
compared to a one-to-one deployment. Figure 2.4 shows the additional
local load balancer instance deployed between the Junos WebApp
Secure Pool and the Web Server Member pool.
Figure 2.4 Many-to-Many Deployment
Physical Deployment
Junos WebApp Secure can be deployed without significant levels of
supporting equipment. Figure 2.5 shows a single server deployment
with a cluster of firewalls, a cluster of load balancers, and a single
Junos WebApp Secure with a single backend server. In this this case,
NAT is performed by the firewall and forwarded to the load balancer
where the connection is terminated. A load balancer is not actually
necessary in this scenario and the connection can easily be terminated
directly on the Junos WebApp Secure Server itself, but that is an
uncommon scenario as failure of the server will result in a loss of
service, though in pre-production environments this may well be
acceptable. The load balancer cluster VIP, Junos WebApp Secure
Server, and backend server are all placed on the same Layer 3 subnet.
The design is simple to deploy, although the security could be better
because there is no inspection of traffic between the load balancer and
the Junos WebApp Secure Server. It also provides good performance as
the connections are simply switched at Layer 3.
NOTE
This method is typical in entirely virtualized designs where the load
balancer, Junos WebApp Secure Server, and the member servers are all
virtual editions.
23
24
Figure 2.5
Simple Physical Design
Figure 2.6 shows the transformation of the TCP packets as they transit
the infrastructure and where the sessions are transformed or terminated by the various components.
In larger deployments, or those employing physical hardware, a more
traditional layered security design may be used. Rather than placing all
the components on the same flat subnet, each device is separated into
individual De-Militarized Zones (DMZs) so that each connection must
cross a firewall or other Layer 7 device multiple times. The goal of this
design is to add as many logical barriers between the outside world and
the protected device as possible, avoiding a direct route back to the
Internet. Traditionally, this has been considered the Gold Standard in
secure web designs but it comes with significant caveats compared with
more simple designs:
This design and its variants are significantly difficult to set up and
maintain. Even a minor application change would trigger
configuration changes on multiple devices. It is said: Complexity
is the Enemy of Security.
Figure 2.6
Session Transformation
Adding additional redundant network inspection points inevitably injects latency into every transaction and performance may
be affected. Latency is very difficult to compensate for and is a
cost of transaction that is always handed back to the visiting
end-user.
Visibility and troubleshooting become very difficult. With many
network inspection points in place, tracing which device is
mangling traffic becomes increasingly difficult.
Despite its Gold Standard, web sites still get hacked. It’s difficult
to get any real data on the subject, as organizations that are
successfully penetrated don’t tend to provide a network diagram
of the compromised environment detailing the exact modus
operandi and locus delicti.
25
26
As a result, it may be difficult to justify the layered approach as a
security best practice in a world where technologies such as Junos
WebApp Secure need to exist. Figure 2.7 shows a complex environment, which you may find in a large web farm.
Figure 2.7
Advanced Deployment
Figure 2.7 is in effect the many-to-many logical network design taken
to its extreme with additional traditional security controls layered on
top. The general premise is that as the connection works its way
through to the destination Web Server, increasingly finer levels of
control will be applied. The components are as follows:
Screening Edge Router: The edge router provides the physical
link to the Internet. In some cases the functions may be collapsed
into the edge firewall. This is common in Juniper SRX deployments as many routing features are integrated into the platform.
In a classic design, a basic access control list (or non-stateful
firewall) would be in place to filter out and silently drop certain
traffic. This might include LAN-typical protocols, such as SMB
or MS-SQL, which in context would be associated with virus or
worm activity.
Edge Firewall Cluster: The edge firewall cluster is typically
responsible for NAT and deeper screening of source and destination pairs. In the context of our design, it will only permit HTTP
and HTTPs traffic into the External VIP of the Tier 1 load
balancer cluster.
Tier 1 Load Balancer Cluster: This is the first device that terminates the TCP session and where applicable, the HTTPS session
also. Depending on the configuration, it may also perform some
level of Layer 7 payload inspection. A new connection is established and forwarded out a different logical interface towards a
Junos WebApp Secure Server member nominated either by a
load-balancing algorithm or a match against a pre-existing
connection table.
Tier 1 Firewall Cluster: This optional layer provides an additional level of security between the load balancer and Junos WebApp
Secure Server Pool. Its primary purpose is to prevent a crossprotocol breakout should the load balancer platform itself
become compromised. This is the first opportunity IDP technology will have to inspect decrypted HTTPs traffic.
Junos WebApp Secure Server Pool: Once the inbound connection
has crossed the Tier-1 Firewall, it is again terminated for inspection on the Junos WebApp Secure nominated by the Tier-1 load
balancer. If this is an existing session, JWAS may strip out or
modify one or more session parameters from the HTTP stream
before forwarding. In this case, the Junos WebApp Secure is
configured to use the Tier 2 load balancer cluster external VIP as
its backend server. It is located on the same subnet in this instance, but in extreme cases it could be behind a logical firewall
cluster.
27
28
Tier 2 Load Balancer Cluster: The Tier 2 load balancer accepts
inbound connections from the Junos WebApp Secure Server and
makes another layer load balancing decision to forward the
connection on the most available Web Server Pool Member.
IDP Unit (Transparent mode): The final traffic inspection point is
on the immediate inside of the Tier 2 load balancer. In this case,
the device is deployed in transparent mode for simplicity. The
IDP unit need only intervene on traffic flows suspected of being
malicious rather than on all traffic, regardless of the apparent
posture.
Web Server Pool Member: The connection is received from the
Web Server Pool member nominated by the Tier 2 load balancer.
The TCP session table on the host will show the source connection to be originating from the inside address of the Tier 2 load
balancer, rather than real source address of the connection client:
in this case 8.8.8.8.
NOTE
The repeated transformation of traffic in this scenario can create an
issue with logging and reporting systems, making it difficult to determine the “real” source IP address. To that end, most load balancers
inject an additional field within the HTTP header, X-Forwarded-For.
As a session transits the load balancer, the “real” connecting IP address
is of the originating client and it is copied from the TCP headers into
the HTTP headers. This field is also extended on each session transformation by a proxy (in this case, the load balancer). This provides the
ultimate target web server with an understanding of the path the
session took through the network. This greatly enhances troubleshooting as it avoids the need to correlate a large number of firewall and IPS
logs. This feature is not always enabled by all load balancer vendors
and the web server itself will often need minor configuration changes
to log and process the X-Forwarded-For header.
NOTE
In a virtualized environment, several components and functions might
be collapsed into a single-device cluster. For example, the Edge Firewall, 1st Tier Firewall, and 2nd Tier IDP may in fact be handled by the
same logical device but use separate virtual zones and policies to
behave as multiple discrete inspection points. The same is also true of
the load balancer clusters, as most vendors will support multiple
discrete VIPS and network.
The logical order of inspection and placement of devices such as
firewalls and Intrusion detection is not fixed; there is no one correct
deployment. As an example, if the same infrastructure is expected to
also handle non-web traffic, it may be desirable to move the intrusion
detection inspection point further up the packet flow in order to
provide protection of other protocols.
In many cases, Junos WebApp Secure will be deployed in an existing
environment that will resemble some version of both examples provided here, making the correct implementation almost certainly
dependent upon what is already in place, rather than an idealized
version of a best practice deployment.
Sample Deployment Plan
A phased-in approach is recommended in order to successfully deploy
Junos WebApp Secure. For Intrusion Deception to be effective, it must
be deployed between the client and the server it is protecting. Deploying Junos WebApp Secure off-path, as per intrusion detection systems,
is not feasible; to provide any measure of effectiveness the appliance
must be able to intercept traffic and process the responses. However,
with careful planning it is possible to gradually introduce Junos
WebApp Secure without impacting users.
Test in Preproduction
Ideally the initial Junos WebApp Secure installation should be in a
pre-production or development environment. This allows interested
parties to gain an understanding of the basics of Intrusion Deception
without interfering with production user sessions. In many cases, the
preproduction system is a mirror of the production system but typically contains fewer or less powerful hosts. Taking this into account,
the following steps can be repeated for both production and pre-production systems.
Deploy the First Server
Junos WebApp Secure can be installed and configured without impacting on user traffic as it does not become active until such time as
inbound web traffic is directed to it. A backend server can receive and
process traffic forwarded via Junos WebApp Secure, and at the same
time process direct requests simultaneously. Should errors occur, only
user sessions forwarded through Junos WebApp Secure are affected,
allowing basic testing without impact on production or even pre-production sessions. The process of setting up a Junos WebApp Secure
Server is detailed later in this chapter.
29
30
Local Host File Testing
Most client operating systems have an administrator-editable hosts file.
The hosts file converts hostnames to IP addresses in the absence of a
DNS server, but also allows the administrator to manually alter the
host names mapping on a per-host basis. This method allows the
application to be tested while preserving volatile variables such as host
headers and session cookies. As far as the browser is concerned, the
user is communicating directly with the target web server. In reality, the
local hosts file is directing the session to the Junos WebApp Secure
Server, which is acting as a reverse-proxy for the real application web
server.
In Windows operation systems, the hosts file is located in %SystemRoot%\System32\Drivers\etc\hosts and in most Linux Operating
systems in /etc/hosts. A basic host file from a Windows platform is
shown below.
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for
Windows.
#
#Junos WebApp Secure Pool
172.16.10.150 Grizzly
# Web Server Pool
172.16.10.220 Rupert
In the above example, by editing the hosts file, commenting out the
entry for Rupert (the web server we are trying to protect) we can add
the host name as an alias for the IP address for Grizzly, our Junos
WebApp Secure Server. The completed entry should look something
like the one below:
#Junos WebApp Secure Pool
172.16.10.150 Grizzly Rupert
# Web Server Pool
# 172.16.10.220Rupert
Once the file is saved, the effect is usually immediate, and can be
confirmed with a ping test.
C:\Windows\System32\drivers\etc>ping Grizzly
Pinging Grizzly [172.16.10.150] with 32 bytes of data:
Reply from 172.16.10.150: bytes=32 time<1ms TTL=127
Ping statistics for 172.16.10.150:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\System32\drivers\etc>ping Rupert
Pinging Rupert [172.16.10.150] with 32 bytes of data:
Ping statistics for 172.16.10.150:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
In the ping, you can see that the client operating system is fooled into
forwarding traffic for our web server Rupert to the Junos WebApp
Secure Server Grizzly.
TIP
Once the host file has been edited and saved, in most cases Windows
automatically picks up the changes. But occasionally, Windows will
cache the results of a previously successful query and not check the
hosts file again. In most cases this is corrected by simply clearing the
DNS resolver cache on the client by using the ipconfig /flushdns
command from the command prompt.
NOTE
When testing Junos WebApp Secure Server, it is important to remember that if a connecting web browser is configured to use a proxy
server, or PAC file web browser, it overrides the local host’s file configuration. When a proxy server or PAC file is configured, DNS resolution
is handled by the proxy and not the client operating system DNS
resolver. When testing Junos WebApp Secure Server it is recommended
that proxy server and/or PAC files browser configuration be temporarily disabled, forcing the connections to go directly to the nominated
server.
Limited Deployment
Once the initial client-side testing has been completed and the baseline
functionality has been confirmed to be compatible with Junos WebApp
Secure, a limited deployment can begin. For single-server deployments
without a load balancer, it is not straightforward to perform a phased
migration. In such a case, traffic must be forcibly directed to the Junos
WebApp Secure Server and if necessary, manually moved back via a
firewall NAT change.
31
32
For single-server deployments with basic load balancer functionality,
Junos WebApp Secure can be defined as an additional Pool Member in
an existing Web Server Pool. Depending on the availability of resources, the server to which it is paired can be marked as “down” or remain
servicing requests. The Junos WebApp Secure Server will receive a
proportion of new connections based upon the number of available
servers and the load balancing algorithm used. Depending on the
functionality of the load balancer, the number of connections directed
to the Junos WebApp Secure Server can be gradually increased from a
low baseline to a full production load. This allows for an extended
lead-in to allow the impact on performance on a single server to be
understood.
Figure 2.8 shows the path of traffic during an initial limited deployment with a single active Junos WebApp Secure Server.
Figure 2.8
Limited Deployment
Production Deployment
Once the baseline performance of a single server has been benchmarked, a judgment can be made on the number of logical Junos
WebApp Secure Server instances required to support a full production
deployment. Furthermore, after exposure to production or simulatedproduction levels of traffic, any known application compatibility issues
should have been ironed out.
Preparing For Deployment
Before implementation can be begin, some basic network metrics
should be gathered to ensure a smooth implementation. Some aspects
(such a SSL certificates) are not applicable in every environment.
Table 2.1
Host Configuration
Item
Description/Example
Fully Qualified Domain Name
grizzly.foo.com
1st Junos WebApp Secure Server IP
Address & Subnet Mask
172.16.10.150/24
2nd Junos WebApp Secure Server IP
Address & Subnet Mask
172.16.10.151/24
Default Gateway
172.16.10.1
DNS Servers
Local DNS Server IPs
NTP Servers
Local Time Services
Configuration Mode
Standalone/Master
Backend Server Address(s)
First Web server or Pool
Public Key Certificate
Signed by root CA
Private Key File
Secure Certificate File
Root CA Public Key
Provided by root CA
Load Balancer 1st IP Address
172.16.10.100
Load Balancer Monitor Address
172.16.10.101
Health Check URL
Captured at deployment time
Backup Encryption Key
Captured at deployment time
Write Your Settings Here
33
34
Chapter 3
Installing Web Security
This chapter walks you through the process of setting up Junos
WebApp Secure for the first time as a Virtual Server. You will
move through the process of connecting to the vSphere client,
deploying the OVA template, and completing the console configuration. The discussion then switches to the Web GUI, so you
can complete the configuration, and finally, there is some postinstallation housekeeping to undertake.
VMware Console Setup
Setting up Junos WebApp Secure is a very simple task if you have
a VMware ESX host already configured and connected to the
network. Juniper Networks provides Junos WebApp Secure as a
OVF (Open Virtualization Format) OVA file. The minimum
resource requirements to deploy the template are:
ESXi 4.1 or newer
2 vCPUs
6 GB of RAM
20 GB of disk space
The OVA template automatically configures these settings when
the virtual machine is deployed.
36
To Deploy the OVA Template
1. Open VMware vSphere Client and connect to either VMware
vCenter Server or direct to your VMware ESXi Host as shown.
2. From the File menu select Deploy OVF Template.
3. The OVF Deployment Template wizard is launched. The first step is
to find the OVF deployment file – it has to be accessible from your
local workstation running the vSphere client, as the ESXi host does
not make any outbound connections.
Chapter 3: Installing Web Security
4. The vSphere client then displays some basic information regarding
the contents of the package. At the time of this writing, the packages
are not signed by Juniper Networks, but this may change in future
versions.
37
38
5. Give the new Virtual Machine a descriptive name: if you specify the
hostname then bear in mind that it won’t be mirrored in the
configuration. (If you are using vSphere then you need to select the
Datacenter target before you can select the host.)
6. Select the host to deploy the template into, and if appropriate for
your ESXi environment, select a Resource Pool. (The default pool is
usually fine.)
7. Select the storage destination you wish to use. This may be a local
disk or attached to your network, and it will vary according to your
individual ESXi deployment. Junos WebApp Secure typically does not
consume a large amount of disk storage, but it is necessary to ensure
that you have sufficient storage for the initial deployment and any
subsequent snapshots you may take.
8. The vSphere Console then allows you to select which data store
provisioning mode you wish to use according to your existing Virtual
disk policies; the default usually is fine.
39
40
9. The wizard will attempt to map network interface held within the
OVF template to one already present in your ESXi deployment. In this
case, it has matched the template to “Home Main Network
172.16.10”, which is correct in the context of the example. This can
easily be changed at a later stage.
MORE? A further discussion on network layout can be found later in
the Housekeeping section of this chapter.
10. You are presented with a summary of your choices; if all is correct,
click Finish. You can see that the virtual machine can optionally be
powered on after deployment (the check box). But it’s recommended
that this setting is enabled to give further opportunity to review the
settings.
11. The VMware console then copies the OVF file from your
workstation into the ESXi host. The package is unpacked and the
virtual disks are created. Depending on the speed of your connection
and available processing resources, this may take a few minutes or up
to several hours to complete.
41
42
12. Once the Virtual Machine has been deployed, you should see the
guest you named in Step 5 appear in the console. Right click on the
new guest to bring up the context menu and select Edit Settings...
13. With the Virtual Machine Properties open, you can review the
resources configured. You may wish to double-check that Network
Adaptor 1 is associated with the appropriate Network Label, and that
optionally, you add second or third logical network interfaces if your
environment requires it.
ALERT! It’s possible, but not recommended, to adjust the number of CPUs and
the amount of RAM allocated to your Virtual Machine. Do not do so
unless instructed by Juniper Support.
If you are satisfied with the settings click OK to return to the vSphere
client. The virtual machine is now ready to power on and begin the
text mode setup.
Text Mode Setup
Once the Virtual Machine has been deployed, it is time to power on
and configure the base operating system.
To Configure the Base Operating System
1. Right-click on your Virtual Machine and click Open Console.
2. A black console window should open up. Press the green triangular
Play button to start the Guest. After a few moments Scientific Linux
will start and after a few minutes you will be presented with the
console log in window.
43
44
3. Once the virtual machine has finished booting, click in the black
area of the window to make sure the virtual machine has been
activated. Log in to Junos WebApp Secure with the default username
and password:
Default Username: mykonos
Default Password: mykonosadmin
4. The log in automatically starts the Setup Utility, which is used to
change various configuration options that are not available in the Web
GUI setup, as well as assisting any troubleshooting of the
configuration or conducting maintenance.
NOTE
To return to the Setup Utility when at the shell prompt, use the command: [mykonos@grizzly ~]$ sudo setup.
5. The first step is to configure the basic network configuration. Scroll
down using the cursor keys to Network Configuration and press
Enter. Press Enter again to set the hostname.
6. Set the hostname to something meaningful to you and your network
– ideally it should match the server name you specified when deploying
the virtual machine, but this is not critical.
45
46
7. Press the Enter key to update the hostname or click on Update. The
program returns you to the Network Menu. Scroll down to Configure
Interfaces and press Enter.
8. Now you can configure the first logical interface, eth0. Select eth0
and press the Enter key to configure.
9. By default, DHCP (Dynamic Host Configuration Protocol) is
enabled on the network interface. In almost all cases, DHCP needs to
be disabled and the IP replaced with a static IP address. Feed in your IP
configuration as gathered at the end of Chapter 2, taking into account
whether your load balancer or firewall is acting as a default gateway.
10. Select Save and return to the network Menu.
11. Proceed to the DNS Settings to configure your domain name,
taking care to add any additional DNS search suffixes required.
However, in most cases, this can be left blank. To list multiple DNSs,
separate them via a comma; for example: 172.16.10.1, 172.16.10.2.
12. Click on Save to return to the previous menu.
13. Optionally, there are some additional configuration items you may
need to address depending on your environment:
Add Virtual Interface: This allows you to bind an additional IP
address to an existing physical interface, which is helpful when
dealing with multiple SSL certificates and applications on a single
Junos WebApp Secure Server.
Add VLAN Interface: Some network deployments place different
logical networks on the same physical network. This option
allows you to create and address a logical VLAN interface and
specify a 802.11q VLAN tag.
Add Bonded Interface: Multiple physical interfaces can be
bundled together to form a single logical interface for both
performance and resilience. This configuration is not usually
required within a VMware ESXi environment.
Proxy Settings: In very secure web DMZ environments, there
may not be a direct path back to the Internet to allow the virtual
server to collect updates from Juniper. In this case, a local
outbound proxy server can be used as an intermediary.
Cluster Interfaces: In highly available configurations a dedicated
cluster interface can be specified to allow peer virtual appliances
to share configuration and session information.
47
48
14. Once you are happy with the configuration, scroll down to Restart
Networking to ensure the configuration changes have taken effect and
click on Exit.
15. The next step is to initialize the virtual appliance, preparing the
database and the configuration for the first time. (Note that this
process can be repeated at any stage, but will permanently delete data
on the system including any attackers which are currently being
tracked.) Open the Initialize Appliance option (see Step 3), press
Enter, and then Confirm (shown here) to start the operation.
16. There are four separate appliance modes available:
Standalone is a self-contained appliance that processes traffic and
contains configuration information unique to itself.
Master appliances can push configuration to other Traffic Process
appliances as well as process traffic.
Dedicated masters only hold configuration information, they do
not process traffic.
Traffic processors only process traffic and do not hold any
configuration information.
In this context, select Standalone.
17. Junos WebApp Secure will then initialize the database. This will
take several minutes to complete, depending on the resources of your
host. Press OK to continue when the process is complete. You are now
ready to begin the web-based portion of configuration.
49
50
Starting the Web Interface
Now the basic network configuration has been entered, it should be
possible to reach the Web Interface to complete the application
configuration.
The web interface provides a dashboard of recent security incidents,
hackers, and open sessions. The interface allows you to drill down into
incidents as they occur. The web interface is also used for day-to-day
administration of the virtual appliance, defining applications, responses, and alerts. To access the Junos WebApp Secure interface open a web
browser and connect to:
https://<IPADDRESS>:5000
…where <IPADDRESS> is the IP address of your Junos WebApp
Secure Server.
In most cases, you are presented with a certificate error the first time
you connect. The default certificate included with the Junos WebApp
Secure package will not be trusted by your computer’s web browser.
This is to be expected.
To Use the Web Interface
1. Open a web browser and connect to https://<IPADDRESS>:5000
to access the Web Interface. Sign in with the default username of
mykonos and the default password mykonosadmin.
2. As this is the first time you have connected to Junos WebApp Secure,
a license key must be provided. This is usually delivered electronically
at the time of order, or may come from your local Juniper account
representative. The keys are a short text string in the format XXXXXX-XXX-XXX-XXXX consisting of numbers and letters. Enter
this string into the text box and click Add to import the string.
NOTE
The license validation service requires outbound Internet access in
order to be able to successfully license and receive updates. This
service runs over TCP 443 (SSL) and connects to licensing.mykonossoftware.com. The connection is made either via a proxy server as
configured in section 3.2 or directly once DNS has been configured and
the port opened on the upstream firewall.
3. Read and accept the software licensing terms. You can optionally
send your hardware details to Juniper Customer Support directly from
the appliance, but this is not necessary in a virtualized environment.
Click the Save License button to continue.
51
52
4. The Configuration Manager details all the active license keys on the
appliance and the expected expiration date.
5. Click the Edit Preferences button in the top right corner of the
screen. This will show some advanced options. By clicking in the Skin
drop down box it is possible to change the appearance of Web
Interface. Select the Light skin to make the web interface readable at
most screen resolutions. The default Language may also be changed
in this menu if required. The Junos WebApp Secure appliance
Timezone may be set via the drop-down box. As with most security
appliances the default is set to UTC Coordinated Universal Time.
Change this setting if you wish to localize the server. Expert Mode is
also configurable from this screen. Advanced configuration options
for some environments are displayed when Expert Mode is enabled.
6. Scroll down to the bottom of the window and click the Save button
to commit the configuration.
7. To start the Configuration Wizard, click the highlighted area at the
top of the screen. Depending on your environment, the Configuration
Wizard has between five and nine steps. Let’s review all of those steps,
but you may wish to skip some for your environment.
8. Configure Backend Servers. A backend server is a Web Server
hosting the application that you wish to protect using Junos WebApp
Secure. The assumption is that each Application you wish to protect
runs on at least one web server. Junos WebApp Secure can act as a
simple software load balancer and direct inbound connections to
multiple identically configured web servers. If this is the case, you can
enter the number of identical web servers you have running the same
application. It is not generally recommended that you enable this
feature. In this case, let’s accept the default of a single backend server.
Click Next to continue.
53
54
9. Provide a name and address for the backend servers. Name the first
logical server so it can be easily identified by yourself or another
network administrator. The Server IP address is the standard IPv4
interface the application is listening in on. In most cases the HTTP
and HTTPs port will be the server standards, 80 and 443. If your web
servers are running on any alternate ports such as 81 or 8080, adjust
accordingly. When utilizing the load balancing features of Junos
WebApp Secure, it is necessary to specify a priority for each virtual
server for load distribution. Specify 1 to ensure the server always
receives traffic. In load-balancing scenarios, a server configured as a
backup will only receive traffic when all other servers are unavailable.
In almost all cases Backup should be disabled.
10. SMTP Settings. Junos WebApp Secure generates reports and alerts
dependent on the enabled configuration. To deliver these alerts to an
inbox, an SMTP mail relay must be configured. In most cases, this will
be a pre-existing intranet server used for forwarding mail around the
organization but in some cases there may be a relay specifically
deployed for the Demilitarized zone. Enter the following information:
Default Sender Address. The alerts will be sent by this sender.
SMTP Server Address. The local mail relay responsible for
forwarding mail.
SMTP Server port. In most cases this will be the default TCP port
25.
SMTP Username and Password. If authentication is required
enter credentials provided by the mail server administrator,
otherwise leave blank.
Select Next to continue.
TIP
Specify the hostname in the default sender address to identify at a
glance which instance of Junos WebApp Secure generated the alert.
TIP
SMTP Mail relay servers tend to be static hosts that do not change
often, in this case it is suggested the fixed IP address is used to prevent
Junos WebApp Secure from being dependent on DNS to send alerts.
NOTE
It is quite likely that the mail server administrator will need to be
informed that Junos WebApp Secure will be generating SMTP alerts
and the configuration will need to be altered to allow the Virtual Server
to relay mail internally. This is a simple change and will vary according
to the mail relay software deployed.
11. Enable Alerts Service. To receive alerts via SNMP or SMTP the
Alert service must be enabled. Even in pre-production and test
environments it is worth enabling the alerts to gauge the number of
alerts which are actually generated. Junos WebApp Secure generates a
zero false-positive rate so even in very busy environments relatively few
alerts are sent. Tick the Send Alerts? box and click Next to continue.
55
56
12. Configure the number of SNMP servers and SMTP recipients.
Depending on your environment you may wish to receive alerts via
SNMP (Simple Network Management Protocol) or SMTP (Simple Mail
Transfer Protocol). In either case, the details of these services will be
provided by the responsible network administrator. Enter the number
of SNMP servers in your environment if any are present, and enter the
number of SMTP email recipients you wish to configure and click Next
to continue.
13. Configure email alert contacts. For each email contact it is necessary
to provide basic details, working hours, and the minimum severity of
alerts they should receive. In most cases, it is recommended that at least
one network administrator mailbox is configured to receive alerts on a
24-7 basis. If necessary, additional administrators can be added at a
later stage. Enter the required details and click Next to continue.
14. Configure Backups. Junos WebApp Secure can be configured to
perform local backups, which can be used to restore the system in the
event of a failure. In a virtualized environment, this process is normally
handled by the virtualization tools but the native features can be enabled
if desired. Select No and Next to continue.
15. Junos Spotlight Secure is a cloud-based hacker intelligence service
that allows Junos WebApp Secure customers to share information
regarding attackers who have previously attempted to breach a protected
system. This is an advanced topic outside of the scope of this Day One
book. Disable the feature and click Next to continue.
16. Complete Configuration Wizard. Once all the information has been
entered, JWAS shows the Configuration Wizard Complete Screen. This
contains two pieces of critical information that need to be recorded.
Backup Secret Key: The embedded database encrypts backups
using a randomly generated secret key. In order to restore a backup
to an alternative machine, this key needs to be recorded and stored
where it can be retrieved for this purpose.
Health Check URL: Junos WebApp Secure has a default, randomly
generated page which is designed to inform an upstream load
balancer of the server health. This page URL can be modified, but it
is worth recording this information also.
57
58
TIP
To change the Health Check URL from the default to one that is
standard across your environment, click on the text highlighted in blue
and the web interface will jump to the Security Engine configuration.
17. Final Step: Reboot the Server. Once the basic configuration has
been completed, it is tempting to start testing immediately by
redirecting traffic into the appliance. However, to ensure that all the
outstanding processes have started, it is recommended that the Virtual
Server is cleanly rebooted. Return to the VMware Console and log in
with the default Username and password. Scroll down to Quit in the
Setup Utility. Once returned to the Linux Shell, enter the command:
[mykonos@grizzly ~]$ reboot
Mon Jan 21 18:24:39 UTC 2013
This process will take a few minutes to complete dependent on your
host’s resources. You will eventually return to the Console Log in
Screen. At this point the initial setup is complete and you are ready to
proceed to the housekeeping stage.
Housekeeping
Once the initial base configuration is complete, it’s a good time to
perform some basic housekeeping of the platform before beginning
testing.
Configure SSH Access
By default Junos WebApp Secure runs a standard OpenSSH v2 server
to allow remote administration. This is useful as monitoring logs in
restricted VMWare ESXi console windows is difficult, and access to the
full shell for many administrators will be preferable. To access the SSH
shell use a standard SSH client such as OpenSSH or PuTTY and
connect to:
ssh://<IPADDRESS>:2022
…where <IPADDRESS> is the IP address of your Junos WebApp
Secure Server.
Time Checks and Network Time
In the text mode setup we configured Junos WebApp Secure to utilize
an external Network time protocol server. When deployed as a virtual
appliance, the Junos WebApp Secure guest will use the local system
time from the host server. Over time, this clock can drift and it is
recommended that an external, reliable time source is configured to
ensure that all the hosts in the environment are synchronized. While
Junos WebApp Secure to some extent plays a long game with the
attacker, it is still important to be able to correlate the logs and alerts
from more traditional security technologies such as firewalls and
Intrusion Detection and Prevention systems to provide a complete
audit trail of network events. By the time the rest of the configuration
has been completed, the time should have automatically synchronized
to the configured time sources.
To check the local time, reopen the VMware Console and sign in as the
mykonos user. Exit the Setup utility, this should return you to the
Linux shell prompt. Enter the “date” command to show the current
system date, time, and time zone.
[mykonos@grizzly ~]$ date
Mon Jan 21 16:23:19 UTC 2013
[mykonos@grizzly ~]$
In most cases the clock should automatically synchronize with the
configured time source. If for any reason the time is not synchronized,
check the connectivity to the NTP source and ensure that any required
firewalls rules are in place.
59
60
Change the Password
The Junos WebApp Secure configuration does not force the user to
change the default mykonos administrator password. Following a
security best practice, it is recommended as a matter of urgency that
the password is changed. To change the password on the appliance,
enter the text-mode setup (either by console or SSH), quit the setup
utility, and from the Unix shell prompt, enter the following:
[mykonos@grizzly ~]$ passwd
Changing password for user mykonos.
Changing password for mykonos.
(current) UNIX password: <enter existing password>
New password: <enter new password>
Retype new password: <repeat new password>
passwd: all authentication tokens updated successfully.
[mykonos@grizzly ~]$
The configuration change should be immediate and the next time you
log in to the Web interface you will be forced to enter the new mykonos
user password.
Update the System
Periodically Juniper releases new versions of the Junos WebApp Secure
appliance to provide new features and bug fixes. In most cases this is
performed using the web interface. Navigate to Updates at the bottom
of the Junos WebApp Secure dashboard and click the check for updates
button. This will attempt to check and download any outstanding
updates for the system. This process may take a while as the updates
can be very large.
Once the update has been downloaded and unpacked, click Update
Selected to install the patch.
NOTE
For the automatic updates to work correctly, the JWAS server must be
able to establish an outbound connection to the Internet. If a direct
path is not desirable, a proxy server may be specified in Console Setup
Utility under Network Configuration as discussed in section 3.2.
NOTE
During the update the target JWAS server may well be unavailable and
unable to forward traffic to backend servers. It is therefore recommended that traffic be gracefully migrated away from the server before
the update begins.
Depending on the host resources available, the update will go through
several stages and will take several minutes to complete.
Once complete, the services should automatically restart and return
the administrator to the dashboard screen.
Alternatively, the Junos Web App Secure may be updated manually
from the command line. To update the patches to an appliance, enter
the text-mode setup (either by console or SSH), quit the setup utility,
and from the Unix shell prompt enter the following:
[mykonos@grizzly ~]$ sudo mykonos-update –d
Downloading...
Downloaded: No updates found
Once the file has been downloaded, use the same command with the –l
switch and specify the location of the downloaded update.
[mykonos@grizzly ~]$ sudo mykonos-update –l /srv/updates/
mws-core-5.0.1-11.meta
415/415 - grub-0.97-77.el6.x86_64.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata
[mykonos@grizzly updates]$
61
62
Check the Log Files
The Junos WebApp Secure logs are held on the local file system of the
appliance in the /var/log/mws folder. They can be accessed via the
console or via the SSH shell using standard UNIX commands such as
tail, cat, and more.
The logs are broken down as follows:
/var/log/mws/mws.log: Contains system level events such as
engine startup and shutdown.
/var/log/mws/security-alert.log: Contains the raw log security
incidents and is useful when monitoring the appliance in realtime.
/var/log/mws/firewall.log: Contains the output from the embedded IPTABLES firewall, which drops non-HTTP traffic directed
to the appliance.
/var/log/mws/audit.log: Contains system administrator activity
such as configuration changes, profile deletions, and administrator logins.
/var/log/mws/management-access.log: Contains activity against
the JWAS Administration Dashboard web server.
/var/log/mws/proxy-error-default.log: Contains activity directed
to the JWAS port listener.
Chapter 4
Network and Application Integration
This chapter covers the actions necessary to ensure that Junos
WebApp Secure is part of a highly available solution. The need to
correctly monitor a server is discussed and the required steps are
laid out. Now that the server is operational, it is important to
tune Junos WebApp Secure in to some basics of how your web
application is configured so that it may understand certain
security elements like authentication functions.
Network and Application Integration
Junos WebApp Secure’s logical position between the user and the
backend web server means that it has to have a high level of
availability, otherwise application availability may be affected.
Chapter 2 of this book discussed network designs that can be
implemented in order to maintain a high level of fault tolerance
for Junos WebApp Secure deployment, but a key part of this is
how failures are detected by the load balancer. This chapter also
includes a walk-through on how to configure some advanced
event processors to achieve an even higher level of network
security.
64
Configuring Load-Balancer Fail-through
Depending on the network design there may be one or more Junos
WebApp Secure Servers protecting one or more back-end web server
applications. Should Junos WebApp Secure become unavailable for
any reason, it is sensible to ensure that the Load Balancer is able to
gracefully take the failed server out of service to allow the service to
continue.
This section focuses on two-non Juniper products that are often used
in successful Junos WebApp Secure deployments. The samples provided should be easily translatable into configuration templates from
other vendors.
F5 LTM Sample Configuration
To Create the Load Balancer Pool
1. Sign in to the F5 BIG-IP Configuration Utility. The management
interface is usually accessible via a separate management IP address,
and connect to:
https://<IPADDRESS>
…where <IPADDRESS> is the IP address of your F5 BIG-IP management console.
NOTE
Later versions of the F5 BIG-IP configuration utility include Wizards,
which streamlines the process of setting up a new Virtual Server and a
Local Traffic Pool; for the sake of transparency, however, the manual
process is detailed below.
2. Open up the Local Traffic Menu on the left-hand side and Select the
Pools menu. Click the Create button to create a new pool from
scratch.
Chapter 4: Network and Application Integration
3. Name the Pool so that it can easily be referenced. At this stage no
health monitors are required. For the initial configuration select the
Round Robin load balancing method and ensure that the Priority Group
Activation is set to a value of at least 1. If the target nodes are already
defined in your load balancer configuration you may select them and the
service ports. Alternatively, add each node (both backend server and
Junos WebApp Secure Servers). For fail-through to work correctly, the
Junos WebApp Secure Servers should be given a higher priority than the
backend servers, ensuring that traffic will only be directed to backend
servers if a Junos WebApp Secure Server is unavailable. Click Finished
when all the member servers have been added.
65
66
4. Once the Pool has been created it should show a blue square to
show that service has been enabled but that the status is unknown.
This is because you have not enabled any Pool-level service checks,
yet.
5. Click on the newly created Pool and select the Advanced drop-down
dialog box. This should reveal some additional configuration settings.
By default, the Action on Service down is set to None and this must be
changed to Reselect to force the Pool to immediately select a new
target in the event of a server becoming unavailable.
6. Navigate to Local Traffic, and then Nodes, to see the automatically
created nodes.
7. It is recommended that the name fields are populated with the server
host names as they are visible in several other parts of the
configuration.
To Create a Custom Health Check
In order to properly monitor the Junos WebApp Secure Server, direct
health monitoring is necessary. To this end a special health check URL
is created, which a healthy Junos WebApp Secure will respond to with
a standard HTTP 200 OK message. Any other response indicates some
sort of problem and the node should be removed from the pool. This
URL is created automatically at the completion of the setup Wizard as
detailed in the last chapter. More sophisticated tests that monitor
67
68
metrics such as CPU load are possible, but are outside the scope of this
book.
1. In the F5 BIG-IP Configuration Editor navigate to Local Traffic and
then Monitors. It will show a list of existing and default service
monitors. Click the Create button to create a new Monitor.
2. Name the new Monitor something easily identifiable, such as
Mykonos_Status_Check, and select the type as HTTP. The default
check interval and Timeout should be acceptable in the first instance
and can be easily modified later.
3. By default, the HTTP status health check will send a simple HTTP
GET request to the target server, which will be enough to confirm that
the HTTP server is functioning, but not whether the Junos WebApp
Secure components are healthy. By requesting the Health Check URL,
the quality of the test is improved. Edit the Send String to include the
following:
GET /<HEALTHCHECKURL> HTTP/1.1 \r\nHost: 172.16.10.150\r\
nConnection: Close\r\n\r\n
...
Where <HEALTHCHECKURL> is the health check string captured during the
initial configuration, replace the IP address with either the host name
or the IP address of the Junos WebApp Secure Server.
In the Receive String Box enter the following: 200
This is to inform the test that that a standard HTTP 200 OK message is
an indication that the appliance is healthy.
Click the Finished button to save the Health Check.
NOTEThe Send String sequence is entered as a single string but is in effect
several commands entered in sequence. The HTTP service monitor
emulates a web browser and enters the commands required to establish
a basic HTTP session, request the Health Check URL, and close the
session cleanly. The \r\n sequences in the send string are special
characters that emulate a Carriage Return (CR), and Line Feed (LF),
69
70
respectively. When the session is reconstructed from a packet capture
taken from the load balancer, the actual sequence appears as a HTTP
request and HTTP response. The client request (from the load balancer) is shown in red text while the server response (the Junos WebApp
Secure Server) is shown in blue.
4. This should create an F5 TMOS configuration similar to the
following (reproduced from the F5 iRule Editor for clarity).
To Attach Health Checks to Pool Members
The example pool My_First_MWS contains a Junos WebApp Secure
Server and a Back-end Pool Member. Binding the JWAS health check to
the entire pool would permanently mark the backend server as down,
as it would respond with a standard HTTP 404 error. As a result, it is
necessary to bind the JWAS custom test directly to the Pool Member
and a standard HTTP test to the real backend server.
1. Navigate to Local Traffic, and then, Pools. Select the Pool
previously created and select the Members tab. This should show the
Current Members with a status of (Unknown) Enabled. Click on the
address of the member running Junos WebApp Secure.
2. Click on the Configuration drop-down box and Select Advanced to
reveal additional configuration options.
3. Under Health Monitors select Member Specific. This will allow the
selection and the activation of the Mykonos_Status_Check monitor
created in the earlier step. Select Update to return to the previous page.
71
72
4. Select the backend Pool Member server. Select the Advanced Option
under Configuration and select the Member Specific option under
Health Monitors. Add the HTTP monitor to the Active monitors list.
This will perform a standard HTTP check against only the backend
server. Click Update to return to the previous menu.
5. Repeat the process with all Junos WebApp Secure Server and
backend server nodes, making sure that the appropriate health
monitor is selected.
6. This should produce a config similar to the one shown here. Notice
the monitor Mykonos_Status_Check attached to the JWAS member.
To Create the Virtual Server
An F5 BIG-IP Virtual Server is the Virtual IP address and port listener
that takes inbound connections and redistributes them to the pool
created in the previous steps.
1. Navigate to Local Traffic and Virtual Servers and Select Create to
add a new Virtual Server.
2. Name the Virtual Server something memorable. Enter the IP address
and service port for the Virtual Server to which inbound connections
will be directed. Scroll down to HTTP Profile and select the http-wanoptimized-compressed profile.
NOTE
This profile should be compatible with most web applications, but
depending on your configuration further tuning may be required.
73
74
3. Scroll Down to Default Pool in the Resources section and select the
Pool created in the previous steps from the drop-down list. Click
Finished when the configuration is complete.
4. The newly created Virtual Server should appear in the Virtual Server
list. The status is likely to be Enabled (Unknown) as there are no
Virtual-Server level monitors enabled.
5. Click on the newly created Virtual Server and then the Members
tab. This should show all enabled members within the Pool and their
current status. All being well, they should have a Green health status.
6. Return to the Virtual Servers, the list should show the newly created
Virtual Server; if at least one of the Pool members is functioning it
should have a status of Available (Enabled).
7. Open up a web Browser and attempt to connect to the address of
the Virtual Server. If everything is working correctly the default page
of the web application should be displayed.
8. In the F5 BIG-IP Configuration Utility, click on Local Traffic and
then Virtual Servers. Select the newly created Virtual Server and then
the Statistics Tab and it will show basic I/O statistics on the Virtual
Server and associated Pool Members.
9. The process should create a configuration similar to what is shown
here, clearly showing the binding of the Virtual Address to the Pool
and the associated connection profiles.
75
76
Riverbed Traffic Manager Sample Configuration
To Create a New Service
1. Sign in to the Riverbed Traffic Manager Web Interface.
2. Click on Manage a new service to start the Wizard.
3. The Wizard should start in a new Window. Click Next to continue.
4. Name the service something memorable and select the protocol and
port. In this case, the standard HTTP protocol and port 80 is assumed.
77
78
5. Add only the Junos WebApp Secure Pool members to the list of
back-end nodes (Riverbed terminology) and include the service port.
The back-end application servers will be added in a later step.
6. Review your changes and click on Finish to commit the
configuration.
7. Now, navigate to the Services tab and then the Pool tab. Create a
second Pool for the backend servers. This will be used for failover in
the event the primary Pool becomes unavailable. It is recommended
that a HTTP Monitor is selected. Click Create Pool to complete the
step.
8. The GUI should update with the properties screen of the newly
created Pool. From here it is possible to select additional settings for
the Pool. At a minimum, the notes field should be populated to
describe the Pool correctly.
79
80
9. Return to the Pool tab by selecting Services and then Pools, and it
should show at least two Pools: one for the Junos WebApp Secure
Servers and the newly created Pool of backend servers.
10. Click on the first Pool initially created for the Junos WebApp
Secure Servers. In the Failure Pool drop-down list, select the Pool
containing the backend servers in the previous step. In the event of a
failure of all the servers in the first Pool, the load balancer will fail
through the traffic to the backend servers in the secondary Pool. If not
already set, the notes field should also be populated with a Pool
description. Click Update to commit the changes to the configuration.
To Create a Custom Monitor
In order to properly monitor the Junos WebApp Secure Server, direct
health monitoring is necessary, so a special health check URL is
created, which a healthy Junos WebApp Secure Server will respond to
with a standard HTTP 200 OK message. Any other response indicates
some sort of problem and the node should be removed from the Pool.
This URL is created automatically at the completion of the set up
Wizard, detailed in Chapter 3.
NOTE
More sophisticated tests are available to monitor metrics such as CPU
load, but those are outside the scope of this Day One book.
1. Navigate to the Junos WebApp Secure Server Pool by selecting the
Services/Pools tabs, and then the Pool created for Junos WebApp
Secure Servers. Scroll down to the Health Monitoring section and click
Edit. Select the Manage Monitors in Catalog (sic) button to see all
available monitors.
2. Scroll down to the bottom of the window to the Create new monitor
section. Name the monitor Mykonos_Status_Check and specify the
type as HTTP monitor. Click the Create Monitor button to add it to
the catalog and edit the advanced properties.
81
82
3. Adjust the delay, timeout, and failures settings as required for your
configuration. Fewer monitor calls will reduce the load on the backend
servers, but will also increase the time taken to identify a failure. It is
recommended that during the initial deployment/testing phase of a
Junos WebApp Secure deployment that verbose logging is enabled on
the test to make troubleshooting easier. For a production environment,
this setting may initially be disabled, and then re-enabled should an
issue occur. Otherwise a significant amount of logs will be generated.
4. Scroll down to the Additional Settings menu and populate the
host_header: section with either the host name or the IP address of the
target Junos WebApp Secure Servers. The path: field must be
populated with the health check URL captured at the end of the initial
Web Interface configuration in Chapter 3.
5. In the status_regex: section enter 200 as this is the only valid healthy
response from the Junos WebApp Secure Server. Scroll down to the
note: field and provide a short description of the health check. Click
on Update when complete.
To Attach a Custom Monitor to the Pool
1. Return to the Monitors menu for the Junos WebApp Secure Pool by
selecting Services, then Pools, and then select the Pool created for the
Junos WebApp Secure Servers. Scroll down to the Health Monitoring
section and click Edit. Select the Mykonos_Status_Check from the
Add monitor drop-down list and click the Add Monitor button to
attach it to the Pool.
2. It is likely that the Stingray Traffic Manager will have automatically
enabled a Ping health monitor. This only tests connectivity to the
server up to Layer 3 of the IP stack and does not provide any benefit
over the full Layer 7 test created previously. As a result, in most
circumstances, this Ping health monitor can be removed.
83
84
To Confirm Health Monitoring
Once the servers have been configured, it is worth checking to see that
host monitoring is behaving as expected.
1. Navigate to the Diagnose tab, and then the Cluster Diagnosis sub
tab. Any issues discovered should be highlighted under the
Configuration: Virtual Servers and Configuration: Pools sections.
2. Click on the Event Log tab. If verbose logging is enabled a complete
trace should be shown of the mykonos_status_check requests and
responses, along with any other health checks logged.
3. It is recommended that basic testing is completed to ensure that the
load balancer fail-through is working correctly. The web-page should
load normally. The Traffic Manager web interface should show that
the Default Pool is running and healthy.
4. Disconnect the Junos WebApp Secure Web server from the network
and attempt to connect the Virtual Server address. The web-page
should load normally. The Traffic Manager web interface should show
that the Default Pool has been disabled and the secondary pool is
processing traffic.
85
86
Configuring Event Processors
Event processors are software modules used by Junos WebApp Secure
to analyze inbound HTTP traffic looking for malicious activity. They
may be configured either on a global or per-application basis. Processers can trigger an automatic response from the Junos WebApp Secure
Server. For example, the Hidden Link processor may be triggered if a
connecting client attempts to spider the protected web site looking for
directories that are not linked to any public content. This may directly
trigger an automatic response to either slow or block the connection.
The default event processors provide a good level of protection “out of
the box” but some very useful protection tools require further configuration. In this section you’ll configure some basic event processers.
Login Processor
The login processor is designed to protect web applications from brute
force attacks against embedded authentication mechanisms, a feature
especially useful for protecting applications that either have very basic
or no protection at all against authentication abuse. The Login processor is enabled by default, but to be truly effective, Junos WebApp
Secure needs some basic elements configured to understand how a user
authenticates to the application.
To Configure the Login Processor
In this example, a simple WordPress administration console will be
protected by the Junos WebApp Secure Server. The precise details for
each web application deployed will vary, but this example should
provide you with a basis for understanding the process required to
configure a web application.
1. Log in to the Junos WebApp Secure Console.
2. Navigate to Processors under Basic Mode Configuration. This will
display a list of the processors currently deployed on the Junos
WebApp Secure Server and their current status. Scroll down to the
Login Processor and select it.
3. In most cases, the default options for the login processor are fine,
but there some settings such as the Captcha Expiration, which may
require adjusting depending on the outcome of your usability testing.
87
88
4. Scroll down to the bottom of the window. All currently protected
Login pages will be listed. Assuming this is a fresh installation, there
will be none. Click on the Add button to protect a specific login page.
5. A new screen will prompt you for the settings, and in most
circumstances, these need to be discovered directly from the target
application. Name the application something easily identifiable.
Depending on the application, there may be multiple login pages for
users and administrators. Use a separate row for each distinct page.
6. The URL Pattern is essentially the login page you wish to protect,
and in the URL Pattern field enter a regular expression to describe the
page you wish to protect. The topic of regular expressions (RegEx) is
outside the scope of this Day One book, but examples are provided
that should suit most needs. Using a RegEx is necessary as it allows
Junos WebApp Secure to identify a URL for protection without
necessarily providing an exact match. Links to resources on RegEx are
provided in the appendices. The simplest way to find the URL is to
open a web browser, connect to the page you wish to protect, and copy
and paste the URL into a text editor.
For example, the default WordPress administration page on the
protected server Rupert is accessible using the following URL:
http://rupert/wordpress/wp-login.php
One is only interested in matching everything after the protocol and
host portions of the string, as the connection may be forwarded from a
load balancer, and it is of no interest of how the connection reached the
Junos WebApp Secure Server. By replacing the http://rupert portion
with a regular expression [^?]* we can match any string other than
one containing a question mark. The resulting match string is:
[^?]*/wordpress/wp-login.php
To make sure that specific instance of the php file is captured (and not a
randomly generated one) it is necessary to capture the period. This is
achieved using a single [.] statement which changes the match string
to:
[^?]*/wordpress/wp-login[.]php
It is also necessary to ensure that any attempt to pass variables to the
php pages are captured as well. The RegEx matches on the php
extension followed by a question mark and then any other text. This
provides the final RegEx of:
[^?]*/wordpress/wp-login[.]php([?].*)?
This can be pasted into the Junos WebApp Secure configuration,
providing a reasonably specific match against the WordPress administration login page. It does not, however, cater to capitalization mistakes, which the web server may honor and process. For example, a
connection containing the following string will be matched and
inspected by the Login processor:
http://rupert/wordpress/wp-login.php
But this URL would not be matched by the Login processor:
http://rupert/WordPress/wp-login.php
And it will be passed to the backend server. All other Application
processors will still be active, but if the backend server responds with a
login page, then Junos WebApp Secure will not attempt to intercept
brute-force and other login attacks.
NOTE
Clearly there is a balance to be struck in terms of resolution of the
RegEx versus the ongoing usability of the solution versus a more
traditional web application firewall. In the context of this Application
processor, too fine a RegEx may be broken and ineffective if the
application itself changes significantly.
89
90
7. The next stages require detailed information about the application
itself. While it is possible the application developer may be on hand to
provide this information, in practice, it is often more reliable to reverse
engineer the required settings directly from the application itself.
Navigate to the login page of the application to be protected, here
WordPress.
8. The next stage is to view the source of the Web application as it was
presented to the end user. The procedure differs slightly between web
browsers, but in most cases it is easy to find. For example:
Google Chrome: Right click in the browser window and select
View page source
Microsoft Internet Explorer: Right click in the browser window
and select View source
Mozilla Firefox: Right click in the browser window and select
View page source
This will typically open a new window that contains the HTML stream
sent by the Web server to the web browser.
9. Use the search function to find the string method= . This is the
HTTP method used to submit captured credentials to the backend
server. The post method is often used for web applications, including
WordPress. Make a note of the method used by the application and
enter it into the Junos WebApp Secure Protected Login Pages screen.
10. While still within the page source window, search for the username
field. The easiest way to do this is to search for the text label displayed
on the Web page (i.e., Username). Immediately adjacent to this should
be the definition for the input field used to capture the user name. In
the case of WordPress, the <label>Username is adjacent to an input
91
92
field named log with an id of “user_login”. Often the input field is
named something simple, such as Username or User. Make a note of
user name input field and enter it into the Junos WebApp Secure
Protected Login Pages screen.
11. The Username field Pattern value is a regular expression used to
match input fields with the username fields. If the web application has
a specific format for usernames such as j.smith or jane.doe@foo.com
then it is possible to create a RegEx, which will match and reject
incorrectly formatted username entries. In most cases a simple
catchall will be sufficient.
Enter ^.*$ to accept all input in the username field as valid.
12. The supported Username Field Encoding values are ASCII,
Base64, and Hexadecimal. In the vast majority of cases the encoding
type will be ASCII.
13. Password Field type in most cases will match that of the Username
field type, which in this case is Post Parameter.
14. Return to the page source window and search for the password
input field. It is usually located directly after the username field. In the
WordPress example the field is named pwd, but in many cases it is
simply named Password. Make a note of the password input field and
enter it into the Junos WebApp Secure Protected Login Pages screen.
15. The Password Field Value Pattern field describes valid text that
can be entered as a password. If the application has password
complexity requirements it may be possible to create a RegEx which
can filter out improperly formatted passwords. Otherwise, enter ^.*$
to accept all input as valid in the password field.
16. The Password field encoding value may be set to either ASCII,
Base64, or Hexadecimal. In the majority of cases this will also match
the username field encoding of ASCII.
17. To allow Junos WebApp Secure to detect the outcome of an
authentication request, it is necessary to provide examples of both a
success and a failure. Depending on the complexity of the application,
it may be possible to determine this from the headers but in most cases
it is easy enough to pull this from the body text. Select Body text
under Failure Pattern type.
18. Open a web browser to the protected web application and
deliberately enter an invalid password with a valid username. Some
applications will return a different error when an invalid username is
entered. Copy and paste a suitable text string containing the error
message into the Failure Pattern field. For example:
The password you entered for the username
19. The Failure Pattern Condition field determines whether Junos
WebApp Secure should consider a match on this preceding field an
indication of success or failure. In most cases, and for the sake of
simplicity, this should be set to Failure on Match.
20. The Success Pattern Target field indicates to Junos WebApp Secure
where to look for evidence of a successful authentication. In most
cases this will match the Failure Pattern Target and be set to Body.
21. The Success Pattern is the string used to identify a successful
authentication. This may be as simple as Login Accepted but in the
case of our WordPress example, we can choose a string that only
appears on the administration page. Enter this string into the
Protected login pages Success Pattern field.
93
94
22. The Success Pattern Condition should be set according to whether
you wish the log in to be considered successful if the preceding value
does or does not appear. In the example, the Success on Match setting
will consider the authentication successful if the string Dashboard is
found in the body text.
23. The Require Captcha After setting allows the administrator to
specify how many failed authentication attempts will be tolerated
before the forced Captcha is initiated. This setting may be influenced
by the strength of password complexity requirements on the back-end
application, but in most cases a setting of 4 will provide a good
balance between security and usability.
Settings in Detail
Name:
Wordpress Login
URL Pattern:
[^?]*/wordpress/wp-login[.]php([?].*)?
Username Field Type:
Post Parameter
Username Field Name Pattern:
log
Username Value Pattern:
^.*$
Username Field Encoding:
Ascii
Password Field Type:
Post Parameter
Password Field Name Pattern:
pwd
24. Click the Save button to commit the configuration to the Junos
WebApp Secure Server.
Settings in Detail (continued)
Password Field Value Pattern:
^.*$
Password Field Encoding:
Ascii
Failure Pattern Target:
Body
Failure Pattern:
The password you entered for the username
Failure Pattern Condition:
Failure on Match
Success Pattern Target:
Body
Success Pattern:
Dashboard
Success Pattern Condition:
Success on Match
Require Captcha After:
4
95
96
Testing the Login Processor
1. Open up a web browser and connect to the administration page of
the Junos WebApp Secure protected application. For this testing it is
recommend that the computer used for administering and configuring
Junos WebApp Secure is not used. Attempt to log in numerous times
with invalid passwords but with a valid username.
2. After several invalid attempts, the Junos WebApp Secure Server
should start to take over the session and inject the Captcha processor
in the http stream.
3. Successfully solve the Captcha puzzle and the connection should be
returned to the login page. Repeated attempts will be flagged on the
Junos WebApp Secure Console.
4. Open the Junos WebApp Secure console. Navigate to Incidents and
click on the Most Recent tab. The unsuccessful Site Login Invalid
should be recorded and the attacking client should be recorded as a
detected hacker.
5. Click on the Site Login Invalid incident to get more detail. This
should show the URL that was attacked and the last time first and last
time it was observed.
6. Click on the name of the Attacker at the top of the incident to see all
the incidents associated with this profile. The Responses tab will show
the counter-responses that have been deployed. This should list Break
97
98
authentication (Captcha). It is also possible to manually deploy
counter-measures from this screen by clicking the Activate New
Counter Response button and making a selection from the list.
NOTE
The Cloppy counter-measure is a humorous web pop-up designed to
goad the hacker into doing a better job of attacking the target. However, the use of the Cloppy response makes it apparent that the server is
being protected by an advanced Web application security technology
or a competent system administrator. In either case, this defeats the
goal of Junos WebApp Secure: to actively waste the time and resources
of a potential attacker. The appearance of the Cloppy counter-measure
within the session may make the attacker immediately abandon the
attempt or perhaps start to look for vulnerabilities in the Junos
WebApp Secure system itself.
Application Vulnerability Protection Processor
Junos WebApp Secure includes additional protections for certain
applications. Presently this includes protection for attacks against:
Joomla
PHPBB
WordPress
These protections need to be individually enabled on a per-application
basis and offer some minor configuration options.
Configuring Application Vulnerability Protection
1. To access the Application Vulnerability processor select Processors
under Configuration and click Edit Settings next to Application
Vulnerability Protection section.
2. Click on the appropriate drop-down box for the application you
wish to protect. All applications will be disabled by default. In this
case the WordPress application protection will be enabled. Change the
value to Yes and then select Save to commit the configuration.
99
100
3. Under some circumstances it may be required to just alert on attacks
against the application rather than actively blocking. To achieve this
click on the current Mode of Operation value. In the drop-down box
select Block the request and create an incident. Click Save to commit
the change.

Day One Deploying Junos WebApp Secure

Transcription

Similar documents

February 2016 Growth Spurts

JOHN JAY COLLEGE OF CRIMINAL JUSTICE THE CITY

4th of July Pancake Breakfast Friday Film Nights in the Park

Park and Fly

or more - Zagers Pool and Spa

Juniper Networks M-series : Product Overview

Manual - Backyard Pool Superstore

SCCSC Building Project 2015

to see the schedule