Protect your web applications using WAF with Azure Front Door | Azure Friday


>>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.>>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.>>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]

2 thoughts on “Protect your web applications using WAF with Azure Front Door | Azure Friday

  1. Aquí estoy querido pensando en ti Estaba también perdí dinero en el banco la mulata te salió tranquila sabes que la persona que conocerla primero antes ves que las personas se conocen cuando más necesita que nunca le da la espalda biometacin todo está bien okay Por lo menos estoy hablando

  2. Just keep in mind with all the security features available you won't be able to disabled TLS 1.0 and 1.1 🙁 so much for the security

Leave a Reply

Your email address will not be published. Required fields are marked *