Cisco ASA Firewall Fundamentals in 1.5 hours

[Music] firewalls are a system that has rules to control inbound and outbound traffic on a network in this section we are going to learn about some of the different types of firewalls that can be deployed on a network firewalls are used as an enforcement point between trusted and untrusted networks so if you only want to allow email and web traffic to an untrusted network then you would configure a firewall with rules to only allow those types of applications firewalls are most commonly used between internal networks and the internet so when you get a router from your service provider or from the computer store it's typically going to have firewall capabilities built into it so as your gateway device facing the internet it'll help to prevent traffic from getting onto your network from the internet one of the main jobs for a firewall is to know where traffic is sourced from so if i go to google.com from my home network my firewall is smart enough to allow the return traffic back through the firewall to my computer but if something was sourced from the untrusted internet towards my home network the firewall would block the traffic proxy firewalls can be used in the forward or reverse direction traffic is redirected to the proxy firewall for inspection proxy firewalls are useful if you need to control traffic within a point in the network that does not have an inline firewall application firewalls have the ability to control traffic at the application level with how dynamic traffic is nowadays and with all the different types of applications application firewalls are required for deep inspection to block or allow traffic at the application level personal firewalls are applications running on computers that can be configured for ip and program rules personal firewalls are so important because users may not always be protected by a central firewall on a network so as long as the user at least has their personal firewall running they at least have some type of protection on any network that they join firewalls can be stateful or stateless stateful firewalls keep track of the state of connections while stateless firewalls do not making stateful firewalls the preferred option firewalls can be a closer eye on what is traversing its zones when it can keep track of connection states state tables are used to track the current state of each connection this allows the firewall to permit or deny traffic based on if a connection is established and from where traffic originates from with firewalls a tcp connection is considered to be established after the syn synack and ack exchange is completed during the tcp three-way handshake with stateful firewalls if a connection is sourced from a trusted zone to an untrusted zone the return traffic is permitted since the connection is in the state table and was initiated from a trusted zone however if traffic was sourced from an untrusted zone like the outside and there is not a rule to permit the traffic inbound then the traffic will be denied cisco asa firewalls are at the core of the cisco security suite in this section we are going to learn about most of the cisco asa firewall features here is a list of some of the asa models that are available today from home and small business models all the way up to enterprise 5585x's the asa product line has a lot of models to choose from all right so now for the fun part we're going to start configuring an asa in the lab but the first thing we need to do is to connect a console cable to the asa's console port this will allow us to serial into the asa for the initial device setup as we learn asa command line you will come to find that some of the cli commands are similar to ios switch and router commands but for the most part it is like learning a new language and can take some time to get used to let's start by configuring some basic settings when you log into an asa for the first time you're going to be at this prompt if you type enable and just hit enter it'll get you to the privilege prompt asas do not have a enable password by default so you just hit enter we're going to say no for anonymous error reporting and now we're ready to start configuring our asa our main objective at this point is to get it ready to be managed over the ip network so we're just going to configure it enough to where we can manage it remotely and then once we can ssh or https to the firewall then we can make the majority of our configuration changes so we'll give it a hostname for ssh we of course need a domain name then we'll add our local user accounts that we'll use to log in for console ssh and https access in the real world i would not recommend using cisco as your username i'm just doing it that way in the lab to make it easy and i'd probably use a better password than super secret one two three now we'll enable ssh we'll set it for version two and then we have to configure what networks we're going to allow to access the ssh terminal so this is the same as doing like a vty access list on our ios routers and switches and you see that i have management after my networks well you have to specify the name of the interface which we'll get to later on so http is https access we enable https access with the http server enable command and then of course we have our http network access here we're going to set our aaa authentication parameters for ssh https and console connections specifying the local keyword says that we're going to use local user accounts then of course we want to make sure time is accurate so we'll set our our time zone information one thing that's weird with asas is to look at our ip interfaces it's show interface ip brief instead of like routers and switches which is show ip interface brief so here's the ip interfaces that we have available for us to configure on the lab you'll see that there's actually a dedicated management port on the bottom there of management zero zero and that's the port we're going to use for our management connectivity say show run interface just to see what it looks like so it's set to management only so management interfaces you can you can say management only on the interface to make it only allowed for management communication and then we'll learn more later when we configure our non-management interfaces that the name of command is required to assign our interfaces to security zone so this is saying this is part of the management zone and then of course we have a security level that defines what traffic is allowed between different interfaces based on their security levels we'll give it an ip address of 10.0.2 slash 24. that's our management network make sure we can ping our gateway and we can so we now have basic connectivity out of our management port i like to set the management security level to 99 so we see we have no routes currently so that we can access our management network from different networks we're going to add a static route out of our management interface to the lan so with asas instead of iprout and then the network and next hop you say route the name of the interface that you want to use to route out of then the destination network and next hop so it's a little bit different than we're used to for switches and routers a few more things we want to configure for the initial setup to follow some management best practices we want to make sure that we have logging enabled i like to set my logging level for my buffer to debugging and then my logging trap to log to a remote syslog server to informational and then we'll point to a remote syslog server out of the management interface for remote logging so that's really critical you want to make sure that your firewall not only has local logging setup but also remote logging so you can troubleshoot network or security issues then we want to make sure we have accurate time for correlating events so we'll so we'll make sure that we synchronize to a ntp server so our time is always accurate then i like to turn off snmp services if i'm not using them on my firewall obviously that can be a big vulnerability and then we'll throw a banner on there as a warning to unauthorized users so now that we have an ip address configured on our management port we should be able to remotely access the firewall via the ssh protocol with our putty application or via https with the asdm application asdm is a gui application that you can use to manage your firewall and if you're not big on using the command line then it's a great option for configuring and monitoring the firewall so we'll launch our putty application that you can download for free from the putty.org website put in the ip address of our firewall and login with our local user name and password and we should have ssh access to the firewall so here we go enable put in our enable password and now we are connected over the ip network to our firewall the first thing i like to do is to upgrade the firewall software first you want to run the dur command to look at our directory and the asas disk 0 is going to be where you're going to store your software images so i like to make sure that we have enough space on the firewall first so looks like we're good on space we'll run show version just to see what our current version of software is to get an idea of how big of a jump we're going to make depending on the software version you might have to do multiple software upgrades instead of going directly to the version you want to to be on but we're running pretty new software here so we're i think we're good as far as that goes i'm going to go to cisco's download page and just type in asa then i'm going to select the asa model that i'm running in the lab to make sure i select the right software image then we're going to download the device manager software i'll just grab the latest version of it so this is the asdm image that we can download from the firewall to manage it via https so we'll take that then we'll go back to the other asa images and we're going to download the asa system software image now that i have my images downloaded i place them in my ftp folder and i'm going to copy the images from my ftp server over to my disk zero directory on the firewall and then after we copy the images over will tell the firewall to use the images on boot up to upgrade the software so copy from my ftp server to disk zero let that run there we go now the the main asa image has been successfully loaded to the firewall now we'll load the asdm image to the firewall that we also downloaded now we have both of our images on the firewall one thing i like to do is to check the md5 hash on the software image that i uploaded the firewall and make sure it matches the hash from the download on the website which you were able to see that by hovering over the image on the website you can get the hash so i like to paste the hash in on the command line and then if you run verify md5 and then the path to the image you can have it do an md5 check and and just kind of eyeball and make sure that the hash looks the same so my hash looks good so now i know my software image is not corrupt from the image upload to the firewall so now we have to tell the firewall to use our new software so we're going to say boot system and then the path to our main asa image and then we're also going to have to tell it to use that asdm image so we'll say asdm image and then the path to the asdm image so now our software is uploaded we told the firewall to use the software or we'll save the configuration and then reload the firewall and then once it boots up it should load the new software and be upgraded so after about five minutes or so your firewall should be booted you can get a ping going to it just to know when it's actually back online so now i'm able to successfully ssh back into it and then when we get into it we're going to want to run show version to verify if we're running the new software so we see that we are indeed running the new software that we wanted to upgrade to for the system image and asdm now we're ready to install the asdm software to gain gui management of the firewall to download the astm application you can actually https to your firewall once you connect you'll be able to download the astm software right from the firewall so we'll say install asdm it makes you authenticate so we'll put in our local username and password that we added to the configuration then it's going to ask us to run or save the application will run it hit run again if you have to next next and install it does rely on java so if you do have issues you may have to upgrade your java application i actually already have the application installed so i'm just going to launch it put in the ip address of our firewall and then our username and password to connect to it alright so our asdm is loading and now here we are in the asa astm application so that looks good now we're ready to proceed with our more advanced configuration tasks now that we have our software upgraded we have basic ipconnectivity to the firewall via ssh and with the asdm application now that we have some basic settings configured on the asa we can start to provision it for the interfaces that will be connected to the firewall most firewalls at a bare minimum at least have an inside and outside interface these zones are created with the name of interface commands once the zone names are set then security levels are required to let the firewall know which zones are trusted and untrusted the security level range is from zero to one hundred the lower the security level the less trusted the zone is so we always want the internet facing zone to be set to zero and the internal facing zone to be 100 security levels control where traffic can be initiated from so for example by default all traffic from a security level 100 interface would be allowed to talk to a security level zero interface the opposite holds true for a lower security interface to a higher security interface so if traffic is sourced from a level zero zone destined to a level 100 zone it is denied by default unless there is an access list rule that permits the traffic next we of course need ip addresses assigned to the zone interfaces to be able to provide ip connectivity finally we need to add a default route using the outside zone as the egress interface so that the inside zone can route through the firewall and access resources on the internet now we'll jump back into the lab and we'll provision our lab asa with these interface parameters all right so we'll go to configuration mode paste in our interface script in our default route so you'll notice that when we named our outside interface outside it said that the default security level for interfaces named outside will be set to zero and then anything with inside is set to 100 so by default the firewall is smart enough to know what security levels to set interfaces to based on your name just to show you if we named an interface dmz it would by default set it to a security level of zero dmz should actually be set to 50 this way the dmz can talk to the internet but it can't talk to the inside since you're typically going to have public facing devices in your dmz you want to keep it in between the inside and outside so now that we have our interfaces configured if you do the command show interface ip brief i can see my outside and inside interface we'll go ahead and enable those but the no shot command just like we would on a switch or router looks like they're both up i like to run the command showrun route to look at my static routes i have configured so we have our default route going to our provider next hop let's make sure we can ping our provider next top and we can then we'll see if we can ping the internet and we can so now we have internet access out of our outside interface we're not going to be able to browse the internet yet from the inside because we haven't set up any adding which will be configured in a later section we don't have any routes to the inside in this lab in the real world you would probably have some type of route to the inside so in the lab here we only have one connected network to our inside interface in a big network you would have a core that has all of your gateways and then the core would have a default route to the firewall and then the firewall would have an inside route with the core as the next hop to get to all the internal networks you can also run the command show route the equivalent to show ip route on a switcher router and you get the same output that you would get on a switcher router just a different command to get your route table output now let's take a look at what our interface configuration looks like in asdm right from the home page of the asdm application you can see your interface status we have our inside outside management interface here you also get a traffic counter as well as the link up down status if you go to configuration and then interfaces within the device setup option you can manage your interface configurations from here as well if you hit edit you can change the ip address enable or disable the interface and even change parameters like speed and duplex we even have the ability to add a brand new interfaces from this page so we would first select the physical interface we could assign a vlan tag if we wanted to do sub-interfaces and all the other interface parameters you can also do some interface monitoring from the asdm if you click the monitoring tab and then go to interface graphs if we select an interface we have all these different graphs to choose from no firewall would be complete without access lists typically asa access lists are going to just be inbound and on the outside zone interface mainly to override the security level default drop actions to permit traffic to public facing services within a dmz best practice with firewall acls are to only allow what is necessary so for example if you had a web server in a dmz that needs to be accessed from the internet then you would only allow web ports like http and https in the access list so here you can see the example configuration we're adding a dmz interface to our lab asa with this access list configuration just to show you how you would typically use access lists in the real world so here in our access list example we have our access list entries that say what is permitted or denied in the access list and then to actually apply the access list we assign it to a zone with the access group command now we'll go to the lab asa and apply these configurations okay so we're in the lab asa we'll paste in our dmz interface and access list script so i'll just say showrun interface g02 so we now have a dmz that we can utilize for our lab configurations i'll enable that interface okay so now we have this outside access list i like to run the command show run access list so here's our access list entries one thing that's hard to wrap your head around when you go from configuring access lists on routers and switches to firewalls is that you don't assign the access list to the actual interface we're assigning it to a zone so if you run the command showrun access group you can see which access lists are assigned to your zones so with this access group command we're saying apply this access list name inbound on our outside interface so when traffic is sourced from the internet from the outside of our firewall destined to this ip address in the dmz it's going to permit tcp traffic destined to port 80 and 443 and then all other traffic will be denied to configure access lists in the asdm again we go to the configuration tab firewall and then access rules and you can see the acls that are laid out for each interface typically we don't care about traffic source from the inside entering the firewall our main concern ends up being for things coming in from the outside dust into our firewall's public interface so we see we have three rules on our outside first we're permitting traffic destined to our web server for port http and https and then we have a deny any at the end of our access list even if you didn't have a deny statement in your specific interface rules there is a implicit deny just like for a router or switch access list you can see down below you have a nice visual representation of what the access list is accomplishing and this can really help when you're trying to visualize what direction your access list will have to be applied to private i p addresses are not routable on the global internet network address translation can be used to translate private i p addresses to global routable public i p addresses nats are a very important part of security as a network security engineer nats are a huge part of daily configurations and troubleshooting in this section you are going to learn about the different types of gnats that can be configured on cisco asa firewalls static gnats are used for one-to-one mappings between ip addresses this is the type of nat that would be used for public-facing services like web servers most companies own a block of public ip addresses that are allocated for public-facing devices so if i need to make a ftp server reachable via the internet i would pick a public ip out of the range i own and configure it as a static nat to the private i p address of my internal ftp server that is secured behind a firewall the newer most common way to configure static gnats is something called object gnats with object gnats we're creating ip address objects for the public and private ip addresses that are used for the nat and then the network object that defines the internal private ip address we add our nad statement within that object let's talk about how this nat configuration works so you'll notice that after the net command we have dmz comma outside that's defining the source and then destination zone for this traffic flow so when traffic goes from the dmz zone to the outside zone this internal host ip will be the original source and its translated source will be this web outside public ip object and going in the other direction the opposite is true so if traffic were to be sourced from the outside destined to our outside object which would be the original destination the translated destination would be our inside private ip address object we're back in our lab asa firewall to configure our one to one at first we're going to configure our objects for the public and private i p addresses that will be used for the one-to-one mapping so i ran showrun object to show all of my network objects i have configured so we have our outside object that is tied to our public ip address and then we have our inside object tied to our private ip address for our internal server and these network objects that we have here they can be used for more than just nat configurations they can also be used for configurations like access lists so instead of writing access lists based on ip addresses we can actually base them off of objects now we'll configure nat for our inside object and since this iphost is a part of the dmz zone i'm going to want to reference that zone in my nat configuration so here within the inside objects configuration i've added this nat rule this rule is saying that we're going to nat traffic for this object that sources from the dmz zone destined to the outside zone to this web outside object address which of course is our public ip address and then as we mentioned previously in this lecture the reverse is also true so anything destined to this object source from the outside destined to the dmz will be translated to this ip we can run the show run that command to see all of our configured gnats and then for verification we can either run show nat or show accelate to see some statistics on our configure nat rules next we have dynamic nats dynamic gnats are typically used for outbound user connections to the internet a pool of public ip addresses can be configured as a nap pool that can be shared by multiple sources each new connection to the firewall can use one of the ips out of the nap pool the issue with standard dynamic nap pools is that only one public ip address can be used at a time so if a single host needs more connections on the internet than the amount of addresses that are available then the pool of public i p addresses would not be sufficient to configure a dynamic nat on an asa firewall you can create a nap pool with a network object which would typically be a range of public ip addresses and then you would create an inside network object for the subnet that would be utilizing the nat pool and then of course we add our nat command within that object i'll paste in our script into our firewall so now we have our new object for our nat pool and then the network that resides on our inside zone is defined by this object we run show run nap we see that now in addition to our one-to-one nat for the dmz zone we have a generic nat for inside users to use so that they can be added to public ips for internet access the key thing to understand with that dynamic gnats is that it doesn't matter what ip the inside hosts getting added to because nothing on the outside needs to point directly to the inside hosts so unlike the one to one static net mapping we can dynamically be added to random public i p addresses as long as the return traffic for the inside initiated connection makes its way back to the firewall that's all we care about to solve the limitation of dynamic pool exhaustion pat or port address translation was introduced pat has the ability to use port numbers in addition to ip addresses for its mappings a single public ip address can accommodate over 65 thousand nats instead of only one one compared to dynamic nat each nat is mapped to the first available pool address with a dynamic port number these port number two ip mappings are tracked in the nat table so that the nat device can send the return traffic to the correct host when one of the ips of the pat pool has exceeded its limit of port translations then the next available ip in the pool can be used pad is the most common method of nap for allowing internal user devices to access the internet via public ips and this is what you would see in the real world to configure a dynamic pat on an asa firewall it's actually the same concept as a dynamic nat except we have the pathpool keyword after our dynamic statement internet line within our inside object so we'll go in and paste in our pat pool so you can see that with our dynamic nat it looks almost the same except we're missing the pat pool command here this is what defines the naf as being a port address translation pool our last type of nat is policy based nat policy based gnats translate addresses based on policy rules conditions like destinations can be used to determine what address will be used for the nat for example if you look at our nat table here we have it so if an inside source is destined for the ip address 4.2.2.2 then we'll translate the source to our dot 12 address and then if an inside host is destined to 8.8.8.8 based on that condition we're going to translate the source to the dot 13 ip so now you can see how you can choose which translation to use based on certain conditions here's an example of a policy nat configuration for an asa firewall so this that's saying when we have the original source of this inside object the 10.1.10.0 network we're going to translate its source to the network object ip12 if this object is the destination and then the same goes for the second line except it's a different set of objects so there we go we pasted in our script we have all of our new objects and then our policy nat defined all right now that we've got to see the nat configuration from the cli we'll log into the firewall with asdm and look at the nat configuration in the gui so we'll go to configuration firewall and then nat rules and now you can see what our nat rules look like in the asdm so one important thing to know is that in the order of operations it's going to be top down so our object gnats are going to be at the end of our nat rules with our single line nat configurations up at the top one thing cool about the astm is you can use this packet trace feature and we can say okay for this source ip going to this destination ip address and with these port numbers what would happen to this traffic flow if it went through the firewall with our configured rules hit start and we see it checks the route lookup the nat configuration and ip options and we see finally that the packet would be allowed if it went through the firewall and then if we hit this nat drop down option you can see the nat that this traffic flow would have matched so we see that just as we would expect we would match our last catch-all nat rule for our dynamic pat phase can operate in two different modes routed and transparent routed mode would have layer 3 interfaces while transparent mode would have layer 2 interfaces 99 percent of the time i see asas in routed mode and it is not as common to use transparent mode a use case for transparent mode would be if you had a lan segment that you wanted to inspect traffic on that had no routing capabilities then you could use transparent mode to enforce traffic at a layer 2 level routed mode is the default mode to switch to transparent mode if you need to you would use the global configuration command firewall transparent essays can be broken up into multiple logical firewalls if they are placed into multi-context mode when asas are in multi-context mode one physical firewall can allocate specific interfaces to multiple logical firewalls for high security networks it may be required to force certain networks through dedicated firewalls for additional security to enable multi-context mode on an asa you enter the command mode multiple then after the asa is restarted it will operationally be in multi-context mode once in multi-context mode there is a system configuration mode that is used to manage contexts and interface a location once contacts have been created in system mode you now have multiple virtual firewalls running on one physical appliance you can access each context configuration by entering the command change to context and then the name of the context once you change to a context you can manage the virtual firewall configuration for example if you wanted to add an access list to your finance virtual firewall you would change to that context configuration and then configure it just like you would a completely different firewall in addition to the context that are added within the system configuration by default an admin context is created the admin contacts can be accessed by entering the command change to context admin the admin contacts configuration is used for management features like aaa snmp and logging to switch back to system mode you can use the command change to system and that will take you back to the base configuration prompt here we are logged into one of our lab asas that happens to be running in multi-context mode you can run the command show mode to confirm your firewalls mode and as you can see we're in multi-mode there is certain licensing that is required to run in multi-context mode if you run the command show version on your firewall you can see how many security contacts your firewall is licensed for so for this one we could have up to five logical firewalls so currently we're in the system mode if we enter the command change to contacts admin that now takes us into the admin context go back to the system mode all right so for this lab we're going to create a context we'll go to configuration mode and we'll say context and then the name of our context we'll just call this context lab and now we've created the lab context and we can now allocate interfaces to the context allocate interface the name of the interface which is g2 and now if i run show run context we see that we have our admin context this test context from the earlier lab and then our lab context i'm actually going to delete this test context now that we've created this context and we have an interface assigned to it we can go and configure the context by entering the command change to context and then the name of our context which is lab i miss one important step when you create your contacts you have to give it a configuration url so that's where it's going to store the contacts configuration now that i have my config url applied to the context i can now switch to the lab configuration if we say show run it has some default settings and then you'll notice that we have this interface within our contacts configuration that we can modify so now you can see that you only can configure interfaces that have been allocated to your context and then i'll switch back to system with change to system and then we can go back and start to create more contexts modular policy framework is a method for applying different security features with class maps and policy maps similarly to applying qos and zone based firewall configurations on a ios router once traffic is matched with a class map a policy map is used to apply traffic policies like application inspection quality of service and ips redirection asas by default have a modular policy framework configuration we can run the command show run class map and show run policy map to see our existing modular policy configuration so this default list is basically saying match all traffic and for that default class of traffic we want to apply these inspection rules i usually don't tweak too much stuff in my policy maps the main reason in the real world that i adjust these are if there's issues with certain protocols like we usually want to turn off esmtp inspection because it can break email services so we'll go ahead and shut that one off from its additional inspection for that protocol i've had to disable the skinny inspection and outside of adjusting the default inspection rules to fix application issues then i'm usually adding a class map to redirect traffic to a net flow destination or for an ips sensor and if you want to confirm matches on your policy map then you can run the command show service policy to configure the modular policy framework in the asdm we go to configuration firewall and then service policy rules and this is where you'll find your policy map and class map configuration and just like i showed you in the access list video if you click this diagram button you can see a visual representation of the policy map actions in active standby mode one asa is active operationally configuration and connection state changes are replicated to the standby asa for stateful failure recovery if an active asa fails and goes down the standby asa will go active and take over the role as the primary asa one important thing to understand about high availability asa firewalls is how they need to be interconnected each firewall must have the same zone interface connections this is required so that if a firewall were to fail it still has the same physical connectivity as the active firewall in addition to our zone interfaces firewalls must have what's called a lan failover interface this interface is used for hello messages between the firewalls so that both firewalls know the status of their peer it's also used for configuration replication and synchronization so if a configuration change is made on the active firewall it can use this interface to replicate that change to the standby firewall in addition to the lan failover link you can optionally have a state failover link this link is used to pass connection state information so that the standby firewall can support existing connections that were previously on the active firewall the state failover link should be a dedicated link separate from the lan failover link but it can use the same link as the lan failover link so you could add both of these failover roles to a single link between the firewalls before we configure the actual failover commands on our firewalls we want to have standby ip addresses assigned to all of our interfaces this ip is pushed to the standby unit and can be used for interface monitoring between the primary and secondary firewalls it can be any available ip address on the interface's lan if possible you want to make it the next available ip address after the primary ip to configure failover between our asa firewalls we have to configure failover parameters on the active and standby firewall the first step is to enable failover globally then we define which unit will start off as the primary firewall and which unit will be the secondary firewall then we have to assign an interface to be a land failover link then there's some timers you want to have a failover key for security the failover replication http command is what enables state replication for http traffic then we define our stateful failover link which we're going to follow the best practice in this lab and have a dedicated link for land failover and a dedicated link for state failover and then ip addresses are required for the communication between the land and state interfaces so we need to assign ip addresses for those interfaces and these can be non-routable networks because the layer 3 communication is only going to exist on your directly connected interconnections between the firewalls now we'll jump into the lab asa firewalls to configure active standby failover okay so we'll start on the firewall that we consider to be the primary out of our two firewalls we'll paste in our failover configuration after you paste in your failover configuration you may lose connectivity to the firewall as it goes through its negotiation to see if there are any other aha firewalls connected i'm logged back in and i ran the command show failover history and you can see from the time i pasted in the failover configuration you can see the different states the firewall went through while it negotiated next i want to add secondary ip addresses to all of our ip interfaces run the command show run interface i have a standby ip assigned to my management address but now i'm going to want to go through and add standby ips to all my active ip interfaces i'm just going to pull up a notepad paste it in and then i'm going to use the next available ip address let me add the command standby and the ip address that two and then we'll use that two on this network too when you configure failover if you start with the firewall that's considered to be the primary you'll just add your standby addresses to its configuration and now our primary firewall is configured our second firewall that we add to the failover pair would be considered to be our secondary firewall and since we already configured these interfaces on the primary we don't have to configure any of these ip interfaces to the standby firewall it'll retrieve these parameters through synchronization once it communicates with failover to this primary firewall okay so on the secondary firewall we'll configure failover globally define this unit as being the secondary unit i'm going to say failover we'll define our lan interface that's going to be gigg07 configure our state link as soon as i added the lan failover ip address information the firewall started to run their discovery process and were able to detect each other so you can see that this firewall detected the active mate which was the primary firewall that we previously configured and then it started to retrieve configuration replication from its active mate so the primary firewall so now you see our hostname changed automagically and if we run show run you see that it's retrieved the full configuration sync from the primary we'll log back into the primary firewall now and to verify our failover status we can run the command show failover we see that the host that we're currently logged into is considered to be the primary and active firewall that's what it should look like normally and then our secondary unit is standby and ready so that's exactly what we want to see on the secondary firewall this tells me that we're running good and failover is configured properly once you have failover looking good it's always good to test it so we can actually run a command on the standby and tell it to be the active firewall and then that'll force this primary firewall to be the standby just as a test and then we'll switch it back so i'll get an infinite ping going here to the primary firewalls management ip and we'll see what happens and how quickly we fail over to the backup unit so i'm going to run the command failover active on the standby unit so this should tell the standby unit to take over as the active firewall of course i'm going to lose my connection from that session it looks like we did not lose any pings though so now if i log into 10.0.2.10 so now i'm logged into the secondary that's now the active firewall and i run show failover and you can see that sure enough we forced a failover between the firewall so now the secondary units the active and our primary is standby and we'll run the command failover active and this will make the primary the active firewall again and you can see that again we did not even lose a ping so you can see how fast asa failover works and there you go so now we're back to normal failover can also be monitored and configured from the asdm right from the home page we see it we have a failover status section here if you click the details option it links you right to the monitoring page where you can monitor your asa failover status we can even send some commands to the firewalls right from here to configure asa failover from the asdm if we go to configuration device management and then there is a high availability and scalability section there's a wizard you can launch if you want to configure failover that way or you can go to the failover configuration area asa firewalls can be configured with advanced firewall services for additional protection botnet traffic filtering is a service that can be enabled along with a license to protect against botnet and other suspicious activity a dynamic database hosted by cisco updates botnet enabled asas with blacklisted domains when clients try to connect to sites that match a site from the dynamic database the asa can log and drop the connection attempts the latest and greatest asa firewall services are classified as next generation firewall services these services include ips url filtering and amp now that cisco has bought sourcefire and revamped their security solutions all of these services are available onboard cisco asa firewalls vpns give us the ability to securely connect network devices over untrusted networks vpns are made up of security concepts like encryption hashing and authentication there are two types of vpn access site to site and remote access vpns site-to-site vpns are used to connect multiple networks between remote branch offices and data centers these tunnels are formed between devices like routers and firewalls that have cryptography abilities remote access vpn is for individual remote users vpn applications and secure web browser sessions can both be used on a mobile device like a phone or laptop to establish remote vpn tunnels now we will take a look at how an ipsec tunnel is formed for both types of tunnels first the traffic that needs to be encrypted must be defined this traffic is called interesting traffic you may only want to send certain traffic over the vpn tunnel interesting traffic is defined with an access list on the vpn gateway internet key exchange is the protocol used to set up security associations in the ipsec protocol suite ike is broken up into two phases in phase one hashing authentication dh group lifetime and encryption are negotiated once the phase 1 policies have been negotiated the peers run the diffie helmet exchange to create shared secret keys then the vpn devices will verify their peer identity with authentication and after these exchanges a secure phase one tunnel is built for future communication next phase two parameters like hashing lifetime and encryption are negotiated with transform sat configurations then finally an ipsec security association is created for the interesting traffic and data can be encrypted and decrypted between the vpn gateways vpn tunnels can be set to use two different modes transport mode and tunnel mode let's compare the two in transport mode only the payload of the ip packet is usually encrypted or authenticated and it requires less resource overhead tunnel mode is the default mode for cisco devices in tunnel mode the entire ip packet is encrypted and authenticated it is then encapsulated into a new ip packet with a new ip header once vpn tunnels are formed there are a few different options that you should be aware of for the exam the first is hair pinning hair pinning is when vpn traffic is routed back out the interface on which it was received on this type of traffic flow is necessary for hub and spoke vpn topologies another important vpn option to know is split tunneling split tunneling is simply how a remote access vpn defines what is interesting traffic an acl is used to specify traffic that should be encrypted or sent in clear text remote access vpns have many options to provide additional control to endpoint devices always on vpn is one advanced feature that forces remote vpn access connections to always be connected to vpn this allows enterprises to maintain constant control over company-owned assets the last vpn option that you should know for the exam is nat traversal nat traversal is used when a vpn connection is established through a nat device normally ike uses udp port 500 but with nat traversal udp port 4500 is used remote access vpn used to be accomplished primarily with ipsec vpn client applications this is considered to be the legacy remote vpn access option nowadays ssl vpn is the way to go one popular method of ssl vpn is clientless with clientless vpn no client application needs to be installed on endpoints a user can simply launch a web browser type in the vpn url and log right in from their browser once connected all traffic is proxied through the vpn gateway through a https session let's hop into the lab and configure a client list vpn setup on a cisco asa with the asdm management software when you're deploying a ssl remote vpn solution the first thing you should do is get a real digital certificate this is required so that remote vpn users do not get a certificate error when they try to connect to get a valid certificate on our asa firewall for vpn first we have to create a certificate signing request on the asa once the csr is created we then export it and upload it to our certificate authority provider then the certificate authority will sign our certificate we'll then install it back in the firewall and we will have a trusted certificate to use for our vpn connections to create our csr we go to remote access vpn certificate management and then identity certificates and click the add button so we have to give it our fqdn name our key pair size and then we're going to save the csr to a file locally on our pc so we've successfully exported the csr now we'll take that csr upload it to our certificate authorities website have it signed you'll want to open up the csr in a text reader copy and paste the csr information onto your certificate authority's website will then download the sign certificate and upload it to our firewall to complete the certificate installation in addition to installing the signed identity certificate we also want to install the root certificates of our certificate authority usually the root certificates from the provider will come with your identity certificate or you can download them from their website now we have to tell the firewall to use this certificate on our outside interface so we'll assign the certificate to the outside interface now it knows that it can use this certificate for https connections on the outside interface now we're ready to configure our clientless vpn options so we'll launch the client list ssl vpn wizard makes it really simple to set up your vpn first of course we have to name it select the interface that will be active for ssl vpn connections i always like to give my vpn configurations a group url so that connections can be made directly to this policy with that url and we're just going to use local username and password for this but of course you could use an external radius server if you wanted to authenticate to an external data store then we can make a new group policy for some of our configuration options and there we go so we've created our clientless vpn configuration we have the connection profile and the group policy that was created if you go into the portal configuration you can do a lot of customization for the portal that is used by the ssl vpn users you can customize it of course with what the title is and the image the coloring scheme you can set which applications are accessible by the vpn client we can also go into our group policy configuration and set things like the home page that the user will get redirected to and internal links that can be accessed directly from the vpn portal okay so we'll test our client list vpn connection i put the url to the firewalls vpn interface in my web browser you can see the web browser trusts the certificate you can look at the certificate details and see that it was signed by godaddy our local credentials in and now we're logged into the ssl vpn portal you see we have our link to our wireless lan controller we have options for ssh and terminal services i'll go ahead and click on my wireless lan controller link test that out so there you go we are successfully connected to our internal wireless lan controller with our https client list session through our vpn gateway you could launch an rdp session directly from the vpn portal so there you go we now have a remote desktop session that's being encrypted through our clientless vpn connection to monitor and troubleshoot our client list vpn connections in the asdm we can go to the monitoring tab and then go to vpn change the filter to client list ssl vpn then we see our ssl vpn sessions we can see the group policy that's applied to the user username and their public ip address we can hit details here to get more information about the connection in addition to asdm we can also go to the command line of the asa and run the command show vpn sessiondb and webvpn and you'll get a command line output of your clientless vpn connections next we have cisco's anyconnect vpn solution anyconnect is pretty amazing you could spend a whole year playing around with all the different features that anyconnect has to offer it is a client vpn application that can run on laptops and mobile devices unlike clientless vpn data can be transferred directly between endpoints through the encrypted tunnel so once you're connected it is truly like the remote endpoint is connected locally to the network back in the asdm we're going to run the anyconnect wizard just like we did for the clientless vpn configuration give it a name and associate it with an interface which will of course be our facing interface anyconnect can use ssl or ike version 2 so you have the option here to select which protocols you want to be allowed for this anyconnect profile you have to select an anyconnect image file the anyconnect image can be downloaded from the cisco website and then uploaded to the asa we'll just use local credentials here just like we did in the client list vpn configuration but typically you would have an external radius server being used for authentications you need a dhcp pool for anyconnect the remote vpn clients will actually retrieve an ip address from this pool and those ips will be used to communicate over the vpn tunnel we want to make sure that we exempt nat translations for this traffic also known as known at and that's it we've created our anyconnect configuration now let's take a look at what that wizard is actually creating first we have our connection profile a good example of parameters you could assign with a connection profile are client address assignment and aaa connection profiles are also referred to as tunnel groups when you're in the command line configuration next we have group policies a group policy is a set of user orientated attribute and value pairs used for the vpn connections things like client configuration settings and filters can be applied with group policies split tunneling is where we define the traffic that will be sent through the vpn tunnel you can either tunnel all vpn client traffic through the tunnel or define a split tunnel acl to only use the tunnel for specific destinations in this example with our split tunnel acl we've created we're only tunneling traffic that matches 10.0 networks and 10.1 networks all other traffic will be sent locally onto the user's local lan the last anyconnect configuration options that i want to cover are client profiles client profiles are xml files that are stored on the anyconnect vpn client devices with parameters like the name of the profile as it's shown in the anyconnect application always on vpn and backup vpn gateway destinations each time a change is made to these profiles vpn clients automatically receive any updates each time they connect well now it's time to test our anyconnect vpn connection you first need to download the vpn client from the asa or cisco's website i already have it installed on this computer so here's the anyconnect vpn application we'll put in the url that will connect us to our vpn gateway and then since i have an alias set up it gives me a drop down to choose which vpn connection i'd like to use of course we want to use our anyconnect lab configuration hit okay and we've established a anyconnect vpn tunnel to our asa firewall if we select this gear icon here we can see some of the statistics for the vpn connection we see the address we received via dhcp the client profile xml file that we downloaded route details shows us what is actually included in our split tunnel acl these were added on because of a dns option but here's the 10 0 and 10 1 networks that we defined in our split tunnel acl to monitor and troubleshoot our anyconnect vpn sessions we can go to monitoring vpn and just like our clientless vpn connection we can see our anyconnect connected clients and we can do the same in the command line with show vpn sessiondb anyconnect one cool feature that can be integrated with anyconnect vpn is endpoint posture assessment with the anyconnect posture module endpoint posture assessment has the ability to scan an endpoint for things like antivirus and anti-spyware to determine if it's a compliant endpoint or not if an endpoint does not pass the posture check then it is denied access to the network or it can be remediated an example of how you could use posture assessment would be if you only wanted vpn clients to be able to connect if they had up-to-date antivirus or if you had secret files or registry entries installed on company assets that could be verified during the posture assessment i happen to have then the connect posture module running on my lab pc and you can see that it just layered below the core anyconnect vpn module if you click the advanced window button and go to system scan you can see the compliance information for the endpoint the policy server is my ice node which is doing the posture checking you can see which security products the endpoint assessment found on my endpoint the posture assessment check that i have running is if my endpoint has fire amp running then it passes the posture check and is allowed to connect to the network with full access in this video we will establish a site-to-site vpn tunnel between an asa and a cisco csr router at site a on the left we have the asa with an inside lan of 10.1.10.0 and on the right is site b with a router and local network 10.2.10.0 this tunnel will be configured via the command line on both devices but then after we get the tunnel up i'll log into the asdm on the asa and the cisco configuration professional gui management on the csr so you can see how to use the vpn wizards if you are not comfortable with the command line in the real world we would always use the command line but it can be a lot easier at times from the gui here's our command line script that we're going to use on both the asa and the router you can see that there's some syntax differences between configuring it on the asa versus the router first we will define our local and remote networks this is considered to be our interesting traffic and is the only traffic allowed over the vpn tunnel then we configure a nat rule to exclude translations between our local and remote lan networks when the vpn traffic egresses the vpn gateway's outside interface without the net exclusion traffic may match an existing nat rule which can cause issues with vpn tunnels next is the phase one policy that defines the type of authentication encryption hashing and dh group that will be used for the phase one tunnel we then need to create a pre-shared key that will be used for authenticating the vpn peers on the asa the key is applied within a tunnel group which is the same as a connection profile along with the tunnel group a group policy is also required on the asa next we will set our transform set parameters for the encryption and hashing types that will be used for phase two to tie everything together we need to create a crypto map crypto maps match interesting traffic acls set our vpn peer public ips and define the transform set protocols to activate the crypto map it needs to be applied to an interface this would normally be the outside internet facing interface once the crypto map has been activated you of course want to make sure that routing is configured throughout the network to send traffic to the firewall and out of the outside interface for traffic to be encrypted in the vpn tunnel let's start off with the site a configuration on the asa firewall okay i'm in the lab asa i'll paste in our vpn script looks like it was happy with all of the commands now we'll head over to the site b router and paste in the vpn script for that side to start the tunnel we need to send some interesting traffic across our devices here's a site a device on the asa side let's see what its ip address is so 10.1.10.11. now let's go and see what the pc's ip address is on the site b side the device over on the site b side has a p address of 10.2.10.12. so we'll see if we can ping that ip from site a [Music] there you go so that tells me that our vpn tunnel is working let's make sure that we can ping from site b to site a okay so we have bi-directional communication the first verification command i always run on asas is show crypto ice camp sa and that command is going to verify our phase 1 status on asas mm-active is the state we want it to be in for a successful phase 1 tunnel so we're mm-active for the tunnel going to site b we'll run the same command on the cisco router the output's a little bit different on routers qm idle is the final state of phase one so it's not mm-active like it is on the asa so this looks good this shows me that phase one has been successful back in the asa to verify phase two and if traffic's actually being encrypted and decrypted across the tunnel we run the command show crypto ipsec it shows our local and remote network our vpn peer ip to truly verify if the tunnel is working correctly you can tell if packets are being encrypted and decrypted so this looks perfect we're on the same command on the cisco router and we have a similar output we see our local and remote networks our remote pier and our encryption and decryption statistics now i'm actually going to delete the tunnels from the command line and then we're going to configure the same tunnel but from the gui management applications for the asa and the router so remove all of our commands on the asa and then we'll do the same thing on the router here we are in the asdm on the asa to configure our tunnel from the asdm we'll use the vpn wizard for site-to-site tunnels put in our remote gateways public ip address outside interface and then we can actually call out our objects that we created previously from the command line paste in our appreciated key we want to exempt this traffic from that translation and then next as you can see it's so easy to configure site site tunnels through the asdm wizards so this may be the preferred method for a lot of you hit finish okay we should be good next we'll use the cisco configuration professional gui management application on our cisco router here's the cisco configuration professional it's a software that you can execute on your computer that allows you to manage your cisco routers with a gui application so i've already added our lab router as a device if you click on the configure button you can see the different types of configurations that you can push to the router from the configuration professional it's actually really cool you can backup your configurations from here upload files for software upgrades if you'd like okay so now we'll configure our sitesite vpn tunnel with the configuration professional wizard we go to configure security vpn and then site to site vpn launch the selected task you can go through the quick setup wizard but we're going to use the step-by-step wizard so we have the ability to customize some of the configuration g1 is our outside interface put in our peer i p address and pre-shared key by default it has this three does policy we're going to add a new one to match the security on the asa side we'll select that proposal and hit next we also want to make a custom transform set we'll select add hit ok and next now we have to define our local and remote networks site b is 10.2.10.0 with a slash 24 mask and site a is 10.1.10.0 24. so that's it we've created our tunnel with the cisco configuration professional click finish and deliver the configuration to the router okay so we should be in business we'll go to our site pc and generate some interesting traffic to start the tunnel and we're getting replies so that's good news back on the asa if you go to monitoring and sessions under vpn statistics we can see the status of our tunnel up here you can see we have one active site-to-site vpn tunnel back on the router we can go to monitor ipsec tunnels and we get some of our phase 2 statistics and a nice green icon if the tunnel is up

Channel: Knowledge Power

Views: 12,541

Rating: 4.9839358 out of 5

Keywords: ccna, mcsa, linux, fortinet, fortigate, vpn, ipsec, ssl, decurity, network, firewall, mobile, iphone, computer science, sql, voip, engineer, oracle, database, AI, artificial inteligance, كورسات, فايروول, احمد نظمي, windows, kali linux, centos, network security, network شرح, network course, network +, network engineer, network master, cisco, sophos

Id: yvRPY1FnK4A

Length: 88min 28sec (5308 seconds)

Published: Tue Dec 29 2020