WEBVTT
00:00:01.100 --> 00:00:01.960
Hello.
00:00:01.960 --> 00:00:04.645
Welcome to Microsoft Build 2017.
00:00:04.645 --> 00:00:07.140
My name is Amit Srivastava.
00:00:07.140 --> 00:00:09.150
I'm a program manager
with Azure Networking.
00:00:10.230 --> 00:00:13.140
Today, I'm going to talk
about how to secure your web
00:00:13.140 --> 00:00:16.440
applications using
Application Gateways,
00:00:16.440 --> 00:00:18.400
Web Application Firewall or WAF.
00:00:20.100 --> 00:00:23.740
I'll be talking about WAF's
features, capabilities,
00:00:23.740 --> 00:00:28.310
logging analytics, integration
with Azure Security Center and
00:00:28.310 --> 00:00:29.330
I'll also do a demo.
00:00:30.360 --> 00:00:34.630
Before starting with
Azure Application Gateway, well
00:00:34.630 --> 00:00:37.650
Application Firewall, I wanted
to talk a little bit about
00:00:37.650 --> 00:00:40.190
Application Gateway and
its capabilities.
00:00:41.490 --> 00:00:45.830
So Application Gateway
is less 7 load balancer.
00:00:45.830 --> 00:00:48.390
It performs as application
delivery controller as
00:00:48.390 --> 00:00:49.360
a service in Azure.
00:00:51.220 --> 00:00:57.223
We launched in June 2015
with SSL offload and
00:00:57.223 --> 00:01:01.760
Cookie based session infinity
as the key scenarios.
00:01:01.760 --> 00:01:06.580
Since then, we have added quite
a lot of functionality including
00:01:06.580 --> 00:01:10.970
SSL policy where you can
control your protocol versions.
00:01:10.970 --> 00:01:15.718
You can for example say
allow TLS 1.1 or 1.2 and
00:01:15.718 --> 00:01:17.838
delay TLS 1.0.
00:01:17.838 --> 00:01:21.980
You can also do end-to-end
SSL re-encryption.
00:01:21.980 --> 00:01:23.720
If you don't want your
communication from
00:01:23.720 --> 00:01:25.985
Application Gateway to
the back end or http.
00:01:27.430 --> 00:01:30.820
You can protect
up to 20 websites
00:01:30.820 --> 00:01:32.980
behind a single
Application Gateway.
00:01:32.980 --> 00:01:35.050
You can have a different
back-end pools and
00:01:35.050 --> 00:01:36.890
sell 20 websites
at the same time.
00:01:36.890 --> 00:01:38.300
If you have enabled WAF,
00:01:38.300 --> 00:01:40.400
you can protect up to 20
websites at the same time.
00:01:41.480 --> 00:01:43.970
You can also do
content based routing.
00:01:43.970 --> 00:01:48.150
For example here, I'm showing
video and images going to their
00:01:48.150 --> 00:01:51.860
own back-end pulse, and you can
scale these pulse independently.
00:01:51.860 --> 00:01:56.110
So you can have bigger boxes
on the video, and smaller
00:01:56.110 --> 00:01:59.210
on the images for example or
static text and scale them.
00:02:00.470 --> 00:02:03.760
You can also do web
socket support.
00:02:03.760 --> 00:02:05.640
You can have,
00:02:05.640 --> 00:02:09.650
we also provide rich diagnostics
with Application Gateway.
00:02:09.650 --> 00:02:10.530
So for example,
00:02:10.530 --> 00:02:15.430
we provide access logs, which is
an account of every request and
00:02:15.430 --> 00:02:18.240
response which received
by Application Gateway.
00:02:18.240 --> 00:02:22.220
It shows the total number of
bytes sent in, bytes sent out,
00:02:23.400 --> 00:02:28.870
the client IP, other data
like latency, and URI port.
00:02:29.990 --> 00:02:33.080
So that's great for knowing
what is application gateway
00:02:33.080 --> 00:02:34.910
receiving and
how it's responding.
00:02:34.910 --> 00:02:37.990
We also have performance
logs which show the details
00:02:37.990 --> 00:02:40.710
on application gateway
instances themselves.
00:02:40.710 --> 00:02:44.048
So you can look at how many
requests are being served,
00:02:44.048 --> 00:02:48.550
what is their average
throughput, average latency.
00:02:48.550 --> 00:02:51.017
What is the number of back-end
healths which are healthy or
00:02:51.017 --> 00:02:53.100
the number of back-ends,
which are unhealthy?
00:02:54.260 --> 00:02:58.100
We also provide a real-time
back-end health API.
00:02:58.100 --> 00:03:00.840
So by default, when
application gateway comes up,
00:03:00.840 --> 00:03:03.890
it probes every back-end
at a fixed interval.
00:03:03.890 --> 00:03:06.145
You can customize them
using custom probes, and
00:03:06.145 --> 00:03:10.320
using back-end health API, you
can get real time information on
00:03:10.320 --> 00:03:11.911
which of the back-ends
are healthy.
00:03:13.070 --> 00:03:15.950
Now given the central
place where we do
00:03:15.950 --> 00:03:19.280
certificate management and
SSL policies,
00:03:19.280 --> 00:03:23.600
it made sense for us to enhance
our security portfolio and
00:03:23.600 --> 00:03:27.114
provide you with a web
application firewall.
00:03:27.114 --> 00:03:28.300
So lets go into that.
00:03:29.360 --> 00:03:33.440
Web applications are increasing
becoming targets of
00:03:33.440 --> 00:03:38.020
very sophisticated exploits
which target layer 7 application
00:03:38.020 --> 00:03:39.830
vulnerabilities.
00:03:39.830 --> 00:03:42.260
These attacks are becoming
more and more prevalent.
00:03:43.620 --> 00:03:47.130
OWASP the Open Web
Application Security Project
00:03:47.130 --> 00:03:50.640
publishes a list of top
ten vulnerabilities.
00:03:50.640 --> 00:03:53.860
These include vulnerabilities
like SQL injection,
00:03:53.860 --> 00:03:56.155
cross site scripting,
to name a few.
00:03:58.745 --> 00:04:01.165
If application developers
want to prevent these
00:04:01.165 --> 00:04:05.215
vulnerabilities, they have to
be very diligent in their code,
00:04:05.215 --> 00:04:09.227
they have to have very
strict reviews, and
00:04:09.227 --> 00:04:12.755
not every application
undergoes such a process.
00:04:13.870 --> 00:04:16.650
Therefore, having a web
application firewalls sitting in
00:04:16.650 --> 00:04:19.110
front of these applications
00:04:19.110 --> 00:04:22.390
greatly enhances the security
profile of that application.
00:04:23.480 --> 00:04:27.190
Now, many of these profile
are inherently difficult.
00:04:27.190 --> 00:04:29.630
These vast solutions
are difficult to configure and
00:04:29.630 --> 00:04:30.662
maintained.
00:04:30.662 --> 00:04:34.480
More over our customers will
want a single unified API.
00:04:35.640 --> 00:04:37.410
Which they are familiar with,
and
00:04:37.410 --> 00:04:40.670
they don't want to go
into another solution and
00:04:40.670 --> 00:04:44.610
have another configuration,
another way of looking at logs,
00:04:44.610 --> 00:04:48.240
another way of hooking with
monitoring and alerts.
00:04:48.240 --> 00:04:51.870
They want a platform provided,
uniform solution.
00:04:51.870 --> 00:04:55.550
Which is at the same time simple
to configure and operate.
00:04:55.550 --> 00:04:58.640
Keeping that in mind,
web application firewall
00:04:58.640 --> 00:05:02.520
was launched from
application gateway site.
00:05:02.520 --> 00:05:06.758
We declared preview
giving last ignite, and
00:05:06.758 --> 00:05:10.448
we declared date
in March of 2017.
00:05:10.448 --> 00:05:13.959
It's now generally available,
and therefore, everyone to use.
00:05:15.620 --> 00:05:19.080
Web Application Firewall
is offered as a new skew
00:05:19.080 --> 00:05:20.690
in application gateway,
called WAF.
00:05:22.230 --> 00:05:25.350
With Web Application Firewall,
or WAF's, cue you get
00:05:25.350 --> 00:05:28.620
all the features which I've
described in an earlier slide,
00:05:29.670 --> 00:05:33.740
which is part of the standard
skew and you get WAF capability.
00:05:34.870 --> 00:05:38.350
Now, Web Application Firewall
is built
00:05:38.350 --> 00:05:40.890
using core rule sets
from ModSecurity.
00:05:41.960 --> 00:05:44.166
When they launched in preview,
00:05:44.166 --> 00:05:46.949
we supported core
rule set 2.2.9.
00:05:46.949 --> 00:05:51.830
Today, we support core rule
set 2.2.9 as well as 3.0.
00:05:51.830 --> 00:05:55.590
Now ModSecurity Core Rule Set
is one of the most popular web
00:05:55.590 --> 00:06:01.240
deployments and has a lot of
community adoption and support.
00:06:01.240 --> 00:06:04.860
That is one of the reasons we
chose to go with ModSecurity
00:06:04.860 --> 00:06:05.985
as the default this time.
00:06:05.985 --> 00:06:11.140
With, it comes preconfigured
when you create
00:06:11.140 --> 00:06:14.640
the Application Gateway Valve,
with just the click of a button
00:06:14.640 --> 00:06:18.610
you can provide protection
from most of the common
00:06:18.610 --> 00:06:22.230
vulnerabilities like SQL
injection, protocol violation,
00:06:22.230 --> 00:06:28.210
cross site scripting,
local file inclusions and so on.
00:06:28.210 --> 00:06:32.740
I'll cover in detail these
protections in a later slide.
00:06:32.740 --> 00:06:35.250
Now, this illusion is part
of Application Gateway.
00:06:35.250 --> 00:06:37.010
It is fully managed by Azure and
00:06:37.010 --> 00:06:39.650
you can use your
same familiar APIs.
00:06:39.650 --> 00:06:43.880
Today we allow you to create
Application Gateway Firewall
00:06:43.880 --> 00:06:46.650
using our portal,
the Azure portal.
00:06:46.650 --> 00:06:51.426
You can use CLI, Powershell,
SDK, whatever it is your choice
00:06:51.426 --> 00:06:55.072
or you could use ARM
templates for that matter.
00:06:55.072 --> 00:06:59.210
It is available only in
the Azure resource manager skew.
00:07:00.760 --> 00:07:04.710
And you can enable the WAF
solution, essentially you choose
00:07:04.710 --> 00:07:08.510
two modes either a prevention or
a detection mode.
00:07:09.680 --> 00:07:13.500
As the name suggests,
detection mode just monitors
00:07:13.500 --> 00:07:18.020
your web application traffic,
it does not stop the attack.
00:07:18.020 --> 00:07:20.830
This is good for you to monitor
your web application and
00:07:20.830 --> 00:07:23.800
see what kind of exploit
pattern it's getting.
00:07:23.800 --> 00:07:25.820
If it is seeing any attacks, or
00:07:25.820 --> 00:07:28.130
if it is seeing any
malicious traffic.
00:07:28.130 --> 00:07:32.330
Once you identify such
a traffic, you can always go and
00:07:32.330 --> 00:07:35.330
change it from detection
to prevention mode,
00:07:35.330 --> 00:07:38.328
in which case it actually
starts blocking the traffic.
00:07:38.328 --> 00:07:43.523
A user or an attacker who is
trying to send a malicious
00:07:43.523 --> 00:07:48.955
traffic autobot will get a 4
to 3 forbidden access and
00:07:48.955 --> 00:07:54.181
that connection would be
terminate in prevention.
00:07:54.181 --> 00:07:56.574
Now, of key requirement for
00:07:56.574 --> 00:08:01.161
any WAF solution is to allow
the user to eliminate false
00:08:01.161 --> 00:08:05.162
positives by allowing
rule configurability.
00:08:05.162 --> 00:08:08.915
G, we have also added options
for users to enable and
00:08:08.915 --> 00:08:13.710
disable individual rules or rule
sets, I'll cover that as well.
00:08:13.710 --> 00:08:18.650
Another key requirement is for
the application developer or
00:08:18.650 --> 00:08:22.770
administrator to be
fully aware of what
00:08:24.120 --> 00:08:27.880
exploits he is seeing at
any given point of time.
00:08:27.880 --> 00:08:30.520
Therefore, monitoring
becomes a key requirement.
00:08:31.586 --> 00:08:37.045
Azure Graph integrates
directly with Azure monitor
00:08:37.045 --> 00:08:43.247
which is a uniform way of all
Azure resources who send data,
00:08:43.247 --> 00:08:47.354
log data, and
integrate with alerts.
00:08:47.354 --> 00:08:49.970
WAF also integrates with
Azure Security Center.
00:08:49.970 --> 00:08:53.210
I'll cover that in
the next slide as well.
00:08:54.960 --> 00:08:58.800
So as I was saying
that at preview time,
00:08:58.800 --> 00:09:04.111
we allowed only one rules of
schema which was CRS 2.2.9.
00:09:04.111 --> 00:09:07.980
Now, we have added CRS
3.0 to support as well.
00:09:07.980 --> 00:09:12.920
CRS 3 offers new
addition of rules and
00:09:12.920 --> 00:09:15.970
greatly reduces
the total false positives
00:09:15.970 --> 00:09:20.060
which an application sees,
and therefore we, by default,
00:09:20.060 --> 00:09:23.400
are start with 3.0 and
if the user wishes,
00:09:23.400 --> 00:09:28.990
they can always switch from
3.0 to 2.2.9 or vice versa.
00:09:28.990 --> 00:09:31.970
You can use with just
a click of a button,
00:09:31.970 --> 00:09:35.196
with just your same
provisioning APIs.
00:09:35.196 --> 00:09:39.879
Out of Box you get preventions
protection from SQL injection,
00:09:39.879 --> 00:09:44.648
cross site scripting, we also
provide the HTTP rate limiting,
00:09:44.648 --> 00:09:48.888
we protect you from fixation,
local filing inclusion or
00:09:48.888 --> 00:09:52.920
remote filing inclusion and
protocol violations.
00:09:52.920 --> 00:09:55.736
So that's extremely powerful.
00:09:55.736 --> 00:09:59.318
Without doing any kind of
configuration you straight away
00:09:59.318 --> 00:10:01.081
get protection from these.
00:10:01.081 --> 00:10:03.833
API's from these attacks.
00:10:03.833 --> 00:10:05.910
And you can always come and
00:10:05.910 --> 00:10:10.736
choose which rules you want to
enable for your application.
00:10:10.736 --> 00:10:13.409
You can choose whether you
want to be in prevention, or
00:10:13.409 --> 00:10:15.922
detection mode, and
switch between them as well.
00:10:18.290 --> 00:10:22.312
Now as I mentioned that to
eliminate false positives,
00:10:22.312 --> 00:10:26.160
one of the key requirements
which we took care of from
00:10:26.160 --> 00:10:30.279
preview to GA time was
allowing rule configurability.
00:10:30.279 --> 00:10:34.582
So, you can see that a RuleSet
like CRS 2.2.9 is composed
00:10:34.582 --> 00:10:39.385
of various broad rule groups for
example, cross-site scripting,
00:10:39.385 --> 00:10:42.386
SQL injection, or
protocol violations.
00:10:42.386 --> 00:10:47.194
And each of these rule groups
is in itself composed of
00:10:47.194 --> 00:10:49.391
many different rules.
00:10:49.391 --> 00:10:51.145
There are probably 30 or
00:10:51.145 --> 00:10:53.860
40 rules in many of
these rule groups.
00:10:53.860 --> 00:10:56.636
And what we have observed
based on feedback is
00:10:56.636 --> 00:11:00.435
that sometimes a specific rule
is causing a false positive for
00:11:00.435 --> 00:11:04.379
the customers, and they want to
turn that specific rule off, so
00:11:04.379 --> 00:11:05.560
now we allow that.
00:11:06.590 --> 00:11:10.568
You can disable your entire rule
group, for example, you can say
00:11:10.568 --> 00:11:14.474
that you're not connecting to
a SQL database, and therefore,
00:11:14.474 --> 00:11:17.970
SQL injection is probably
not much importance to you.
00:11:17.970 --> 00:11:19.380
You can turn that
entire rule group off.
00:11:19.380 --> 00:11:23.057
Or we could have cross-site
scripting rule group on, but
00:11:23.057 --> 00:11:27.830
turn off an individual granular
rule inside that rule group.
00:11:27.830 --> 00:11:29.320
We support both, and
00:11:29.320 --> 00:11:32.030
similarly, you can also
switch from prevention and
00:11:32.030 --> 00:11:35.940
detection mode, and you can also
switch rule sets, themselves.
00:11:35.940 --> 00:11:37.571
So you can switch from 2.2.9
to 3.0 and vice versa.
00:11:37.571 --> 00:11:40.030
We offer both capabilities.
00:11:43.028 --> 00:11:47.176
Now, monitoring is
extremely important.
00:11:47.176 --> 00:11:51.790
It's a integral part of any
solution specially for WAF.
00:11:51.790 --> 00:11:56.971
So, by default, when you create
a web application firewall,
00:11:56.971 --> 00:12:02.000
we ask you to turn on
the Azure Monitor capabilities.
00:12:02.000 --> 00:12:05.538
I mentioned the performance log,
the access log back and
00:12:05.538 --> 00:12:07.537
held in a previous discussion.
00:12:07.537 --> 00:12:09.738
With web application
firewall SKU,
00:12:09.738 --> 00:12:14.260
you get a web application
firewall log integrated as well.
00:12:14.260 --> 00:12:19.485
Now, every time, either in
detection or prevention, input
00:12:19.485 --> 00:12:24.820
modes, resent any exploits which
we detect to Azure Monitor.
00:12:24.820 --> 00:12:28.690
And from there, this is
sent in a JSON format, and
00:12:28.690 --> 00:12:33.300
it can flow directly to your
storage account, the customer
00:12:33.300 --> 00:12:38.023
storage account, or it can flow
to a customer's Event Hub.
00:12:38.023 --> 00:12:41.477
Or you could also turn it
on with MS analytics so
00:12:41.477 --> 00:12:44.410
that you can do log
search on this logs.
00:12:44.410 --> 00:12:47.767
And I'll cover those details.
00:12:47.767 --> 00:12:50.439
Because it is integrated
with Azure monitor,
00:12:50.439 --> 00:12:53.381
we can call a REST API and
get these logs yourself and
00:12:53.381 --> 00:12:57.260
integrating to any third
party tool of your choice.
00:12:57.260 --> 00:13:00.419
You could also do it with the
call from Azure storage as well
00:13:00.419 --> 00:13:02.685
and I'll show you
the log format in demo.
00:13:06.370 --> 00:13:09.543
Web application firewall
is also integrated with
00:13:09.543 --> 00:13:11.135
Azure Security Center.
00:13:12.165 --> 00:13:15.995
Azure Security Center is
a central place in Azure for
00:13:15.995 --> 00:13:20.445
you to get recommendations,
define policies, and
00:13:20.445 --> 00:13:24.065
monitor your
application's health and
00:13:24.065 --> 00:13:28.055
receive alerts on any attacks
at one central location.
00:13:29.310 --> 00:13:33.564
With this integration,
Azure Security Center is
00:13:33.564 --> 00:13:38.527
able to recommend Microsoft WAF
as one of the solutions for
00:13:38.527 --> 00:13:41.376
any VM it detects as vulnerable.
00:13:41.376 --> 00:13:44.350
So you could scan your
subscription and it will
00:13:44.350 --> 00:13:48.011
tell you that these are the VM's
which are vulnerable and
00:13:48.011 --> 00:13:52.740
recommend of WAF and Microsoft
WAF is also recommended on.
00:13:52.740 --> 00:13:55.319
You can from there directly
deploy a web application
00:13:55.319 --> 00:13:57.438
firewall and
protect that particular VM.
00:13:57.438 --> 00:14:00.954
Not only that once you have
enabled the WAF through
00:14:00.954 --> 00:14:04.470
Azure Security Center we
send periodic alerts for
00:14:04.470 --> 00:14:07.244
any attack or
exploit which we detect.
00:14:07.244 --> 00:14:12.460
The same day that we're sending
alerts to the Azure monitor.
00:14:12.460 --> 00:14:15.060
We send it to
Azure Security Center, and
00:14:15.060 --> 00:14:18.670
at that one center location, you
can see your application health
00:14:18.670 --> 00:14:21.940
and also take a look at all the
alerts which it has received.
00:14:23.690 --> 00:14:26.220
So those are the main
capabilities.
00:14:26.220 --> 00:14:28.510
I will now go to a demo.
00:14:28.510 --> 00:14:33.350
And show you these capabilities
in portal as well as quote.
00:14:33.350 --> 00:14:36.332
Let's take a look at how
the web application,
00:14:36.332 --> 00:14:40.155
how simple it is to create a new
web application firewall and
00:14:40.155 --> 00:14:42.159
how simple it is to configure.
00:14:42.159 --> 00:14:44.400
So if I wanted to create
a new web application,
00:14:45.667 --> 00:14:48.218
Application gateway with
web application firewall,
00:14:48.218 --> 00:14:49.999
I would just follow
a few basic steps.
00:14:52.060 --> 00:14:56.836
I will do a BuildDemo,
I only have to choose WAF, and
00:14:56.836 --> 00:15:00.210
I choose my SKU size Medium or
Large.
00:15:00.210 --> 00:15:04.286
I'll create a new,
ResourceGroup,
00:15:04.286 --> 00:15:06.980
I will let the listener
location beat.
00:15:09.637 --> 00:15:13.140
And then, I would choose
a Virtual Network.
00:15:13.140 --> 00:15:15.310
And always create
a new virtual network.
00:15:19.705 --> 00:15:22.010
I would have to create
a public IP address.
00:15:28.153 --> 00:15:32.486
And let's just have a listener
which is just listening on
00:15:32.486 --> 00:15:35.210
HTTP port would it
be which is fine.
00:15:35.210 --> 00:15:40.210
And we want a web application
firewall that Enabled and
00:15:40.210 --> 00:15:44.888
let's say we want it
in Prevention mode.
00:15:44.888 --> 00:15:49.683
And that's it with those few
simple steps I'm creating
00:15:49.683 --> 00:15:54.488
a web application firewall
with CRS 3.0 as default.
00:15:56.597 --> 00:15:59.748
For demo, I have already created
a web application firewall and
00:15:59.748 --> 00:16:01.040
I wanted to show you that.
00:16:02.590 --> 00:16:03.752
So here we can see
00:16:03.752 --> 00:16:08.734
that I created a Web Application
Firewall with rule set of 2.2.9.
00:16:08.734 --> 00:16:12.722
And I have optionally
turned off a few rules, for
00:16:12.722 --> 00:16:16.418
example, in CRS 20
protocol violations,
00:16:16.418 --> 00:16:20.420
I have turned off URL
including abuse attacker.
00:16:20.420 --> 00:16:23.961
Similarly, I could
either enable it or
00:16:23.961 --> 00:16:29.030
turn off another rule and
save it and that's about it.
00:16:29.030 --> 00:16:31.892
That's how I just get rule
configuration from this web
00:16:31.892 --> 00:16:33.205
application firewall.
00:16:33.205 --> 00:16:37.148
Now, I also did a very
simple application,
00:16:37.148 --> 00:16:42.379
this is probably as vulnerable
application as possible.
00:16:42.379 --> 00:16:46.945
This is a commonest application
and all it does is it just
00:16:46.945 --> 00:16:51.413
accepts user name and comment
as input and that is it and
00:16:51.413 --> 00:16:55.607
then just tries to write
it back to the file system.
00:16:55.607 --> 00:16:58.604
So that was the application
which I was showing and
00:16:58.604 --> 00:17:01.741
you can see that this is just
a simple comment wall and
00:17:01.741 --> 00:17:04.890
I can write a comment and
that should be fine.
00:17:04.890 --> 00:17:08.168
Let's write a valid comment.
00:17:11.140 --> 00:17:13.742
And I can see it's valid now.
00:17:13.742 --> 00:17:18.730
Let's try to do something
which is not varied.
00:17:18.730 --> 00:17:24.840
I'm trying to inject a script
inside, and the WAF detects it.
00:17:24.840 --> 00:17:28.072
And this is a a script
injection attempt, and
00:17:28.072 --> 00:17:30.454
this is a anomalist characters,
00:17:30.454 --> 00:17:34.719
detects these anomalous
characters, and shows a 403.
00:17:34.719 --> 00:17:38.995
In fact, this particular
firewall is reliant on 2.2.9.
00:17:38.995 --> 00:17:46.840
And therefore, I would not be
able to browse it just using IP.
00:17:49.426 --> 00:17:54.096
It expects me to have a proper
host header which is not numeric
00:17:54.096 --> 00:17:57.210
and it detects that
header hosted in this
00:17:57.210 --> 00:18:01.056
case is just a numeric IP
string, and therefore,
00:18:01.056 --> 00:18:03.180
it just doesn't allow it.
00:18:03.180 --> 00:18:09.000
Similarly, I can try and do a
hello, and then a classic 1 = 1.
00:18:09.000 --> 00:18:11.818
And that also
should be the same.
00:18:11.818 --> 00:18:16.344
So you see that we have
configured a web application
00:18:16.344 --> 00:18:22.344
firewall with 2.2.9 and it just
detected a script injection or
00:18:22.344 --> 00:18:25.292
a simple SQL
injection attempt or
00:18:25.292 --> 00:18:30.050
a protocol anomaly with
the numeric value in hosted.
00:18:30.050 --> 00:18:35.216
Now, I can always go to this
particular application gateway,
00:18:35.216 --> 00:18:38.050
and look at its
diagnostics logs.
00:18:40.930 --> 00:18:43.970
Now, I have turned
the diagnostics logs on.
00:18:43.970 --> 00:18:48.060
This is a central way in
Azure to turn on diagnostics.
00:18:48.060 --> 00:18:50.945
And you can see that it
has generated access logs,
00:18:50.945 --> 00:18:53.144
it has generated
performance logs for
00:18:53.144 --> 00:18:55.686
application gateway
performance itself,
00:18:55.686 --> 00:18:59.070
and it has generated application
gateway firewall logs.
00:18:59.070 --> 00:19:03.949
I could download these and
look for
00:19:03.949 --> 00:19:06.840
vulnerabilities.
00:19:06.840 --> 00:19:10.790
So you can see that it
is logging each and
00:19:10.790 --> 00:19:16.074
every vulnerability it has
found in this interval.
00:19:16.074 --> 00:19:18.364
And this is formatted in
a simple JSON format.
00:19:18.364 --> 00:19:25.910
The key things to notice
over here is that it.
00:19:27.280 --> 00:19:28.830
For example, let's look
at this particular log.
00:19:28.830 --> 00:19:32.220
It says that the client
which tried to do this,
00:19:32.220 --> 00:19:34.990
was this IP from this port,
and it was just requesting,
00:19:34.990 --> 00:19:36.960
this is the URL it
was requesting.
00:19:36.960 --> 00:19:40.525
And it gives a detailed message
of what exactly went wrong.
00:19:40.525 --> 00:19:45.230
This particular request was
missing an accept header, and
00:19:45.230 --> 00:19:49.932
therefore it says that it threw
an access the night with this
00:19:49.932 --> 00:19:50.509
code.
00:19:50.509 --> 00:19:55.365
For example here, you can see
that I had already tried to
00:19:55.365 --> 00:19:58.887
do the same, and
I have gotten that log.
00:19:58.887 --> 00:20:01.760
I was trying to access
it through The IP and
00:20:01.760 --> 00:20:05.380
it clearly says host header
is a numeric IP address.
00:20:07.910 --> 00:20:11.280
So this is how the log flows.
00:20:11.280 --> 00:20:17.020
I can also go into
the log analytics.
00:20:17.020 --> 00:20:19.900
I have just configured
an OMS log analytics.
00:20:19.900 --> 00:20:22.750
I created a new workspace over
there and configured that.
00:20:22.750 --> 00:20:24.265
Now I can do a log search.
00:20:24.265 --> 00:20:25.602
So I could just search,
00:20:33.174 --> 00:20:38.480
I could search for
example, anomaly.
00:20:38.480 --> 00:20:42.685
It would show me that hey,
access was denied.
00:20:42.685 --> 00:20:46.230
Because I was trying
to do a hello and
00:20:46.230 --> 00:20:48.610
I was trying to do some
other pattern match.
00:20:48.610 --> 00:20:49.870
And you can see all of these,
00:20:49.870 --> 00:20:51.900
you can search by
rule IDs as well.
00:20:51.900 --> 00:20:53.916
So this is how you
do a log search,
00:20:53.916 --> 00:20:56.590
it is completely
integrated with.
00:20:56.590 --> 00:20:58.570
This just a simple log
search I am showing,
00:20:58.570 --> 00:21:02.120
you can do quite a lot of other
sophisticated queries as well.
00:21:02.120 --> 00:21:04.404
I also wanted to show
security center.
00:21:08.574 --> 00:21:10.171
So I go to security center.
00:21:14.857 --> 00:21:17.650
And here
are the recommendations.
00:21:17.650 --> 00:21:20.845
I followed one of those
recommendations and
00:21:20.845 --> 00:21:24.255
configured the log of
Application Gateway Firewall.
00:21:26.510 --> 00:21:29.070
At one central location you can
see all the alerts which it
00:21:29.070 --> 00:21:30.270
has generated.
00:21:30.270 --> 00:21:32.330
So it has generated alerts for
today and
00:21:32.330 --> 00:21:36.880
you can see these new alerts
which is 949 blocking evaluation
00:21:36.880 --> 00:21:40.470
or RC correlation protocol
enforcement and so on.
00:21:40.470 --> 00:21:45.987
So this is how you can look
at your existing solution.
00:21:45.987 --> 00:21:50.021
If you wanted a new solution,
you could always look at
00:21:50.021 --> 00:21:53.968
the recommendations from
Azure security center and
00:21:53.968 --> 00:21:57.030
you can add a web
application firewall.
00:21:58.240 --> 00:21:59.340
For example,
00:21:59.340 --> 00:22:02.920
let's say this window VM
is not protected right now.
00:22:02.920 --> 00:22:05.621
I had created a existing
solution with Application
00:22:05.621 --> 00:22:08.651
Gateway called ASC test,
let's try to create a new one,
00:22:12.669 --> 00:22:15.631
And it shows all
the possible options,
00:22:15.631 --> 00:22:19.051
and Application Gateway
is one such option.
00:22:19.051 --> 00:22:22.103
And when you click on that and
you click create,
00:22:22.103 --> 00:22:26.071
it takes you to the familiar API
in which I showed you earlier on
00:22:26.071 --> 00:22:28.540
how to create a web
application file.
00:22:28.540 --> 00:22:31.894
So, that concludes
our ASC integration.
00:22:35.436 --> 00:22:39.760
And how do you do this
through a programmatic way?
00:22:39.760 --> 00:22:42.230
Straightforward if
you have configured
00:22:42.230 --> 00:22:45.900
as a Web Application Firewall
using ARM templates,
00:22:45.900 --> 00:22:49.420
the amount of addition for
this is minimal.
00:22:49.420 --> 00:22:53.146
All you need to do is add
a Web Application Firewall
00:22:53.146 --> 00:22:58.219
configuration section into the
Azure Resource Manager template.
00:22:58.219 --> 00:23:02.470
And you simply just say what is
your firewall mode, whether it
00:23:02.470 --> 00:23:06.558
is protection or detection,
you say your ruleSetType, or
00:23:06.558 --> 00:23:09.850
you can see the ruleSetType
in the parameters.
00:23:11.250 --> 00:23:15.040
Your rule set is OS and the
type, ruleSetType is OWASP and
00:23:15.040 --> 00:23:16.510
the version is 3.0.
00:23:16.510 --> 00:23:19.570
So you just specify that and
that's it.
00:23:20.650 --> 00:23:25.258
So with this much you can create
a Web Application Firewall out
00:23:25.258 --> 00:23:27.660
of box with 3.0 protection.
00:23:28.820 --> 00:23:32.370
I'm also showing you that if you
wanted to disable a particular
00:23:32.370 --> 00:23:37.731
rule or an array of rules,
all you needed to do was give
00:23:37.731 --> 00:23:44.790
the ruleGroupName, and
all the rules within that group.
00:23:44.790 --> 00:23:47.550
And that's it.
You just execute this and
00:23:47.550 --> 00:23:51.460
it would reconfigure
the Web Application Firewall and
00:23:51.460 --> 00:23:54.590
block these particular rules,
00:23:54.590 --> 00:23:55.930
if we just remove them
from the configuration.
00:23:57.560 --> 00:24:00.450
And that is it for the demo.
00:24:00.450 --> 00:24:01.820
Let's go back to the slide.
00:24:01.820 --> 00:24:03.430
That concludes my demo.
00:24:03.430 --> 00:24:07.050
The key takeaways that
you should remember is
00:24:08.300 --> 00:24:11.900
with Application Gateway
you not only get
00:24:11.900 --> 00:24:14.450
the list of load balancer
with all the capabilities but
00:24:14.450 --> 00:24:18.600
you can also now
centralized your security.
00:24:18.600 --> 00:24:19.490
Enhance it further and
00:24:19.490 --> 00:24:22.680
have a Web Application Firewall
at the same central location
00:24:22.680 --> 00:24:24.420
without changing any code.
00:24:24.420 --> 00:24:26.930
As I mentioned, Application
Gateway can protect up to 20
00:24:26.930 --> 00:24:28.040
websites at the same time.
00:24:29.250 --> 00:24:34.640
You can eliminate false
positives by customizing your
00:24:34.640 --> 00:24:38.710
rules by choosing a rules set or
customizing rule groups or
00:24:38.710 --> 00:24:41.040
individual rules within
that rule group.
00:24:41.040 --> 00:24:43.180
It is easy to configure and
manage,
00:24:43.180 --> 00:24:48.060
it continuously emits logs,
both into Azure monitor and
00:24:48.060 --> 00:24:52.120
Azure security center,
you can continuously monitor and
00:24:52.120 --> 00:24:55.440
change your WAF settings
depending on what you observe.
00:24:56.960 --> 00:25:00.550
You can also scale out
Application Gateway
00:25:00.550 --> 00:25:03.180
by just adding more instances.
00:25:03.180 --> 00:25:04.670
If you see a bottleneck
in performance,
00:25:04.670 --> 00:25:07.970
you can add more instances,
and that will
00:25:07.970 --> 00:25:11.770
increase the throughput and
capacity of your gateway.
00:25:11.770 --> 00:25:12.270
Thank you.