Pass CompTIA CASP Certification Exam in First Attempt Guaranteed!

All CompTIA CASP certification exam dumps, study guide, training courses are prepared by industry experts. CompTIA CASP certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

Securing Networks (Domain 1)

5. Firewalls (OBJ 1.1)

While routers can use access control lists to provide some protection and filtering for our networks, it's really a dedicated device known as a firewall that excels at using access control lists. Now, access control lists are very important for us to be able to secure our networks from unwanted traffic. A large portion of the permit and deny statements that we use and utilise in our ACLs are based on port numbers because these directly correlate with an application or service that we wish to allow or block.

Access Control Lists, or ACLs, are the rulesets that are placed on the firewalls, routers, and other network infrastructure devices that permit or allow traffic through a particular interface. These rule sets will control the flow of traffic into and out of our networks. Now, while Access Control Lists can also be used to help define proper quality of service levels inside our networks, in this particular video we're really going to be focusing on their crucial role in the security of our networks and their use inside of Firewalls.

Now, to configure the access control list on our firewalls, we're either going to be using a web-based interface or a text-based command-line interface. When configuring these ACLs, it's important to remember that the order in which they're listed specifies the order of the actions that are taken on a particular piece of traffic. Actions are always performed top-down inside of an access control list. The traffic is compared against the first rule, and if it matches the conditions for the action to be applied, it can be performed and no other ACLs will be checked. For this reason, our most specific rules should always be placed at the top of the list, with more generic rules located towards the bottom. Now, many devices support the use of an implicit deny function for their rule sets.

Other devices, though, don't support this function, and so it is considered a best practise to include a deny all rule at the end of your ACL to ensure that only authorised traffic is going to be entering your network. Finally, it's important to log the actions taken by our network infrastructure devices, like our firewalls. Any time a rule condition is met from the access control list, that action should be triggered, and it should then be logged. This includes any deny actions that are taken, including the deny all at the bottom of the ACL access control list. Rules are made up of some key pieces of information, including the type of traffic, the source of the traffic, the destination of the traffic, and the action that should be taken against that traffic. For example, in this access control list, the first entry is going to state that it allows TCP traffic from 192 to any destination IP over port 22.

Now, routers can provide basic security using these access control lists and filtering rules, but it's really our network firewalls that are most commonly going to be used for network security and bulk blocking and allowing. Firewalls can be hardware-based appliances or specialised software installed on a client or server to perform this function. The primary role of a firewall is to inspect and control traffic trying to enter or leave a network's boundary. There are many different types of firewalls, including packet filtering, stateful proxy, dynamic packet filtering, and kernel proxy firewalls. Each type of firewall is going to focus on either a more or less thorough inspection of the traffic. As with everything in network security, there is going to be a performance tradeoff based upon how deep an inspection we do. If a firewall does a more in-depth inspection, then the device can't achieve as high a throughput because it's going to take more time to go through every one of those ACL rules and inspect each of those packets.

This can negatively affect our network's efficiency and increase the network's latency. The most efficient firewalls in terms of maximising throughput are going to be our packet-filtering firewalls. These firewalls only inspect the header of the packet to determine if the traffic is going to be allowed or denied based on the IP addresses and port numbers. This type of firewall acts very similarly to a router using an access control list, and it can be placed between subnets inside a network. Unfortunately, these simple firewalls cannot prevent IP spoofing, packet fragmentation attacks, or attacks against the TCP handshake itself because they're limited in their inspection to the packet header of the traffic.

Now, stateful firewalls are going to track the status of all the connections and requests that are going into and out of the network. So in addition to the simple header inspection that is performed by the packet filtering firewall, a stateful firewall also knows if an outbound request was made from our network, and then it's going to use that to determine if it's going to accept traffic coming from a remote host back into the network. For example, when you attempt to visit a website such as Going to Diecraining.com, the stateful firewall remembers this, and then it's going to allow the return traffic coming from my web server, Deontraining.com, back to your host because it remembers that you asked for that information, and now I'm delivering it to you. A proxy firewall is going to be placed between an internal and external connection in the network, and it's going to make connections on behalf of the other endpoints.

There are two types of proxy firewalls: circuit-level and application-level. Now, a circuit-level firewall, like a socks firewall, is going to operate at the session layer, or layer five of the OSI model. An application-level proxy is going to be a deep packet inspection device that conducts a different proxy function for each type of application. At layer seven of the OSI model, for example, it can read and filter HTTP traffic differently than it would FTP traffic. Because of this deep packet analysis, though, there is a larger impact on its performance and efficiency as a firewall, allowing traffic to go through the network. For this reason, application-level proxies are best positioned in the network when they are located as close as possible to the application server that they're trying to protect. A kernel proxy firewall is another type of firewall that we need to discuss. These are also known as fifth-generation firewalls, and they're going to be placed between two systems and create connections on their behalf.

Much like many of the other firewall types that we already discussed, the main distinction of a kernel proxy firewall is the minimal impact that it has on our network's performance. Even while conducting this full inspection of the packet at every single layer, These devices should be placed as close as possible to the system that is trying to protect the inside of the network as well. Now, because firewalls are such integral security devices for our networks, they are constantly being evolved to provide us with better features and more security. There have been three such evolutions in recent years. This includes things like the NGFW, or "next generation firewall," the UTM, or "unified threat management firewall," and the WAF, or "web application firewall." All of these are going to focus on adding and optimising application and protocol-aware technologies to provide us with better security. Next-generation firewalls attempt to overcome the shortcomings of traditional stateful firewalls by creating firewalls that are application-aware. This means that these firewalls can distinguish between the different types of traffic that specific applications are sending into or out of the network.

These devices conduct a single deep packet inspection of the traffic and then utilise signature-based intrusion protection when they're installed as an inline device inside your network configuration. Additionally, these Next-Generation Firewalls are fast with little impact on your network's performance. These devices have full stack visibility over traffic and can provide granular control over traffic by developing custom signatures. Next-generation firewalls are complex devices, and they have the ability to integrate with several other security products. Unfortunately, this can lead to our organisation becoming dependent on a single vendor over time because these different firewalls are going to be configured to work with their product line. These firewalls will be much more difficult to manage than a single packet filtering or stateful firewall, but they will provide significantly more security. It's worth noting that many organisations have shifted away from Next-Generation Firewalls and toward a unified threat management firewall (UTM).

Unified threat management devices provide the ability to conduct numerous security functions within a single device or network appliance. These devices include the functionality of multiple specialised devices, such as network firewalls, network intrusion prevention systems, gateways, antivirus and antispam, virtual private network concentration, content filtering, load balancing, and data loss prevention, all within a single network appliance. These unified threat management devices have a lot of benefits as well, such as reducing the number of devices that technicians need to learn, operate, and maintain. This can help to decrease the overall cost of providing these protections, but there are still going to be some drawbacks here. The largest issue with UTM devices is that they are single points of failure.

If the device fails, for example, we don't just lose our firewall anymore; we now lose our firewall, our antivirus, our intrusion prevention system, and things like that. All of our security stack can be wrapped up in this one device, which means if we lose it, we lose our entire security stack. So our organisation needs to consider both the advantages and disadvantages of unified threat management before deciding to implement it in our architecture. Some advantages of using a UTM include lower upfront costs, maintenance, and power consumption. Because all of these functions are contained within a single rack-mounted device, they will be easier to install and configure than having to do multiple devices for each function. And they can be fully integrated, which has a lot of benefits too. The big disadvantage here is that they are a single point of failure and often lack the detail provided by a more specialised tool. And their performance is not always as efficient as that of a single-function device.

While UTM devices work well for the most part, they do utilise separate individual engines for each function they're trying to perform in their security inspections. Whereas, when you're using a NextGen firewall, you're going to be using a single, more efficient engine. And so if network speed and efficiency are your primary concerns for your organization, you want to consider using a NextGen firewall over a unified threat management device. Now, if your organisation decides to go with a unified threat management device, you're going to place it in between your LAN and the connection to the Internet, just as if it were a firewall in an inline configuration. Finally, we need to discuss a specialised type of firewall known as a web application firewall, or WAF. Now, a web application firewall is going to be focused on the inspection of the HTTP traffic, or Hypertext Transfer Protocol traffic.

These firewalls utilise specific rule sets to prevent common attacks against web applications, such as cross-site scripting and SQL injections. Web application firewalls can be installed as separate appliances or as a type of software plugin on your web server. This type of firewall can also be installed either inline or out-of-band inside your network. If it's going to be placed in line, the device is going to be placed between a network firewall and the web servers themselves. By utilising this inline placement, these devices can prevent live attacks, but they're also going to slow down web traffic and sometimes block legitimate traffic by mistake sometimes. Now, if it's placed in an outer band configuration, the device is going to receive a copy of all the traffic that was destined for the webserver using a mirrored port off of a switch.

This is going to be a very non-intrusive way to conduct web application filtering, but it cannot block live traffic if you're using this configuration. This means when you're using this out-of-the-box solution, it's really more of a detection system than a prevention system. As you can see, there are a lot of different choices when it comes to firewalls. when you're designing the architecture of your network. This includes our stateless firewalls. Stateful firewalls, proxy firewalls, and application-level proxy firewalls Kernel proxy firewalls, next-generation firewalls, unified threat management systems, and web application firewalls.

6. Configuring Firewalls (OBJ 1.1)

I'm going to show you how to configure the Windows firewall and the Mac firewall. So whichever system you're using, you'll know how to do it. Let's start with the Windows firewall. We're going to use the Windows Defender Firewall with advanced security. To load this up, simply go down to your Windows key or your Start menu, scroll all the way down to where you see Windows, Windows Administrative Tools, and then scroll down again once you click on that, and you will find the Windows Defender Firewall with advanced security.

Once you click on that, it will open. From here. You can create all the policies you want. setting up inbound rules and outbound rules, monitoring it, etc. Once you have it set just the way you like, you can actually export that policy. So you'll have it as a backup if you ever need to refer back to it. Right now, my domain profile shows that Windows Defender Firewall is turned off. My private profile shows that it's on, and my public profile shows that it's on. This means that I have the Windows Firewall enabled on both my private and public networks. In the private network, I don't allow any inbound connections that don't match my rules, but I will allow outbound connections that don't match my rules. In my public network, I have it set the exact same way.

Now, if I want to change that, I can go into my inbound rules or my outbound rules and decide how I want that to be done. Let's take a look at some of these rules. For example, we have this one here, which is SSH, which is Secure Shell. All of my profiles allow it. It's enabled for all of them. It will do an allow action, and it's going to allow any programme to be run from any address locally to any address remotely over port 22. That may be what you want to do, or it may be something you want to block. Let's go ahead and look at some other ones. We have an app installer down here that allows it to go from any local address to any remote address, protocol, and port. This type of "any, any" rule allows for a great deal of flexibility. And so this is going to allow a lot of things to go through that we might not want. Now, let's say you have a programme that you want to add to this.

Maybe you have a new web server on this machine and you're going to run it on port 80. You can hit a new one. You can then select a program, a report, a predefined one, or a custom one. In this case, if it's a web server, we would want to do it based on port 80. Then we'll click on "next." Do we want it for TCP traffic or UDP traffic? It's a web server. Again. It's TCP. There's something else that might use UDP. You can set that up. And then for what ports is that going to work—for all of your local ports or specific ports? Well, if it's a web server, it again should be on port 80, and for secure port 443, we can go next. We can allow that connection. We can allow the connection if it's secure, meaning that it has to use something like a VPN tunnel with iPSC, or we can block the connection and not allow any web traffic in. In our case, we want to allow the connection.

Then we click on "Next," and you can see which of those three networks it's going to apply to. I'm going to allow all three of them to have it applied to them, and then I'll give it a rule on Jason's web server, and that's it. Now you can see that Jason's web server is now going to allow traffic from any program, from any local address, and from any remote address over protocol TCP and on port 84, four, three. Now, conversely, if I wanted to block things from getting in, we would do the exact same thing, except we would set it up as a block or a deny. For example, I don't want to allow anybody to telnet into my network because telnet is unsecured. So I'd create a new rule and then block anything on port 23, which is TCP traffic on port 23.

And then I'll hit Next. I'll block that connection, and I'll block it for all three of those networks, and I'm going to say blocking telnet, and that's it. You can see how easy it is to set up these rules. You should feel very comfortable setting up these types of rules. If somebody says, "I want to block TCP on port 23 or I want to block Telnet," then you should be able to say, "I want to block it from this area and let it go to that area." Now one more area of the Windows firewall that I want to show you is down here in monitoring. Down in monitoring, you can see which profile is active, as I showed you before, but you also have access to the log file, and if you click on that, you'll be able to see what's currently there. What is being logged right now? Is it logging dropped packets and successful connections? Right now it's not, but we can change that if we want to. Now we can also view our active rules. This again brings us back to what those inbound rules are and which ones are actually active on this profile. So you'll notice that anything that's all or public is displayed here?

Anything that was just private or domain is not active for this particular connection. Next, we're going to configure a firewall on a Mac machine. To do that, simply go to the apple in the upper left corner and go to System Preferences from here. You're going to click Security and Privacy, and then you're going to click on the Firewall tab. You can see that my firewall is on, but I can't click any of the firewall options right now. That's because you have to unlock it by clicking the lock and adding your username and password for the admin account. Once you do that, you can turn off your firewall, or you can turn on your firewall and configure the options in here. You can block all incoming connections. You can see what applications have been allowed through the firewall. In my case, Skype and Google Drive are allowed to have connections to my computer. And then you can automatically allow built-in software, meaning Apple software, to receive incoming connections, things like iTunes and iMessage.

And you can automatically allow downloaded software to receive incoming connections, meaning this is software that you trust. And finally, we have stealth mode. Stealth mode instructs your firewall not to respond to or acknowledge any attempts to ping your network. So if somebody is doing a ping sweep of your network, my computer is simply not even in an answer. So you won't know if it's up, down, or even there. So how do we add an application to this list to allow incoming connections? Well, Mac makes it fairly easy. You click on the plus sign, you find the application—for example, my chess application—and then hit add. When you do that, it will by default allow incoming connections. Now, if I don't want that anymore, I can simply click on it and subtract it, and it won't answer up. As you can see, you don't have the same level of fidelity that you have on a Windows machine here on a Mac. To get that level of fidelity, you'd have to use the command-line firewall tools that are provided, such as PF or IPFW.

7. Proxies (OBJ 1.1)

In this lesson, we're going to discuss proxy servers, some different types of proxies, and the four different types of gateways. Proxy servers are devices that create a network connection between an end user's client machine and a remote resource, such as a web server. These devices can either be physical, hardware-based appliances or they can simply be a piece of software installed on another server within our infrastructure.

Either way, these devices provide a few distinct benefits, such as increased speed and efficiency in our networks, increased security, and additional opportunities to conduct audits. Increased speed and efficiency are gained when using a proxy server because proxy servers provide a function called web caching. Essentially, whenever a user requests a website through a proxy, it retains a local copy in its cache. Then, when another user requests the same website, instead of requesting it directly from that webserver over the slower Wan link, the proxy server can simply provide the user with the cache copy that it saved locally inside of itself. This saves time and bandwidth, and it works really well for static websites.

Now, this technique doesn't work really well when you're dealing with modern Web 2.0 websites, things like Facebook, Twitter, and Reddit, and places like this that are going to use user-generated types of content. This is because every time you log in, you're getting a personalised experience specific to that user, and this makes the caching not nearly as efficient. The second benefit of a proxy server is increased security. Now, this occurs because each proxy can be configured with a list of acceptable and nonacceptable sites, and they can then block those sites that are deemed unacceptable. So, for example, let's say an employee tries to access a website containing pornography or gambling while they're sitting at their desk at work. Our proxy server might be configured to prevent that access. Similarly, we can also block websites that are known to host malware and other content that we wouldn't want access to from our corporate networks.

Finally, proxy servers also provide our network with additional auditing capabilities since they can record each and every request that's made by the users to go out to the wide area network. These logs can then be used to determine if an employee is attempting to access websites that they're not allowed to access, such as gambling or pornography, like we talked about earlier. But it can also tell us how much time an employee is spending on any given website. So if a manager is worried that an employee has been surfing Facebook all day and not doing their job, they can actually put in a request for the system administrators to create a report of that user's web browsing activity.

And they can query the proxy server and look at the audit logs to determine exactly how much time they spent on any given site if this is allowed within the scope of the organization's policies. Now, in one of my previous organisations where I served as the IT director, we started seeing our network slowing down over time because we started adding more users, and we were getting worried about this. So one of the things we did was start evaluating which websites were using the most bandwidth by checking our proxy servers, and not surprisingly, number one and number two were YouTube and Facebook.

Now this allowed me to go to upper management and request additional money to buy more bandwidth, or if they didn't want to give me that bandwidth, we would then request to block these sites so we could maximise the bandwidth we had for real work functions and not for people going on social media. Now in the case of this organization, our leadership decided to block YouTube because they didn't see a valid business reason that would require our employees to be using YouTube during working hours instead of us buying a larger amount of bandwidth from our Internet service provider.

So they decided to save some money and make it so the employees couldn't use YouTube. Now everything I've said in this video so far is describing a specific type of proxy known as a forward or transparent proxy. This type of proxy is typically located at the perimeter of your corporate network and regulates outbound traffic based on your specific policies from your acceptable use policies. This will frequently hide the client's IP address as well as block any malicious incoming traffic sent in response to the client's request to a remote web server. But we have another type of proxy out there known as a reverse proxy.

A reverse proxy acts as an intermediate connectionpoint positioned at your corporate network's edge, and it acts like the actual endpoint. Essentially, the reverse proxy is going to serve as a gateway between your users and your application origin server. So if I'm hosting a web application on one of my servers, I could set up a reverse proxy to act as an intermediary between the remote users and my web application. This allows the reverse proxy to receive the user connection request, complete the TCP three-way handshake, and then connect the application's origin server with the end user. So why might you want to use a reverse proxy? Well, it's going to provide us with four main benefits. content catching, traffic, scrubbing, IP masking, and load balancing. First, we can use a reverse proxy to perform content caching.

By placing a few reverse proxies in several locations around the world, those reverse proxies can now act as part of our content distribution network. For example, let's pretend I have my main web server that hosts all my website for deontrain.com sitting in Miami, Florida. I could have four reverse proxies located in Japan, Germany, New York, and San Francisco as well. Each of these reverse proxies will get a copy of my website, and anytime I make a change to my content in Miami, it's going to be compressed and cached by those reverse proxies located around the world. Now, if I have a student in India who requests my home page, they would get a copy from the closest and fastest reverse proxy, in this case, the one located in Japan. This would then reduce page load times and improve the user experience for that student. Second, we can use a reverse proxy to perform traffic scrubbing.

By placing the reverse proxies in front of our backend Web application servers, they can inspect and filter traffic heading to those servers before it gets processed. This helps with DDoS mitigation because DDoS attacks only affect one or a few of our reverse proxies and not our back end servers, and it also helps with Web application security because the reverse proxy can be connected to a Web application firewall to filter out any bad requests and malicious packets. Third, we can use a reverse proxy to perform IP masking. Just like a forward proxy can hide the client's IP from its destination, a reverse proxy can mask the IP of our application servers, since the client only communicates with the reverse proxies and not with the application servers directly. Fourth, we can use a reverse proxy to perform load balancing.

Because these reverse proxies act as a gateway between the users and our Web application servers, they can route the individual request to any server they desire. So if we have multiple Web application servers, we can use our reverse proxy to distribute the load across multiple servers to provide a better quality of service to our end users. So remember, when you're thinking about proxies, that we have two basic types: forward and transparent proxies, and reverse proxies. When we talk about forward and transparent proxies, we're focused on filtering information that's leaving our networks with reverse proxies. We're focused on filtering information that's coming into our networks and is destined for our application servers.

8. Gateways (OBJ 1.1)

Take a moment here and talk about the different types of gateways that are used in your enterprise networks. Now, each one of these is used for a specific function, and it's important to know what they do and when you're going to use each type. So let's talk about NAT gateways, Internet gateways, API gateways, and XML gateways. First, let's talk about NAT gateways, or network address translation gateways. Now, a Nat gateway is going to be used to give endpoints without public IP addresses access to the Internet without exposing those resources to incoming Internet connections.

For example, let's say I have ten workstations on a subnet that uses a private IP address of 192, 168, and 100:24. Those ten machines won't be able to access the Internet to get their software updates or even browse Facebook because they only have private IP addresses. And private IP addresses cannot be routed across the Internet. So those devices are going to have to connect to a NAT gateway. And that NAT gateway would then use either network address translation or port address translation to proxy those requests from the workstation to the public internet and then back.

Now, a NAT gateway is also heavily used in cloud-based networks when you need to be able to connect private cloud resources to the Internet or when making outbound requests. Remember, with a Nat gateway, connection requests must be initiated from the outbound traffic going towards the Internet. The second type of gateway we have is known as an Internet gateway. And this is kind of like the opposite of a NAT gateway. With an Internet gateway, we allow inbound connections to be initiated from the Internet and then relay or proxy them to our internal resources. For example, if I have ten servers sitting in my DMZ, they're going to be assigned private IP addresses.

And I could set up an Internet gateway with public IPs to listen for inbound connections and then relay those to the right servers based on their private IPs. If you remember when we discussed the concept of a reverse proxy, we said that a reverse proxy can perform this function for us. And that is exactly what we're talking about here, because a reverse proxy can act as an Internet gateway. So, for example, let's say I'm creating a new webapp on one of my internal servers that's going to deliver practise exams to all of my students. Since the internal network uses private IP addresses, my practise exam application server might have an IP address of 182, 168, 1, or something like that. And then you're not going to be able to connect to that directly from the Internet because it's a private IP. So I'm going to need to configure a public IP as an Internet gateway or reverse proxy, and it's going to listen to the request from you and then relay that request to my internal private IP on your behalf. This protects my internal server from having people on the Internet directly connect to it, which increases the overall security of our network as well as giving me the chance to filter an inbound request or conduct load balancing as it goes across multiple servers. The third type of gateway we have is known as an application programming interface, or API gateway.

Now, an API gateway acts as a reverse proxy to accept all the application programming interfaces or API calls that are coming into this network, and then it's going to aggregate the various services required to fulfil those requests and return an appropriate result to the requester. For example, when you want to watch a movie on Netflix, you're actually going to be connecting to the Netflix API gateway. The API gateway then determines which particular services and servers are needed to fulfil your request based on the location you're making that request from, whether you're wanting to watch the movie on your laptop, smartphone, tablet, or TV, and a lot of other factors like that. Each time someone requests that movie, the API gateway will decide how to best fulfil their request based on all of these different factors. Since the API gateway is a reverse proxy, it gives us additional security by preventing people from directly connecting to the API itself, and it gives us the opportunity to provide filtering and access controls to those requests prior to sending them on to the API itself to fulfil them.

The fourth type of gateway we have is an Extensible Markup Language (XML) gateway. This works just like an API gateway, and in most cases, it is an API gateway. But it's a specific type of API gateway because it focuses directly on data requests that come in XML format, whereas an API gateway is more generic and can support JSON, XML, or other formats as well. Essentially, an XML gateway is an XML firewall, if you want to think about it this way. It's going to provide us with filtering and access controls specifically focused on XML-formatted inbound data to the API to add additional protections for us.

CASP certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass CompTIA CASP certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.