>> Hey, friends, you're always hearing
about online security attacks,
compromised websites, and some go undetected.
How can you protect your application
from hackers and malicious traffic?
Teresa and Sharad are here to show us
how Web Application Firewall with
Azure Front Door can help protect
our web applications without compromising speed,
today on Azure Friday.
[MUSIC]
>> Hey, folks, I'm Scott Hanselman and it's Azure Friday.
We're talking about Azure Front Door.
Teresa and Sharad, how are you?
>> Very good. Thank you.
>> Thanks for sharing this product with me.
I actually recently set up
Azure Front Door and I'm excited to learn even more about it.
>> Great.
>> All right.
>> So today we are going talk about what are
the recent updates from the last Azure Friday session
we did about Azure Front Door,
and then we'll talk mostly about
the Web Application Firewall which
just went into general availability.
So just a quick recap of what Front Door is.
So one of the key things that Front Door provides is
if your application is hosted in multiple regions,
than unlike a typical DNS based load balancing system,
you can fill one near instantly
from one region to another because there's
no DNS detail that gets cached or things like
that or via any CAST IP.
So when things need to switch,
the client doesn't see any changes happening,
and behind the scenes Front Door actually just switches
over from let's say US West to UK South, etc.
>> So staging.hanselman.com right
now is a C name that goes to Azure Front Door,
that DNS is going to be the same always.
>> Yes.
>> So if I failover, I don't have to wait
for the whole world's DNS to expire.
>> Yeah.
>> Yeah. So typically we do
demos that yeah we can feel were under 30 seconds
from each other and a client
doesn't even see breaking connections because
they are still connecting to the same
Azure Front Door environment.
>> Nice. Okay. That's cool.
>> The next thing that we talk about
is the path this load balancing.
So Azure Front Door is a Layer 7 load balancer, so HTTP, HTTPS.
So based on paths,
we can send it to one region versus another region,
or depending on how you've deployed your Microservices in Azure,
or even not in Azure even on
other Cloud providers or on-premise systems.
So based on path, you can
do load balancing between one versus the other,
you can do active-active, you can do active-passive,
or just based on Microservices.
>> By the way,
that's been hugely useful for me because I'm in
the process of moving my system
from an old virtual machine to multiple Microservices,
and I've got hanselman.com/blog,
slash this, and slash podcast, and slash speaking,
all of that running on one IIS that
now is going to run in multiple apps services,
and I wanted to have in multiple locations, in multiple regions,
and the only thing
that would give me what I needed was Front Door.
>> Yeah.
>> Thanks for that.
>> It's working great.
>> So the next thing we
introduced of it's [inaudible] which is now
generally available is
the Web Application Firewall capabilities about Front Door.
So that's the new thing that we have
talked with and we're investing very heavily
in the space because we see
the constant requirement from
our customers coming and talking to us.
Okay. How can we improve
the security from application
because your fronting all of the traffic?
Is there any way I can protect?
There are different scenarios of SQL injection,
cross-site scripting, multiple other things.
The last thing because Front Door is
a content site acceleration and at the heart of the CDN as well,
we can literally accelerate both your
dynamic as well as your static content so pulling from the origin.
So as I mentioned, some of the new capabilities,
GA for WAF capabilities,
we have enabled URL redirect,
that is you can redirect HTTP to HTTPS traffic.
You can also redirect from one domain to another.
You can redirect on the pots.
All those are very versatile capability that we've launched.
We were not supporting Apex domains so that was a very,
very major pain point of something we heard.
>> Can you explain what an Apex domain is?
>> Yes. So typically, let's say if you have
a domain hanselman.org or hanselman.net,
that's an apex domain.
You typically have your users going
to dub dub dub dot hanselman.com.
>> Was that in the old days called naked domains?
>> Yeah. The Naked domains, route domains,
apex domains, it's all the same thing.
>> Okay. That's good to know, and I actually have that,
so I should make sure that my Front Door is correctly configured.
>> Yeah. So the other thing is that we have
now got a bunch of certifications like ISO and SOC,
and we're working through
getting a lot of these other modern certifications.
We'll also have a blog post about that,
all these new certification that Front Door has.
>> Cool.
>> Yeah.
>> So then why have you on the Web Application Firewall.
>> Yes.
>> Okay.
>> Yeah. So you mentioned you actually like
your blog site to be on Azure Front Door now,
have you tried WAF?
>> Well, so I looked at it and I went as far
as clicking and preparing the profiles and the policies,
but I saw SQL injection,
my site doesn't have SQL,
I saw PHP, I don't run PHP,
so I thought maybe it's not for me.
>> All right. So the WAF capabilities actually have more than
just a known attack signature
such as SQL injection or cross-site scripting.
It can also helps you from malicious bugs.
Let's say you have your website,
and then there is somebody intentionally who want to send you
many requests to block legitimate users to really awesome blog,
in that case, you can definitely create
customized WAF rules to block them. You can limit them.
>> So then maybe WAF is for me.
>> Yeah, we should try that.
>> It's for everybody who's running a website.
>> So you think the WAF should be turned
on for anyone using Azure Front Door?
>> Absolutely.
>> Yeah.
>> Okay.
>> We can go through some scenarios of how do you
set up a WAF with Front Door to protect your web applications.
>> Let's do it.
>> So let's see. Let's go ahead and
start to create a new WAF policy.
>> So here we have a Front Door setup.
It's a very simple Front Door that we have.
It's just going and pointing to
an app service instance running in Central US,
and there are two routes,
one that just redirects HTTP to HTTPS traffic,
and the other one forwards it to
this back-end pool that I just
mentioned for all the HTTPS traffic.
>> Think about this scenario as you have
your blog site hosted at the web app,
so it's this now we have added Azure Front Door,
so now your users across
the globe can get to your site through Front Door.
So the Front Door is a reverse proxy
in front of your web applications,
by design, we block everything,
but the web traffic to you.
>> Really? Now you had mentioned before that there are
different existing policies like
SQL injections and PHP and different WordPress,
and different things that are known,
but I've started to notice some, I think,
naughty people trying to do
posts and things and then just errors are showing up
in my logs which makes me feel like maybe I need a custom policy.
>> Absolutely. You can customize the policies,
say for my websites,
I only allow get-method,
I'm not going to allow post-method.
You can do that. So let's let's go through a scenario.
First, let's see how do we find to define a WAF.
>> Okay.
>> So here we go.
>> So on the Marketplace, you can just go to Marketplace
and click on "social Web application firewall",
and it'll show you the entry,
I'm just going to click "Create".
>> Yeah. So in the Create flow,
you will see just a few clicks,
and then define your resource group,
and then define a policy name.
A policy name is unique.
So we do use that as a unique identifier so it cannot be the same.
>> Okay.
>> We will let you know if somebody else used that name.
So here and if you go down in the managed rule set,
so this is a pre-configured rule set,
has about nine groups,
and those are identified as
the top vulnerability is for
web applications defined by OWASP top 10,
so Open Web Application Security Project.
So those are the known signatures.
So we have them pre-configured for you.
So you can easily have the default protection.
>> I went through this process and I was
getting ready to turn them all on.
>> Yes.
>> I was going to just turn it all on
because I want to be extra safe.
How do I make sure that one of them doesn't
accidentally keep my site from working because
maybe I have a strange URL and one of
those policies thought I was a bad guy to myself?
>> So usually when you've been labeled a WAF,
there are two mode.
If you go to the top of either as
a prevention mode and detection mode.
Initially because both positive
is a real concern for a lot of application owners,
so you can say I'm going to enable everything in
detection mode so that I can see,
and then for each individual rule,
you can disable it.
>> That's cool. Okay. So then what
prevented me from finishing and going,
"Yes, I want all of this turned on," was not knowing that.
So now I can turn everything on,
go into detection mode,
run for a week,
see what false positives may have happened,
and then kind of make my policy perfect just for me.
>> Absolutely. Yeah. Actually that's
what we recommend people to do.
>> All right. Great.
>> Also even, let's say,
you decided I'm comfortable enough
to enable protection mode or prevent mode,
and for one specific rule,
I'm not so sure, individual rule level,
you can also do blog.
>> Really?
>> Yes. [inaudible]. So let see how easy to set it up.
So here we have the default configuration enabled for you,
and then go ahead, we can associate with a Front Door host.
Then in there basically what you will be
able to choose the Front Door you set up.
Right here, if you create,
"Review and Create", and that's the whole process for you.
>> That's it?
>> That's it. For time's sake,
we're not going to go create and we're going to
go back to the one we already pre-created.
>> Okay. Cool.
>> So here, in this one you can see there's global settings.
We mentioned about prevention and detection,
and then there's also a global settings, say, for example,
if there's certain match conditions match,
I don't want to block or I don't want to log.
I actually want to redirect to a honeypot or some where I
want to look what of this particular traffic do.
You can do that. You can
define what is the redirect URL you'll use.
Our default response code when we block is 403,
you can say something else.
Because sometimes people actually say I just wanted to say
200 so that people doesn't know I'm actually blocking.
So you could do that.
>> That's a good point.
>> Then you can customize your response body as well.
So that's all for the Managed Rule space.
So in a WAF policy,
it consists of customary rules
and managed or pre-configured rule set.
Customary rules always have a higher priority.
So we always run customary rules first.
So here we have a few customary rules defined for you.
Let's go through the UserAgent one.
Because a lot of- if you heard about concerns on bot.
So there is a malicious paths and a lot
of malicious paths have some kind of signatures.
A lot of time is in the user agent string.
So in this particular case,
we configure a customary rule to block
a UserAgent that says I'm suspicious.
>> Right. If the bad guy says bad guy,
you should block him. Absolutely.
>> Yeah. So you can use other signatures here.
>> That's a lot of flexibility.
>> Yes. So our call is a really flexible WAF rules engine.
>> You were also mentioning about requests method.
So we also have capabilities to do
request method based on query string,
URL parameters, and several other options that
you can define your match condition space.
>> Yeah. Another customary rule
I want to point to you is the rate limiting.
So rate limiting is a conditional rate limiting.
I can define for my one page of my website,
I can only allow you to do five.
If people do more than five per minute,
I think it's suspicious.
You can do that. There's another use case for
rate limiting is to block volumetric attacks.
So you can't just send me thousands of request from [inaudible].
>> Now you've got my brain thinking
about all the things I could potentially do.
For example, I'm having a problem with comments spam.
I could start rate limiting
the bad guys that are going and spamming me
by saying these many post over this amount of time is suspicious.
I know you're excited to comment on my blog.
>> Yes.
>> Slow down.
>> Right. Yeah.
>> This is great.
>> If that particular spam will have any other signatures,
any combination of HDD parameters you
can specifically define a customary rule to block.
>> I'm doing that outside the context of my blog.
It's really, those are business rules
that are in the Front Door space.
I don't have to change any application
code for any of these things.
>> Absolutely.
>> Catch it at the Front Door.
>> Yes.
>> That's fantastic.
>> Because Front Door architecture is using Anycast,
so it's always very close to the client.
So we want to stop it as close as to
the source without bringing all this traffic.
>> So I'm in West US too and they are in Australia,
you'll stop them before they even cross the continent.
>> Yeah, probably in Melbourne,
Brisbane, Sydney, both. Yeah, multiple locations.
>> You can catch them before they leave the continent.
>> Yeah.
>> Yes.
>> Fantastic.
>> You don't have to travel the waters.
>> That's great.
>> Yeah. I think that's all,
we can show you how that works. So let's see.
>> Sure, very briefly as we end here.
>> Show briefly how it is.
>> Yeah. So in this first case,
let's say we were talking about the rate limit scenarios.
So we have this example where we have we have rate limited,
as we we're showing.
>> Yeah. So if you go here, we said five.
So I'll just do a refresh around five times,
and you'll see that on the sixth to
seventh attempt I'm now blocked to go into that particular site.
Correspondingly, there are several other rules like, for example,
for cross site scripting or SQL injection or local file.
You can see in the URL that somebody's
trying to access to the local file or something.
>> Yeah [inaudible].
>> It just blocks you from doing those kind of things as well.
>> Let's quickly touch on what do you see. So we have metrics.
It's fully integrated with Azure Monitoring.
So you can tell which rule is
blocked and how many requests are blocked.
As far as log goes,
it's fully integrated with log analytics.
So you can use log analytics or you can
use a storage account or you can use event hub.
So here we just show you it is integrated with log analytics.
So you can see what requests come or what rules were triggered.
You can actually create
something like a Sentinel to do a same integration.
You can pop your events
through log analytics, through there as well.
>> That's pretty cool. It's not a black box.
That's one of the things, when we turn a feature like this on,
when we as customers put something in front of our application,
we don't want it to feel like a black box and you're
showing me that none of these things are black box.
Every policy, every action that is taken
is available to me to go and analyze and do the right thing.
>> Absolutely. Yeah, absolutely.
>> Just one last thing. We're running
all these powerful WAF rules
and everything on your all the traffic that we're getting.
So here I have a sample, we're doing
a side-by-side comparison going into
the actual instance of Central US,
the App Service instance,
and we're going to the root path itself.
We're doing that 50 times,
and we'll pull the root path,
the base image, the root domain itself.
We'll go WAF Front Door on the left-hand side,
and it has the WAF enabled.
There is no caching whatsoever.
So it's just every time evaluating WAF rules,
going to the back-end, pulling the content and giving it back.
So we'll just start both of these,
and you'll see after a few seconds at Front Door running,
each of these instances we are pulling
around around 9KB of response size.
After a while, as the connections get warmed up,
as more and more- as we get more traffic,
you'll see a significant acceleration.
We are currently on the Microsoft's corporate network so there's
a lot of time it takes to exit our proxy networks.
But yeah, you'll see that there'll be
a significant improvement even for
a 9KB object pull on an average,
we would be saving around a 100 to 200 milliseconds
on a per-request basis.
>> It looks like on the left it's already 20 percent faster,
just in the few little bits that you've done.
>> So you can see we saved here around- so on an average for 9KB,
in Front Door we're doing 432 milliseconds,
on the right-hand side we were taking around 570.
>> The warmer it gets, the faster it gets.
>> That's because of the- and considering on your left-hand side,
going through Front Door we actually do the full inspection.
Every single rules, hundreds of rules,
actually for WAF it's done,
still faster than if you were to go to
your website directly without any WAF protections.
>> All right. Well, I'm going to go and set this up right away.
>> Great. Thank you.
>> Thank you so much for chatting with me.
I'm learning all about Azure Front Door
and WAF and I'm going to go set this up right now,
today, on Azure Friday.
[MUSIC]