5.1 network security technologies Flashcards
1
Q
Compartmentalization
A
- Network segmentation has been done for a long time by the network operations folks. They use routers, VLANs, subnetworks, and so on to break up a network. But segmentation is done for efficient management of IP addresses, routing traffic efficiently, and so on. It is purely a network management issue
- Compartmentalization does the same thing: Break up a network into different areas. But compartmentalization does this for an entirely different reason. We break up the network by functional area. For example, let’s put everyone in Human Resources on one network and everyone in accounting on a different network. Doing this enables us to control who can see different kinds of traffic more easily. If you put a user from HR and a user from accounting on the same network, the odds that one of them may see some of the other’s traffic goes up dramatically. This could lead to security issues
- Part of a compartmentalization plan could include creating enclaves for especially sensitive systems. Examples include any central authentication server, the Research and Development server, and so on. These tend to be servers with extremely sensitive information on them. By using firewalls, IDSs and IPSs, and some of the other technologies we talk about here, we can create enclaves (distinctly bounded areas enclosed within a larger area). We can then carefully control traffic to those systems and allow only the systems administrators to actually access them directly.
2
Q
Firewalls
A
- The firewall is the primary mechanism to provide security separation between two networks. Most people think of firewalls as going between the internal network and the internet, and they absolutely do belong there! But they can also be used (returning to our example from a few minutes ago) to keep people from HR out of the accounting network and vice versa. As already stated, the firewall is also a significant part of how we create private enclaves for sensitive systems.
- Here, we discuss three types of firewalls. We use common terminology but do realize that some vendors may have different names for everything we talk about. Because understanding firewalls is so important to understanding fundamental network security, we devote time to each of the three types listed here in upcoming slides
- There is a fourth type of firewall that has become important and deserves mention. The Web App Firewall (or Web Proxy or half a dozen similar names) is a special purpose type of firewall. It sits in front of your web server, meaning between the web server and the web browser, and controls all traffic to and from that server. A good Web App Firewall is going to be fully knowledgeable about attacks against web servers and can block those attacks in real time. For example, they would know exactly how to recognize an SQL Injection attack and prevent it from working. They should also protect your website from defacement.
o Since attackers need an IP address visible from the Internet to attack an organization, web servers have long been a primary attack surface. By definition, a World Wide Web server must be accessible to the world. Web servers have an IP address and an open port allowing web browsers to connect. Therefore, attackers can connect as well. For this reason, your web servers need extra and specialized filtering of traffic.
o A WAF watches all traffic to and from a web server. The device always allows legitimate traffic, such as GET /index.html commands. But if it identifies common attacker techniques such as Structured Query Language (SQL) attacks, Cross-Site Request Forgery (CSRF), Cross-Site Scripting (XSS), and CommandLine Injection attacks, and many others, they are blocked. The proxy firewall operates at OSI Layer 7 to inspect the packet’s payload (application layer). It helps protect web applications and sensitive data by monitoring and filtering web traffic between a web server and people on the Internet
3
Q
Firewall rules
A
- Although every firewall type and product are different, some general statements apply across the board. Those include what you see here
- Every firewall product requires you to configure rules of some kind. Exactly what those rules look like as far as their syntax or the interface you use to create them can vary from product to product. But in one way or another, you need to put rules on your firewall. On a packet filtering router, the rules are called an Access Control List (ACL) that you load onto the router and apply to an interface. For most if not all stateful inspection and proxy firewalls, there is some kind of Graphical User Interface (GUI—pronounced Gooey) management interface you will use to configure the rules. How do you know what rules you should put on the firewall? It’s a simple answer or should be. Your organization’s policy tells you what rules you need. If your policy states that internal users can surf the web, that is a firewall rule you need to create.
- Always work on an exclusive lookup : Let’s say you have firewall rules, and a new packet comes in and it parses through the rules (goes through the rules and sees if it matches) it goes from rule to rule and once it finds a match it stops looking and sees the decision of whether to permit or deny
- Most firewalls on the market today are default deny type products. In other words, you put in rules to allow necessary traffic and everything else is automatically denied. For the vast majority of organizations, that is the wanted default configuration. There are some firewalls that default allow. In certain situations, this can also be good. The important thing is that you must know which default your product uses. That default dictates everything else about how you configure your firewall. Configuring a default deny product is different from configuring a default allow.
- Excessive rules—or “rule creep”—is a very real problem with firewalls. As new firewall admins come in, they add their own rules. They don’t know what the existing rules are for, so they leave them there. This can result in a LOT of extra rules on a firewall that simply don’t need to be there. Please always add a comment to your firewall rules so the next person in the job will have some idea why the rule was added.
- All firewalls we have ever worked with can also generate logs of some kind. Some of the products have advanced logging and alerting capability, often enabling you to use filters to narrow down log entries when searching for specific types of entries. On firewalls with more advanced logging capability, they often have alerting that can tie into your Simple Network Management Protocol (SNMP) infrastructure, or other similar alerting capability.
4
Q
Shallow inspection vs deep inspection
A
- As firewalls analyze packets, they use one of two methods. They are most commonly called “Shallow Inspection” and “Deep Inspection”.
- Shallow inspection means that the firewall only examines the header information, not the data. Most of the time, this means that it will look at the source and destination IP addresses, the source and destination port numbers, and the protocol (filtering on the protocol field of the IP header). In other words, if the packet is * coming from any computer with the network address 10.10.10.0, * is going to the specific address 10.10.22.7, * is from a port number equal to or greater than 49152, * and is going to a port number 53 (DNS), * and it is TCP traffic, then deny it. * But if meets all of those criteria and is UDP, then allow it.
- Deep inspection begins by doing the same thing as shallow inspection: It analyzes the IP addresses, ports, and protocol information. If that information matches the criteria you specify, it can then go into the data portion of the packet to look for information there. For example, it might look for a particular string. If it finds that string, it can allow or deny the packet.
- There are two versions of SSH: Version 1 and version 2; version 1 has several vulnerabilities, so you only want to use version 2. Unfortunately, they both use TCP port 22. So, a shallow inspection firewall can only allow or deny all SSH traffic but cannot do so by version. A deep inspection firewall can allow TCP port 22 and then if it sees the code for version 1 in the data, deny the connection, if it sees the code for version 2 in the data, allow the connection
- Shallow inspection is faster but may not identify problem traffic – deep inspection is slower but catches more – the tradeoff with security
5
Q
Firewalls: packet filter
A
- To set up a packet filtering router, you create a list of filtering rules called an Access Control List (ACL). You load that into the router’s configuration. Finally, you apply that ACL to an interface. At that point, it begins filtering traffic. When you create the rules for the ACL, you can filter on information only from the OSI Layers 3 and 4 headers. Specifically, you can filter on the source and destination IP addresses, the source and destination port number, and the protocol type such as TCP/UDP/ICMP/etc. (based on the protocol field of the IP header). In other words, you can create a rule that says: If the packet is: * From the 10.1.1.0/24 network and an ephemeral port number * To the 10.2.2.2 server and a destination port number of 53 (DNS) * Is TCP traffic That indicates it is a DNS Zone Transfer, which our policy says we should deny.
- But, If the packet is: * From the 10.1.1.0/24 network and an ephemeral port number * To the 10.2.2.2 server and a destination port number of 53 (DNS) * Is UDP traffic That indicates it is a DNS address lookup, which the policy says we should allow. (Notice that the only difference in the criteria is that one is TCP and the other is UDP.)
- With a pure packet filter technology, that is as much granularity as you can get
- Most common on routers and does shallow inspection
- Order of the rules is always important :
o Get majority of traffic to match early in the list : performace – if you have 2,000 rules and your traffic has to parse through that then you will have a lot of latency
o Get traffic to allow/deny appropriately; security issue – if a match on rule 3 permitted and I needed rule 23 to deny, then that is a security an issue
6
Q
Firewalls: proxy
A
- The Proxy firewall has become rare today, at least for the firewall sitting between a corporate network and the internet. Specialized proxies sitting in front of web servers and similar devices are still quite common. The proxy firewall operates at OSI Layer 7. This means that the logic that checks the validity of the packet is at the application layer of the firewall. One of the most important things to understand about a proxy firewall is that nothing goes through a proxy. Traffic goes to the device. Traffic goes from the device. No traffic goes through the device
- This means that every connection to the internet results in two separate connections: One from the client to the proxy and one from the proxy to the internet server. From a security perspective, this is good. The internet server has no idea that the client system exists; all its communication is with the proxy. From a performance perspective, this is horrible. Each time a packet containing data arrives at a proxy, the data has to be copied out of the packet and into a buffer. A new packet has to be created to go out the other side, and the data is copied from the buffer into the new packet
- This can cause unacceptable latency and is the primary reason that proxy firewalls have fallen out of favor. This is especially true for UDP traffic because UDP has no state, and each packet has to be approved independently. VoIP communication (which uses UDP) is unacceptably slow through a proxy
- The US air force has been removing proxy firewalls with stateful inspection and one of the driving factors behind this was voice over IP, which generates a massive number of tiny UDP packets and every one of those packets have to be approved on its own merit and then data copied to a buffer, then new packet, then sent on
7
Q
Firewalls: stateful inspection
A
- A stateful inspection firewall is based on packet filtering. Therefore, everything we said about packet filtering remains true. However, there is something called the state engine, which uses a state table that takes basic packet filtering to a whole new level
- The initial packet of any communication must match a rule in the ruleset to be allowed through. After that happens, the initial packet is allowed through the firewall. As it traverses through, the firewall takes information from the packet (source and destination IP addresses, port numbers, sequence numbers, and more) and builds a state table entry. When the distant system sends its response, the firewall does not compare it to the ruleset. Instead, it looks in the state table. If the packet matches the state table entry, meaning it sees the IP addressing is correct and the port numbers are correct, and all the rest matches, it allows the response packet back through. So stateful inspection gets its name because (after the initial packet matches a permit rule) all subsequent packets are allowed based on the “state of a current connection.” After the firewall sees the session terminate (with a FIN or RST packet), it closes the connection back off and removes the state table entry, so the communication path is open only as long as the connection needs it.
- Most common firewall type today
- All stateful inspection can do shallow – some have the capability to do deep inspection
8
Q
Stateful inspection process
A
- The TCP SYN packet travels from the client toward the server but hits the firewall.
- The firewall stops that packet from going further until it can inspect it and make a decision.
- The firewall sees that the packet is from an internal IP address going to a public server. With a destination port of 80, the user asks to use the server’s web service.
- The firewall looks in its state table but does not find a match. (We return to the state table shortly.)
- Because there is no match in the state table, the firewall parses through the rules to see if there is a match there. Sure enough, rule 3 says that internal IP-addressed computers can go to external websites: The action is to be permitted.
- The firewall dynamically reconfigures the packet filter to allow the packet to go through. (Another name for this type of firewall is Dynamic Packet Filter.)
- As the packet traverses through the firewall, the firewall takes information from the packet and creates a state table entry (denoted at the bottom part of the firewall in the diagram).
- Among other information, the state table entry includes the source and destination IP addresses, the source and destination port numbers, the source sequence number, and more.
- When the SYN packet arrives at the server, it responds with the second step of the TCP handshake, a SYN/ACK (assuming the server has port 80 open for connections).
- When the SYN/ACK hits the firewall, it is stopped for inspection.
- The firewall looks in the state table entry and sees that the SYN/ACK is coming from the correct IP and port number and that it is going to the correct IP and port number, and so on.
- BASED ON THE STATE OF A CURRENT CONNECTION, it makes sense to dynamically reconfigure the packet filter and allow the SYN/ACK through.
- The firewall updates the state table with any new information (such as the server’s sequence number).
- As the communication continues to flow back and forth, the packets are allowed through the firewall based on the state table entry, not based on the rules.
- Only the first packet of any communication has to parse the rules. When the first packet came along and hit the firewall that packet had to parse through the rule until it was permitted then the second packet and so on they all matched the state table and they were permitted – so only the first packet had to go through the rule, and therefore, when you’re figuring out the source and destination, you always look at the first packet
- This is true regardless of the type of traffic that passes through the firewall, whether it be TCP, UDP, ICMP, or anything else. A stateful firewall handles all traffic with equal efficiency.
- Eventually, either the client or the server determines that it is time to end the connection. When this happens, the system sends a TCP FIN packet to the other end, signaling that it wants to begin the four-step TCP teardown
- As the FIN packet traverses through the firewall, the firewall makes note of the FIN in the state table. The firewall allows the four-step teardown to complete. As soon as the teardown is done, the firewall removes the state table entry and dynamically reconfigures the packet filter to close the ports off again. Those ports are open only as long as the state of the communication continues to dictate that they should remain open
o What if there’s no FIN? Timeouts, after a certain time of inactivity the communication haults
o The first rule is often a “stealth rule.” It says if anyone tries to connect directly to the firewall, block the connection. The firewall protects itself from attack. Make sure you’re giving your admin access though, or else you will lock yourself out
o The last rule is often a “cleanup rule.” Any source, any destination any service, deny—and log—the activity. Default deny rarely logs. - Do note that, depending heavily on both the brand and configuration of the stateful inspection firewall, it may do many other chores for us at the same time that it does stateful inspection. Examples of what it may or may not be doing include: * Network Address Translation (NAT) * Intrusion Detection System (IDS) * Intrusion Prevention System (IPS) * Gateway antivirus * Content filtering * Virtual private network (VPN) encryption and decryption
9
Q
DMZ
A
- The Demilitarized Zone (DMZ) of your network is the public access area of your network. In other words, this is where you put all of the servers that you will let people you don’t know connect to. On your internal network, you only allow your own users that you can authenticate, and those who have had security skills/awareness training. This is a fairly high degree of control.
- The DMZ is where you put the web server that you have to allow anonymous access to. People you do not know, who you cannot authenticate, and who have never trained are allowed to connect to that server. It is not just one server—you also have your mail server, your DNS server, and perhaps others. Sooner or later, someone is going to find something they can exploit on one of these servers. They will be exploited at some point—it is simply a question of how long it will take and how bad it will be
- To make the “how long will it take” be as long as possible:
o Harden the operating system of any DMZ server. Remove anything and everything that is not absolutely required for that system to perform its mission in life.
o Keeping all systems patched is important, but especially for DMZ servers. Patches should be applied in the DMZ as quickly as possible after release. Yes, you still need to test the patches first, but any patch that applies to DMZ systems should have expedited testing.
o Use the firewall in front of the DMZ to limit access to DMZ servers only on the required ports. You have to allow some access, of course. A World Wide Web (WWW) server must, by definition, be accessible by everyone in the world on TCP Port 80 and possibly TCP Port 443. Therefore, those ports must be allowed through the firewall. But only those ports and only to that one IP address. Be as restrictive in your firewall rules as you possibly can and still get the job done. - To make the “how bad will it be” as minimal as possible:
o Again, employ your firewall to limit access by the DMZ server to internal systems. Preferably, DMZ servers have zero access to internal systems. In some cases, that is not possible. For example, your web server may require access to an internal database server. If that is the case, the firewall between the DMZ and the internal system should only allow that one DMZ server to go to that one internal database server, and only on required ports and so on. Again, be as restrictive as possible in your firewall rules.
o Have good backups of any data that resides on DMZ servers, especially data that you cannot reconstruct on your own (customer orders, for example).
o Have hot-swap servers ready to put online at a moment’s notice. This way, when a server is compromised, you can take it offline for analysis and put a hot-swap server in place to continue providing service with minimal interruption.
o If the hot-swap server capability is not possible, have the ability to reimage and redeploy DMZ servers quickly. This can cause you to lose the ability to analyze how the compromise occurred (increasing likelihood of recompromise) but will allow you to put an uncompromised server back in service quickly. - Make certain that the recovery capability of servers in the DMZ is “Root-Cause Recovery”. This term means that you can not only recover the functionality and any data for the server, but do so in a way that the root-cause of the breach is fixed. For example, if your web server is broken into and you simply reimage it with the same image, then the attacker will be able to break in again. Instead, you employ root-cause recovery which means that part of the recovery effort includes fixing the problem that allowed the breach to occur in the first place
- A critical point: Never—ever—for any reason—under any circumstance put a public access server on your internal network! There is absolutely no possible justification for doing so. This is perhaps the single worst network design mistake that you can possibly make.
- There are very few unbreakable rules in cyber security. But: * Never put a public access server in the internal network, only in the DMZ. * Never put sensitive data in the DMZ, only on an internal network
o There is no justification to break these rules
10
Q
Sinkholes
A
- Firewall rules are great for blocking traffic. Many companies use them not only to filter incoming traffic to only what is allowed, but to stop employees from going to certain sites as well. The potential problem with doing so is the more firewall rules you have, the more latency you will introduce on the network. Too much latency and you will be told to remove the security mechanism
- A second method of stopping internal employees from going to unauthorized locations on the internet is called a sinkhole. Assuming the DNS server in step 6 of the diagram is the company’s DNS server, you can easily configure any number of sinkholes. In the example on this slide, we configured the company’s DNS server to resolve bad.com to the IP address 10.1.1.1 which is the address of an internal web server. That web server can display some sort of “unauthorized activity” message. You could also simply have the DNS server bad.com to 0.0.0.0. That address is not going to route properly, so the traffic cannot reach the destination
- For a handful of unauthorized sites, sinkholes are great. But do you really want to assign your employees to go out and find all of the bad places on the internet and then keep that list up to date? That is probably not your core business. In that case, content filters (next page) are a better solution
11
Q
Content filter
A
- A web content filter is software and/or hardware that blocks access by users to internet sites based on the content. Generally speaking, you can configure a device of this nature by selecting categories of sites you don’t want your users going to. Common categories include pornography, hate speech, illegal drug-related, and similar such sites.
- Less common is the email content filter. These can be useful in stopping inappropriate email. Examples of such emails include flames (emails with abusive, vulgar, or otherwise inflammatory language). Typically, software of this nature either blocks the message entirely, gives senders a 24-hour cooling off period before asking if they still want to send it, or forwards it to their boss for evaluation
- You can also usually configure a list of keywords into email content filters. Say you have a super-secret project going on within the company. By configuring a list of keywords that would indicate a message deals with that project, you can stop such email from accidentally (or intentionally) being sent outside your corporate network
- Recent studies show that the number one-way companies experience accidental data spills is via “autofill”. Autofill is the feature in an email program that completes the email address as you are typing. It is wonderfully convenient but can also be a security nightmare. You are sending highly sensitive information to the head of the R&D department, who happens to share a first name with your child’s soccer coach. Autofill put the soccer coach’s email address and you fail to notice. Refer to our discussion earlier on Electronic Espionage Act of 1996.
12
Q
IDS/IPS
A
- An Intrusion Detection System (IDS) is an automated system watching for signs of an attack. Some IDSs are devices connected to the network and watch network traffic for attacks, and some run on the host (PC) and watch for signs of attack there. They are respectively called Network IDS and Host IDS.
- IDS systems use a combination of signature and anomaly or behavior detection. Both are similar to what we discussed in anti-malware. Signature analysis has a database of packet header settings and/or strings in the data portion of the packet. The IDS monitors the packets to determine if it sees those patterns. Anomaly detection is very much like heuristics in anti-malware. The IDS is watching for attack-like activity on the network.
- An Intrusion Prevention System (IPS) is simply an IDS that can shut down the attack. Because it is not possible to shut the attack down until it first identifies the attack, an IPS must first be an IDS.
- This chart shows one of the most important points to understand about IDS/IPS. When an IDS/IPS recognizes an Event of Interest, what kind of event is it? How do we categorize it?
o True Negative (It is legitimate traffic, and the IDS/IPS got it correct.)
o True Positive (It is attack traffic, and the IDS/IPS got it correct.)
o False Negative (It is attack traffic, but the IDS/IPS thinks it is legitimate.)
o False Positive (It is legitimate traffic, but the IDS/IPS thinks it is an attack.) - The question becomes, which is worse? The false negative or the false positive? Because the false negative means that the IDS/IPS is missing attacks, many say it is the worst by far. Certainly, it is not a good thing. However, if you have too many false positives, they become white noise and people stop paying attention to what the IDS/IPS is reporting. Certainly, this is just as bad. There are numerous documented cases of IDS systems reporting attacks and exfiltration of data, but nobody notices because there are many gigabytes per hour of false positives being generated. With IPS, you cannot allow false positives at all, since that would mean the security device is blocking legitimate traffic! This cannot be allowed to happen.
- There is a direct coorelation between false negatives and positives – when you prioritize and lower one that increases the other
- You want to tweak it so for the IDS the false positive and negatives are balanced – but the IPS is adjusted so it prioritizes not having any false positives
13
Q
All-in-one security appliance
A
- The other name for an all-in-one security appliance is Unified Threat Management device. If you have a wireless router at home that you paid at least $30 for, then you most likely have an all-in-one device right in your house. Exactly which functionality the device you purchased happens to have will vary. But in the little 6-inchsquare and 2-inch-tall device, you might find a Layer 2 switch, a Layer 3 router, a content filter, an IDS/IPS, a gateway antimalware scanner, a spam filter, a NAT device (doing port address translation specifically), a VPN concentrator, your Wi-Fi access point, and your stateful inspection firewall. The clear advantage is that you have all 10 of those network devices inside one box that you paid very little for. If you had to purchase them all separately, it could easily cost you $1,000 or more.
- The drawback is that, unless the device has the functionality built into it, you can’t see the traffic between those pieces of network gear; it is all internal to that system. This makes troubleshooting virtually impossible. Now, take that home network device and beef it up to handle enterprise-level traffic. You have a corporatelevel UTM device with the same advantages and possible disadvantages. (It is more likely for an enterprise-level system to have an internal traffic monitoring capability.)
14
Q
Sniffer
A
- What the tool does is show you the packets that go across your network. After you learn to “read” the output of a sniffer, you can much more easily troubleshoot a network. Actually, it is just about impossible to imagine trying to manage a network without a protocol analyzer. There are many times when a network administrator simply cannot diagnose and fix problems on a network without a sniffer in their list of tools.
- In reality, when you use a tool of this nature, you are running two pieces of software. The first is the sniffer that captures a copy of the packet. The sniffer then sends it to the second piece of software, which is a protocol analyzer. That is the software that interprets the contents of the packet and displays that information to you in a more human-readable form. Wireshark, which we will talk about next, is technically the Protocol Analyzer—but everyone calls it a sniffer
- If you follow the TCP stream, you can get the login information and the start of the email headers – this is pretty bad from a security perspective
15
Q
Port scanners
A
- To attack a system remotely, there are two prerequisites to success. First, the attacker must know the IP address of the system. Second, they must know what port number they are going to connect to when they get there. Other information can be helpful to the attacker (such as OS and version, applications running, and more), but without those first two, nothing else does them any good. So, one of the things we want to make certain of is that we have systems listening only on ports that are absolutely necessary. Where the attacker uses port scanning to find ports to attack, security staff can use a port scanner to determine what ports we can close (so they can’t be attacked).
- As you have probably figured out by now, a port scanner is a tool that tells us if a port on a remote system is open or closed. There are a variety of methods of accomplishing this, but they all have the same basics in common. The port scanning software sends traffic to a system and looks at the responses it receives back. For TCP ports, if the port scanner gets a SYN/ACK packet (remember the flags from the TCP header?), the port is open. If the port scanner gets an RST (reset) packet back, the port is closed
- Not only does Nmap know how to do every kind of port scan ever invented, it can also do a good job of OS enumeration. It can tell you with a high degree of accuracy exactly what operating system is running on the other end. It does this in part through passive OS enumeration techniques. Every operating system creates packets in slightly different ways, which creates a sort of fingerprint of an OS. Nmap has a database of those fingerprints. It compares packets coming back from a target to that database and tells us what operating system is running on the other end. Nmap can also enumerate the application running on the distant system. For example, it can tell us exactly which web server software a web server is using