Architecting Advanced Network Security Across VPCs

welcome to today's webinar I am Rochelle Hensley and I'll be your moderator today during today's call our topic today is architecting advanced network security across BPB pcs with AWS transit gateway and today we'll be joined by Tom Adamski specialist Solutions Architect aid from AWS Shaw he is the senior director product management at Val techs and Praveen Pat Nala chief architect and co-founder at Baltics we're glad all of you could join us today and thank you so much for being here with us today now for our audience today's call will cover a variety of topics on AWS transit gateway and of course AWS transit gateway with valve texts today we'll start with B PC security capabilities so I'll hand it over to you Tom to take it from here thank you so much thanks well welcome everyone I'm Tom Adamski I'm a specialist solution architect focusing on networking on AWS so I tend to focus on anything to do with networking and with AWS networking services and today I'm going to spend most of the time talking about the different integrations you can have where transit gateway but before we dive into that I want to talk about some of the existing VPC security capabilities and split them into the ones that operate at the network layer and the ones that operate the application layer so on the network layer we have our V PC and we have our subnets inside when we deploy our instances so V PC is our private network we run on AWS the network layer controls that we have to protect those instances our network access control lists that you can wrap around your subnets these are typically used as I can brush broad strokes security so you might just deny ports that you don't like arranges you don't like and then the second layer of security that you always have to deploy are the security groups and the security groups would wrap around your instances or your services and decide what is allowed and what is not allowed to those services and finally you can export the information and the flows that are occurring inside your V PC using V PC flow logs and this will give you metadata information about the traffic so all of those services operate in the network layer which means they're focusing on IP address those ports but they don't actually give you visibility into the application layer into the actual payload if you want to start diving into the application layer you can use traffic mirroring for additional visibility and effectively enabling a virtual tap on your instances to start seeing the pile of those instances are receiving you can enable aw swath which is focusing on HTTP and HTTPS and running on AWS application or balancer or our CDN cloud front and then finally you can use third-party appliances and in today's session we'll focus about on how you can integrate those third-party appliances with the transit gateway and then I'll hand off to Jagga and Praveen to talk about the unique features of vault X and how they implement their services were AWS so first of all let's quickly recap what the transit gateway actually is there was launched at the end of 2018 it the best way to think about it is router that you deploy into ne WS region that allows you to connect multiple V pcs and multiple different environments and create this hub-and-spoke topology so all the V pcs can talk to each other and back to on premise and allows you to also be flexible in how you allow router routing between those different environments so if we look at an example here is our transit gateway and we do always show it as a single object but it's actually a distributed system so it's never a single point of failure it's a highly available highly scalable managed service so here you you can attach multiple V pcs to the strands the Gateway and then those V pcs can route for the trans gateway just like for a router and communicate with each other you can then connect the trans gateway back to your corporate datacenter backed on premise either using VPNs or using our dedicated connectivity Direct Connect and then in the end of last year we launched the ability if we clear transit gateways in different regions so if you have that requirements to connect via pcs in different regions you can use the transit gateway for that and the transit gateway in all those scenarios is really the routing Center it's the brain of all the routing so it knows about all of the attachments and what routes should be sent through through which one and transit gateway is actually really good and helps with integrating your security appliances whether you're focusing on egress traffic so traffic going from your V pcs to the internet or whether you focusing on ingress traffic so traffic coming from the internet towards some application you're hosting on AWS and for egress traffic which we will start with there's three different ways of attaching your security appliances to your transfer gateway environment you can go with the native EPC attachment model you can go with a VPN model and then you can use an explicit proxy model and we'll kind of dive into each one and look how they how they are set up and how how they operate from a high availability point of view so in our example here on the left hand side we have a V PC and the kind of one range and we have an instance there that will be our source of traffic trying to get out to the Internet we have that BBC connected to our transit gateway and then on the right hand side we have our security V PC so this is our BBC where we will have security appliances and you can see already in there we have two subnets and those subnets will be a different availability zone sounds to provide high availability so when we zoom in on how the transit gateway is actually attached to that V PC you'll see that it appears as two different transit gateway Anais which means elastic network interface so effectively logical interfaces with IP addresses that traffic coming from the transit gateway will come out of and then the other thing that's missing is our security appliances so we have additional two subnets and then we have firewalls in each one of those subnets or security appliances that we will use for filtering so if we start looking at how routing is actually configured in this scenario B PC on the Left might just have a default route pointing to the transit gateway so if the instance is sending any traffic to the internet that will be forwarded to our transit gateway the transit gateway needs to have a route back to our V PC on the left but it will also have the default route pointing out through the BBC on the right and then in the V PC on the right we will actually use different routing tables for different subnets so you can create that separation where each subnet will actually have different routing behavior and in our scenario if the traffic happens to come out of the en I at the top we want to forward traffic destined to the Internet to the firewall at the top as well and if the traffic comes out at the bottom we want to forward it to the firewall at the bottom and then from the firewall subnets we will actually have traffic to the internet pointing to the Internet gateway which is what provides the exit and entry points to the internet for the whole V PC so let's do a packet work of how actually the traffic is going to be forwarded so first of all the instance is using its own source IP address and maybe it's connecting to a public website amazon.com so that would be some public IP address that it needs to get to so traffic would use the default route get to the transit gateway the transit gateway also has a default route through the attachment number two traffic might come out from the bottom eni or the talkee and i best way to think about it is can be fairly random and from there we need to decide how to forward traffic next and we know we will forward it to firewall 2 and then firewall to is actually what will apply source address translation so we do so us not so we'll replace the real source IP address of the instance we have its own IP address and then forward the traffic out for the internet gateway to the Internet and we have now a flow from an instance on the left to the internet and we can apply our security filtering on the firewalls but one thing to consider here in terms of high availability is what happens if one of our firewalls fails so imagine the firewall at the bottom has an issue it goes down those route tables that we configured earlier the subnet route tables they will not automatically react to that failure so what will happen is that default route is now being black holes so any traffic coming through the NI at the bottom might be black hole and traffic doesn't have anywhere to go so you need to create your own custom automation to make sure the traffic gets forwarded to the firewall one or the any other firewall that's selected so let's look at another option of attaching your firewalls to the transit gateway and in this case we'll look at the VPN attachment model so if you notice on the right hand side that V PC is no longer attached to the transit gateway directly instead we will configure AWS side to side VPNs so these are just I P side VPNs the running BGP session so the firewalls can inject a default route into the transit gateway router table and the traffic can be forwarded to the finals so if we look at the route tables we still have the same route on the V PC nothing changes here the transit gateway will now see multiple routes to the default destination it will see that it can forward traffic through VPN one all through VPN to and if you enabled equal cost multi path ecmp it's a protocol that allows you to then utilize multiple tunnels and distribute the distribute traffic across those multiple tunnels to get additional bandwidth so once the traffic gets to the firewalls then the same subnet of the subnet of each firewall is going to use the default route to get to the Internet gateway so if we look at how the packet is going to be forwarded for done environment same source and destination as before default route sends it to the transit gateway transit gateway now has two options you can take VPN one or we can - or if you have more you can use multiple different VPNs it will get forwarded to one of the firewalls you apply your security policy and then the firewall does source address translation again through its own IP address and forwards it out to the destination from high-availability point of view it's a little bit better than the previous model as you don't actually need to create your own custom automation so we can rely on BGP to detect the failure of the firewall and remove the route from the routing table however with BGP the timers you can't really adjust them so you can wait as long as 50 to 60 to 90 seconds for this failover to kick in finally let's talk about the proxy model so in this scenario a V PC and Allah on the right is directly attached to the transit gateway but instead of doing routing like we did before and using the routes to forward traffic to the infinite destination what we'll do is we'll set up a feed of proxies maybe put them behind the network load balancer and configure the proxy explicitly or on our instance or we could actually be creative and use DNS to to forward the traffic to the to the proxy let's assume in this case we're doing we're doing explicit forwarding so from a routing point of view because we don't need any routes to the internet all we need is the route to the proxy fleet so the V PC doesn't have a route to the Internet the transit gateway doesn't have a route to the Internet the en eyes of the transit gateway don't need a route to the Internet only the proxies need to know how to get to the internet destinations so if we look at the traffic flow on the left hand side from the instance the traffic will actually be destined through the network load balancer IP address even though underneath the hood in the application layer we will have the actual specific destination saying that the instance wants to get to amazon.com once the traffic hits the NLB will be forwarded to one of the proxies the proxies then will terminate the connection they will see that the client actually wants to connect to Amazon and will reinitiate a new connection to Amazon from their own IP addresses using the Gateway rot so if you look at high-availability here this is actually the best model from a high availability point of view we can rely on the network load balancer health checks to detect failures of any of the proxies and automatically remove that proxy from being a potential target for traffic so if we compare all the three options for egress traffic filtering side-by-side we covered the BBC attachment column so this is the routed model where if you remember you needed to create your own custom automation to make sure that in case your Foley's traffic can still be forward it but the good news about the this model is you didn't have to run any VPN tunnels so you didn't have any encryption overhead and it's transparent to the client so it's just routed traffic then we looked at the VPN attachment model where the high availability was provided by bgp but we had to create those IPSec tunnels which can potentially mean some encryption overhead on your security appliances but again from a client transparency point of view there was no no changes you need to do on the client and then finally the explicit proxy model which from a high availability point of view is very fast so it relies on the NLD health checks you don't really have to do encryption if you're doing the expression explicit proxying with configuring the clients then it's not going to be transparent to clients but you can use DNS and kind of make it as transparent as possible so this is our equation I just want to spend some time on talking about the other direction so when you're publishing an application out to the Internet and you want to implement a layer of security appliances before the traffic gets to your actual actual application so in this scenario we have the DPC on the Left this time it's hosting maybe a fleet of web servers or any kind of application we want we can put a feed of web servers behind an application load balancer and that whole VPC is then attached to all trans gateway on the right hand side we have another security VPC connect to the Internet in there we can deploy a fleet of our proxies so firewalls and deploy a network load balancer in front of them so that users connected to no load balancer first before they get to other proxies so from a traffic law point of view a user if they connect to the application would effectively be directed to the network load balancer that's publicly facing and you would typically do that through configuring DNS to point to the IP addresses of the of that network load balancer once those users connect to the NLB the NLB we're then forwards the traffic to one of the proxies so we'll change the destination from the NLD IP address till the proxies and then the proxies will re initiate the connection so there will send the traffic from their own IP address to the applicational balancer which is the actual destination and then finally the alb will receive the traffic replaced the source to its own IP address and destined the traffic through the web service so this model works really well some of the challenges that customers might run into is figuring out how are you actually going to manage this layer so we have those proxy firewalls each one of them need to be configured to map to your applications so it's very important that there's a scalable way for you to manage and configure configure those devices finally from a high availability point of view if one of those proxies fails we still have and you'll be health checks here who can take care of failover and just remove that proxy from from service so these were some the standard ways of connecting appliances to the transit gateways and I'm gonna have that back to Jakarta to talk more about some of the unique features of baltics okay great thank you Tom so my name is sugar I do a product management at multics and let me dive into the details okay so this is okay so this is a big oral picture of one wall textures so we are software-as-a-service available for doing advanced network security to protect your public cloud applications there's two main components of our use case that we're gonna talk about today one is the edge case where the controller which is the SAS portal where you log in is going to deploy a cluster of firewalls to protect internet-facing applications at the right top side of the spectrum which is we like to call the edge mode this is essentially a distributed security model where the firewall cluster is deployed into each customer's VDC to protect all the applications that live inside that so that's one deployment model most of today's talk is going to be on the right bottom side which is the hub deployment model where we connect across France and Gateway and provide a centralized stack of firewalling services so this is alluding to what Tom mentioned earlier that that final cluster that is deployed how do you manage that at scale how do you deploy policies and how do you do discover your Maps so all are those things that we'll cover through the rest of this talk now to come back and do a basic level set like I said the SAS cloud controller is where the customer logs in and it just built on a completely cloud native architecture where the control plane lives in this portal customers log in there and manage all that environment and then the data plane is the actual firewall cluster that is an auto scaling set that gets deployed into the customers cloud account this is a multi cloud multi region and a multi zone service so it's very fault redundant and tolerant to any individual component failures now the core security engine itself is a fatal pass inspection engine that offers multiple components so there are web applications there is a mod sector graph Engine web trust a rule sets being updated continuously and for other traffic streams there is a snort IP as metallus rule says being updated and all these are combined with TLS decryption and encryption capabilities throughout the day to play in part so the beauty of this approach is start the final cluster living inside the customers environment means that we never see your encryption keys or when we store peek apps for any incidents that happen they all go into the a diverse s3 pocket of the customers environment and a key benefit which kind of trembles alluding to is how do you do management of these appliances and that's where the security as a service component comes in that there's not a lot of work teams have to do it's a fully managed service software updates auto scaling and even the routing with the transit gateway is handled by the service itself so what this gives you is a simplified deployment model and you get a centralized place where you write policies for all your different regions all your different transit gave you a related attachments and so on and so it makes a really clean simple model for management so ok just as a level set of what typical example attacks that we see commonly in public clouds and again this is not specific to public cloud and actually happens within a data center that has application to workloads and the useful vectors are either malicious insiders whether it's a developer whether it's an administrator or an infected user that their laptop or desktop is infected and that allows a vector to go into the cloud environment or more commonly unfortunately it's in this configuration that teams have not spent enough time to understand the shared responsibility model and haven't configured things correctly another vector has been that that some of the Cerner's that are deployed have a known exploit for example each party strokes example from a couple of years ago that there was some owner ability and those whom said don't patch them maybe because they didn't know they needed a Patrick or there was a maintenance window that they were waiting for or maybe both are compatibility so having a security technology in front of it gives you that virtual patching capability and similarly the windows have something exploit where it was literal movement of the Apache of malware that infected across an entire set of infrastructure so those are vulnerability vectors the other factor is to note that is one of the different network connections going outbound and often a key important factor is to distinguish between known good ones essentially a whitelist death set of destinations versus grave air or bad stuff right so a common outbound connection is connecting to your company's github repo to download infrastructure as code components all the logic that powers your infrastructure but then github could have a lot of other bad repositories that the bad guys are hosting or just public repos that you may not want to allow so how do you make sure that connection based on DNS fqdn sni or even the URL path is controlled and a similar example is software updates which you want to allow that's it from canonical comm for doing apt-get on your Ubuntu VMs but you don't want people to go to a rapid share and then you have to think about distinguishing between allowing some things in production maybe only updates from canonical but during tab cycle or test or staging you may allow updates from more repositories right so these are things to consider but in the end what you're worrying about is the impact all these attacks do which is try the cost excellent read data and the strip operations on cars reputation damage right so having a perspective on the attack tells you what solutions you need to look for so with round takes the onboarding flow is quite simple it does not require weeks and months of planning complex templates and you know crazy reference architectures the process is fairly simple you sign up for the service you give us the client potentials and what we start doing is we continuously discover your applications in your AWS DPC's once you scattered them the security admin can then decide to say these are the applications I need to secure and deploy literally about six cluster which we call eval kicks gateway essentially it's all the scheming cluster of firewalls you can use the graphical user interface that I'm showing here you can use an API call to us or anything in the terraform to make the deployment repeatedly also you can deploy in that edge mode or hub mode like you said and we will obviously make the networking connections or trying to Gateway around route changes like I said so you selected the region's you selected what you want to secure and the final clusters come up based on your auto scaling settings you could have said to minimum ten maximum and then you have an infrastructure ready literally with a click of a button and finally you're gonna say what are the specific security policies that I need for this particular application now the applications that we've discovered you can classify them using the names that are assigned to those load balancers or it could be any metadata like tags that are associated it could be test stage in production new york ecommerce whatever is the metadata you associated and that helps you identify and give specific policies so from the time that an app team is ready to an unappetizing literally takes minutes you just need to make a decision and write the right policy for it and as a very mature tool we've also done integration with common sense tools and data like offerings which gives you a deeper way to look into all the traffic patterns and analysis that they're able to take up and finally we've also now started doing integration with threat and vulnerability management tools like it'll be Lascar duty so this gives you also another rich set of ways to hook into the information that we'll deriving so with that said I'm gonna candy darkly Praveen who is the co-founder to give you a deeper dial into the architecture kind of in parallel to what tom is showing you and how they fit into the architecture Thank You Judith for providing an overview of Baltics endeavor solution you know my name is praveen and I'm one of the co-founders at vault dicks in the Baltics is a venture-backed startup we've raised two rounds of funding in the last two years at vortex we are building the first cloud native security service and you know personally before starting vortex I was an engineer in Google Cloud and today I will do a deep dive of a solution and use cases and are and how voltic selves operationalize network security for our customers as they run more and more of their workloads in AWS leveraging AWS transit gateway now at the high level in a vortex solution is an SDN style architecture with a decoupled control and data plane now our solution is fully cloud native we have deep integrations with the AWS api's and technologists you know for example for decryption we require the private keys or for customers or their applications now these is resigned completely inside the AWS account boundary so the instances which we create through AIIMS policy they can securely access the keys from kms and secrets manager similarly we integrate with s3 where we want to let's say do packet capture and store data securely all of that happens securely inside the customers account boundary like no production traffic or private data our keys never leave the customer account boundary when they're communicating with the baltics controller now what disk controller is offered as a service fully managed by us you know what external basically implements that discover and deploy pieces of the architecture previously mentioned that fully manage the lifecycle of the vertex cloud firewalls which are deployed across multiple AWS accounts of our customers and you know it provides a single pane of management for all of your security policies voltage control it is also you know a highly cloud native kitchen built using AWS managed services and technologies we use RDS or aura we do we do use you know elasticsearch etc all of these are managed services provided by provided by debruce now the voltage gate way is a cluster of cloud firewall instances running in our customers AWS accounts it is always deployed as a auto scaling cluster of ec2 instances in multiple availability zones within a region like think about them as you know the vortex Gateway is a collection of mini clusters in each availability zone all of this managed by the vertex controller and each baltics cloud firewall implements multiple layers of network security you know including advanced l4 firewall TLS IPs and RAF all in a single pass low latency highly efficient pipeline data pipeline now our firewall instances can run on both x86 based instance family like the C 45 LS m5 as well as the FPGA based f1 instance family of AWS you know we are the first vendor to use the F for instance family to deliver network security as a service for our customers and we accelerate lot of the computing for security for the clinic special processing which are needed for deep packet inspection on the FPGA now you know let us do a deep dive into the various use cases of resolution no tom has previously covered in detail the egress use case but customers want to protect their outgoing traffic from their workloads ahead of us now as you may have noticed there are various complex steps needed to operationalize the solution using transit gateway right now these include managing the radius route tables the vbc attachments VPN attachments etc with politics this entire exercise is fully automated and we allow our administrators to only focus on enabling the right security policy the define M and manage it for there patience and were close now as a first step politics fully in opiates and fully manage of the services we can see which is used to deploy the vertex fire one cloud firewall which will be used to inspect the traffic they were doing traffic now these again these feral pastures have deployed in multiple lazy's and we internally create a Douglas MLB which is used to spray the traffic among the nodes the node table HR attachments in the V pcs as well as the transit gateway are managed to route the traffic from the V pcs to go via the services V PC before the distinct net and finally we provide various layers of security needed for inspecting vigorous traffic you know by enabling a egress proxy for each of those endpoints of the outgoing traffic and those services include you know security based on DMS F could you an SMI or URL off the destinations on the internet it can also include other past destinations like you know a Dobis s3 lambda Camus etcetera right we allow blocking this connection transitions based on you know defining a malicious IP address list which I again can be dynamic dynamically manage through our platform everything in the Baltics Cloud Controller is API driven whatever you can achieve through the console you can also use our native rest APIs and telephony PS to manage that now the inspection of the traffic in those encrypted sessions is done using snot IPS as well as AWS as well as Val like using mod sec you know CRS and also the advanced rule sets from Rossville now let us look at a more common north-south traffic management use case where customers want to protect their applications in the ingress path now in this mode we first need to direct the traffic for the applications to go via the AWS like it to go by the Erebus NLB of the vortex gateway now what X controller is integrated with various DNS providers including route 53 to manage the DNS records for this routing change now once traffic flows - there will be Walt expire wall can deliver multiple layers of network security and if you look at the traffic flow right the traffic will first hit then will be it will say it'll be sent to one of the availability zones and we do the proxy before it reaches the backend application behind and alb right now for these the various layers of security provided are using laughs we protect against the overstocked and rule sets also as well as the Trustwave advanced rule sets with our IP solution we have fully integrated with the Cisco Talos who sets is always up to date through our solution now security for multiple sites go straight in the you know behind us behind the same EPC of multiple VPC they can all be achieved using SLI based routing and I will actually go over in the next use case deeper into that that this will centralize in security across multiple sites in the same region now these weaknesses actually can also be cross account we know a lot of customers we are talking to they use multiple AWS accounts to segment that infrastructure for various reasons now the security teams can quickly discover the apps using names or user defined tags and define the security policy for those applications and they can go live with the relevant security policy ones defined in actually minutes right versus handling you know auto-scaling templates there are forms stuff with multiple vendors dealing with licensing and everything right now in our solution we can also deploy a similar clusters in different regions they can all share the same security policy all of this programmatically or with a few clicks right so this is where we define as security follows the applications wherever they run administrators define their applications using the define using their user-defined tags they associated the light security policy being worn for each of their applications now if the same application appears in a different AWS account or a different creation in the same account right we will proactively create a services vqc and create the final custer's hokum for the transit gateway locally and modify the dns all of this fully automated so that your applications are always protected ok so this is the last use case I wanted to talk about now one thing to do notice you know assuming of cloud application architectures are highly variable in nature right now applications are being built today through many mechanisms including the classic VM based behind a load balancer containable deployments as well as servers and other pass architectures now in such a variable app environment enforcing a uniform network security strategy to secure their applications is a huge challenge for our customers vault X is highly suited for these kind of environments now what your thing is a centralized security model you know you'd apply a deploy a stack of products cloud file clusters in these multiple daisies and we are protecting all the applications behind the same you know the ferry cluster this is done through SMI based routing each application has an identity and that identity is both the you know the DNS as well as the s name of the service they are implemented we support SMI base loading such that all traffic for multiple applications can be routed and you can define different security policies for each of those applications and once this is all done you can protect your applications here's a network you know the workloads both in the east-west use case where traffic is flowing from one application to another application in the same environment as well as traffic flowing from the Internet to the applications and vice-versa the egress ingress and east/west are all fully clever covered we also support layer seven rate limiting for api-based applications and one more thing which we you know which we work with customers is we enable Alfred firewall advanced l45 one which goes beyond security groups basically micro segmentation based on user defined tags for their access policy okay now I will handle handover to you Thank You purveying now if you'd like to learn more you can actually try Baltics sandbox with the 14-day free trial and it's available on the AWS marketplace you can also visit Val tix.com as well for more information and I believe that concludes our discussion today so I'd like to thank our panel for their time and thank you to our listeners for joining us today have a great day bye bye

Channel: Valtix

Views: 1,670

Keywords: AWS Transit Gateway, Network Security, Cloud Security, amazon web services, amazon vpc peering, amazon vpc, amazon vpc explained

Id: z7u5lGhJfrs

Length: 38min 40sec (2320 seconds)

Published: Mon May 25 2020