Network Security

---

Shortcut to this page: ntrllog.netlify.app/security

Info provided by Counter Hack Reloaded (Ed Skoudis, Tom Liston), Network Security Principles and Practices (Saadat Malik), and Certified Ethical Hacker v9 Study Guide (Sean-Philip Oriyano)

This is an extension of the computer networking resource. Well, we’ll see where this goes — I’m writing this as the class goes.

Networking Overview

Firewalls

Firewalls decide what kind of traffic is allowed into and out of a network.

The more general term for what a firewall does is "packet filtering". A firewall is a type of packet-filtering device. (A router can also be configured to be a packet-filtering device.)

Traditional Packet Filters

Traditional packet filters look at the headers of a packet to see what type of packet it is, where it came from, and where it's going. Specifically,

• Source IP address: does this packet come from somewhere trusted?
• Destination IP address: is this packet going to a server that should receive this type of traffic?
• Source port: what type of traffic is this?
• Destination port: is this packet going to a server that should receive this type of traffic?
• TCP control bits: what type of traffic is this?
• Protocol in use: what type of traffic is this?
• Direction: is this packet going where it should be?
• Interface: does this packet come from somewhere trusted?

These fields are used to create packet-filtering rules, which are often called Access Control Lists (ACLs).

Action	Source Address	Destination Address	Protocol	Source Port	Destination Port	Control Bit
Allow	Inside Network Address	Outside Network Address	TCP	Any	80	Any
Allow	Outside Network Address	Inside Network Address	TCP	80	> 1023	ACK
Deny	All	All	All	All	All	All

If a packet matches multiple rules, the simplest policy a firewall can adopt is to apply the first rule from the top that matches.

Stateful Packet Filters

The problem with traditional packet filters is that they only look at the packet headers, which provides a very limited view of what the traffic is actually doing.

For example, the second rule above allows all TCP traffic to come in as long as the ACK bit is set. Yes, it's expected that outside traffic coming in will have the ACK bit set. But only as responses. What if there are "responses" coming in to our network, but no devices in our network ever made any requests?

This is where stateful packet filters come in. They maintain a dynamic state table that keeps track of connections that are made. This allows them to "remember" earlier packets that went through/out and make decisions about later packets.

Source Address	Destination Address	Source Port	Destination Port	Timeout (Seconds)
10.1.1.20	10.34.12.11	2341	80	60
10.1.1.34	10.22.11.45	32141	80	40

Notice that with this table, if we see outside traffic coming in with the ACK bit set going to one of these two devices, then we know it's an actual response.

Proxy-Based Firewalls

Instead of looking at individual packets, proxy-based firewalls look at the contents of the packets. In more OSI terms, proxies focus on the application level.

Which Technology Is Better for Firewalling?

Traditional packet filters are fast, but their intelligence is very limited.

Stateful packet filters are smarter, but slower.

Proxy-based firewalls are the smartest, but they need the most memory and processing power.

It can be a good idea to use a combination of these three in a network. For example, a stateful packet filter can sit between the Internet and the DMZ while a proxy-based firewall can sit between the packet filter and the internal network.

PIX Firewall

PIX firewall is a stateful packet filter that runs on its own operating system rather than as an application on top of another OS.

Adaptive Security Algorithm

ASA is the algorithm that PIX uses to examine traffic passing through it and decide what to do with it. It keeps track of:

• IP source and destination
• TCP sequence numbers and flags
• UDP timers

TCP

When a host makes a connection request to the Internet, PIX stores the packet's state information (the stuff mentioned above). When a response comes back, PIX checks that the sequence number and source/destination information match what it's expecting. Honestly, nothing special, but I included it for the sake of completeness.

What is special however is that PIX does a few things to improve security. PIX proxies the connection until the three-way TCP handshake is complete. If the handshake is not completed within a certain time, the connection is dropped. This way, only legitimate connections are allowed through the PIX.

The other thing PIX does to improve security is to randomize the initial sequence number. So PIX stores the delta between the actual sequence number and PIX's randomized sequence number and replaces each packet's sequence number with the correct number so that the calculations are consistent.

UDP

Since there's no state information available to keep track of for UDP, ASA uses a timer to track UDP sessions. The timer is active as long as there is traffic. If there has been no traffic after a certain amount of time, the timer expires and no more traffic is allowed for that session.

Stateful Inspection of Traffic Using the ASA

• Outbound connections are allowed, except the ones denied by ACLs.
• Inbound connections are denied, except the ones allowed by ACLs.
• All ICMP packets are denied unless specifically allowed.

Assigning Varying Security Levels to Interfaces

A PIX firewall can have 2-10 interfaces, and each interface can be assigned a level from 0-100. An interface with level 0 means that the interface is connected to a network that is (assumed to be) not secure. Interfaces with level 0 are typically the ones connected to the Internet. Interfaces sitting on the private network are assigned a level of 100.

Traffic can flow freely from a high security level interface to a low one, but from low to high, there needs to be rules defined in the ACLs.

Failover and Redundancy

Failover means that if a PIX starts to fail for whatever reason, a backup PIX can take over. A failover can be stateful, meaning that the current connection information is transferred to the PIX taking over. The state information is transferred via an Ethernet cable between the two PIXes.

So how is a PIX failure detected in the first place? The primary PIX and the secondary PIX periodically send hello packets to each other through a failover cable to see if the other is alive. If two consecutive hello packets are not received within a certain time, testing begins to see which PIX has failed.

Alias

Similar to how NAT translates source IP addresses, PIX's alias feature translates destination IP addresses.

Suppose a client on the internal network needs to access a web server on the DMZ.

1. The client queries the external DNS server for the web server's IP address.
2. The DNS server returns the web server's public IP address.
3. The client tries to connect to the web server using the public IP address.
4. PIX uses alias to translate the packet's destination address to the web server's private IP address.

Mail Guard

This feature helps prevent attacks on a mail server by only allowing certain SMTP commands (HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT) to be sent to the mail server.

Reconnaisance

Reconnaisance is the act of using publicly available information to investigate a target. This includes techniques such as social engineering, physically breaking into a building, digging through trash, and searching online.

Whois Databases: Treasure Chests of Information

Companies have to register their domains and servers with a registration company, a.k.a. registrar. The registrar assigns the company a domain name and enters it into whois and DNS databases so that the company's servers are accessible to the Internet.

DNS

Companies have to register their DNS servers with the registrar, so information about a company's DNS servers are publicly available in whois databases. And DNS servers store IP addresses, domain names, and mail server information. So attackers querying a company's DNS servers can build a list of possible targets to attack, or at the very least, learn more about the company's network infrastructure.

Interrogating DNS Servers

A zone transfer is an operation that asks a DNS server to send all information it has about a specified domain. It was designed to be an operation to update secondary DNS servers, but attackers have found a great use for it. Well, it works if the DNS server has zone transfers enabled.

Defenses From DNS-Based Reconnaissance

• don't include any additional information that don't need to be in DNS servers
  • only name servers and mail servers need to be in there
• configure primary DNS server to only allow zone transfers from secondary DNS server(s)
• configure secondary DNS server(s) to allow zone transfers from no one
• configure firewall to allow access to TCP port 53 only from secondary DNS server(s)
  • Port 53 is used for zone transfers
• use a split DNS architecture

A split DNS architecture has an external DNS server and an internal DNS server. The external DNS server only has information about servers that need to be accessible to the Internet. The internal DNS server contains all the information about the internal devices so they can communicate with each other.

The internal DNS server never communicates with the Internet. If an internal device needs to resolve a name that is on the Internet, it asks the internal DNS server, which then asks the external DNS server.

Scanning

Scanning is a process attackers use to find an opening into the network they are trying to attack.

War Driving

Imagine you're looking for free Wi-Fi, so you drive around looking for networks without that lock symbol. This is kinda what war driving is. In more technical terms, war driving is the process of looking for accessible and unsecured WLANs.

A network might have one or more wireless access points that allow devices to connect to that network wirelessly. Attackers target these access points to try to gain entry into a network.

In that little CSULA example, the Wi-Fi names are referred to as ESSIDs (Extended Service Set Identifiers). They're usually publicly visible so that you can find and connect to them. But some ESSIDs can be hidden. While an ESSID may be hidden, that doesn't mean it's necessarily hard to obtain it.

The goal of war driving, from an attacker's perspective, is to find as many of these ESSIDs as possible to increase the chances of finding an unsecured network.

Active Scanning - NetStumbler

In the 802.11 (a.k.a. Wi-Fi) protocol, a device can send a probe request message to an access point. A probe request is supposed to include the ESSID so that only the access point(s) with that specified ESSID responds. But access points can be (and often are by default) configured to respond to probe requests that specify "Any" as the ESSID. And under the 802.11 protocol, the response must include the ESSID. So an attacker can just send out a bunch of probe requests with ESSID="Any" to all access points in the area and gather their responses, generating a nice list of ESSIDs.

NetStumbler, which is one of the most popular scanning tools, does this probe request stuff. NetStumbler goes even further by collecting a whole slew of information, including encryption method. An attacker using NetStumbler can easily identify networks that are using weak encryption.

Listening for Beacons and Other Traffic - Wellenreiter

So what happens if an access point is configured to ignore probe requests with ESSID="Any"? Well, under the 802.11 protocol, access points periodically send out beacon packets to synchronize their clocks with the devices that are connected. These beacons usually include the ESSID, so an attacker can also capture these beacon packets.

This can be done by (loosely speaking) putting the device into rfmon mode, a.k.a. monitor mode, which allows the device to collect all wireless traffic, not just the traffic directed to that device.

So what happens if an access point is configured to omit ESSIDs from beacons? Well, any wireless traffic between an access point and all devices connected to it will have the ESSID information, so an attacker can just use rfmon mode to collect wireless traffic and get the ESSID from there.

Wellenreiter is a tool that does this rfmon mode stuff. Futhermore, Wellenreiter also listens for ARP and DHCP traffic to determine MAC and IP addresses.

Forcing Deauthentication with ESSID-Jack

Okay, so the ultimate scenario: what if

• access points are configured to ignore ESSID="Any" probes
• ESSIDs are omitted from beacon packets
• there is no wireless traffic to collect

Well, the attacker can use a tool called ESSID-Jack to force traffic. Before using the tool, the attacker needs to obtain the MAC address of the access point, which can be done by using Wellenreiter to sniff for management/beacon frames, which will have the MAC address.

Once the attacker has the MAC address of the access point, they can pretend to be that access point and send a deauthenticate message to the broadcast address, disconnecting all devices connected to that access point. As the devices try to reconnect, they will generate traffic for the attacker to collect.

War-Driving Defenses

• set the ESSID to a value that doesn’t bring unwanted attention to your network
• configure your access points to ignore probe requests that don’t include the ESSID, and set them up to omit the ESSID from beacon packets
• require some form of stronger authentication to your access points
  • WPA and 802.11i
• use a VPN to encrypt traffic to/from the network
• use Wireless Intrusion Detection Systems (IDSs) to look for unusual messages sent by intruding wireless clients (including ESSID-less probe broadcasts and unexpected deauthenticate messages)
• turn on built-in access point capabilities to detect renegade access points that suddenly show up in your environment
• turn down the transmit power for access points near your buildings' perimeters
• use directional antennas to control signal bleed out of the building from these perimeter wireless devices
• use metal shielding to break up wireless signals at the walls of your environment
  • wallpaper with a thin layer of embedded copper wires
  • paint with tiny metal fibers

Network Mapping

Let's say the attacker found an access point advertising an unsecured WLAN and was able to connect to the network. The next thing an attacker would want to do is to discover other devices connected to the network and build a map of the network.

Sweeping: Finding Live Hosts

One simple way to do this is to ping all possible addresses and see which addresses respond. They send an ICMP Echo Request packet and look for an ICMP Echo Response message. If there is no response, it could mean the address is not being used or the ping/response is being filtered.

Many networks block ping messages, so an attacker could send a TCP or UDP packet instead.

Traceroute: What Are the Hops?

After discovering which hosts are alive, attackers would want to know how they are connected to each other (the network structure/topology).

They can use traceroute to see how many routers there are from the attacker to any destination.

If a router decrements the TTL to 0, it will send an ICMP Time Exceeded message, where the source address of the message is the IP address of that router. So if an attacker starts a traceroute with a TTL of 1, it will learn the IP address of the first router. If the attacker starts a traceroute with a TTL of 2, it will also learn the IP address of the second router. And so on.

Cheops-ng

Cheops-ng is network-mapping tool that uses pings and traceroute.

Defenses Against Network Mapping

Pretty much, use firewalls and router packet filtering.

• block incoming ICMP messages, except to hosts that you want the public (including attackers) to be able to ping
• filter ICMP Time Exceeded messages leaving your network to stymie an attacker using traceroute

Determining Open Ports Using Port Scanners

After knowing the addresses of live systems and gaining a basic understanding of the network topology, an attacker would want to find potential entryways into the systems by finding open ports. In doing this, the attacker can also learn which services are in use. For example, if port 80 is open, then most likely a Web server is running on that machine.

A port scanner sends packets to various ports to determine if any service is listening there.

Nmap: A Full-Featured Port-Scanning Tool

Nmap is the most popular port-scanning tool.

The Polite Scan: TCP Connect

TCP Connect scans attempt to complete the three-way handshake with each port. So they send a SYN, wait for the SYN-ACK, and then send an ACK along with FIN to tear down the TCP connection.

If a port is closed, the target machine doesn't send the SYN-ACK. Depending on the machine and the network configurations, it could return nothing, a RESET packet, or an ICMP Port Unreachable packet.

Connect scans are really easy to detect because completed TCP connections are logged in the system.

A Little Stealthier: TCP SYN Scans

SYN scans only do the first 2 parts of the three-way handshake. They send a SYN and wait for the SYN-ACK. If they get the SYN-ACK, they send a RESET to abort the connection.

Same as earlier, if a port is closed, the attacker receives no response, a RESET packet, or an ICMP Port Unreachable packet.

Because the TCP connection is never established, there is no evidence of it in the logs. However, routers, firewalls, and other systems can still detect incoming SYN packets.

Another advantage of SYN scans is that they are faster because they don't have to wait for the connection to be torn down.

Violating the Protocol Spec: TCP FIN, Xmas Tree, and Null Scans

These scans work by sending packets that are not typical in normal network traffic.

FIN scans send packets with the FIN bit set. Xmas Tree scans send packets with the URG, ACK, PSH, RST, SYN, and FIN bits set. And Null scans send packets with no bits set.

For all of these scans, if a port is closed, it returns a RESET packet. If the port is open, it sends nothing. If an attacker doesn't receive a response from a port, it doesn't necessarily mean that that port is open; the traffic could've been blocked by a firewall.

Kicking the Ball Past The Goalie: TCP ACK Scans

It may seem like if we want to defend against port scanning, then we would just block all incoming traffic into our network. However, that would prevent us from going on the Internet (how would we get results from the Internet if we blocked all traffic?)

So we have to allow some traffic into our network, at the very least, packets with the ACK bit set. It should be pretty obvious what an ACK scan is at this point.

Unfortunately for the attackers, different operating systems behave differently in response to ACK packets. For example, some operating systems send a RESET if the port is open, whereas others send it if the port is closed. So an ACK scan isn't really used for finding open ports. It's more for finding out if a machine is running at the target address.

Obscuring the Source: FTP Bounce Scans

The one big problem with all of these scans is that the network can identify where they're coming from by looking at the source IP address of the messages. But there are ways for an attacker to involve another machine so that it looks like the scans are coming from somewhere else.

Some FTP servers allow users to connect to them and request that server to send a file to another system. So an attacker would request the FTP server to forward a file to a specific port on the target machine. Depending on the response, the attacker will know whether the port is open or closed. And best of all, for the attacker, the traffic to the port is coming from the FTP server, so the attacker's IP address is not exposed.

Idle Scanning: An Even Better Way to Obscure the Source Address

Okay, so what if there's no FTP server for the attacker to use? If the attacker can find an idle machine -- one that is not sending any/much traffic -- then the attacker can communicate with this machine and analyze the IP ID field of its messages.

1. The attacker picks a machine that is idle and has a predictable IP ID field.
2. The attacker sends a SYN packet to that machine. This allows the attacker to learn the current value of the machine's IP ID (we'll call it X) when it responds with the SYN-ACK.
3. The attacker sends a SYN packet to the target port and spoofs the source IP address so it looks like the SYN packet is coming from the idle machine.
4. The attacker sends a SYN packet to the idle machine and looks at the IP ID field.

If the IP ID value is X+1, then the port is closed.

If the IP ID value is X+2, then the port is most likely open.

It is not guaranteed to be open because the machine may not be truly idle; it may send a packet in response to something completely unrelated. So an IP ID value of X+2 could falsely report a closed port as open.

Don’t Forget UDP!

UDP scanning is another option, but it's less reliable. Because there's no connection that needs to be established, a UDP port does not need to send anything at all. So no response could either mean the port is closed, the port is open and not sending anything, or the port is open but the packets are getting filtered.

Setting Source Ports for a Successful Scan

To reduce their chances of getting blocked by traffic filtering, attackers can disguise their packets to look like normal traffic. One way to do this is to set the source port of their packets to something that one would reasonably expect traffic from. For example,

• a packet with source port 80 looks like it's a response from a Web server
• a packet with source port 20 looks like it's from an FTP connection
• a packet with source port 53 looks like it's a DNS response

Decoys Aren’t Just for Duck Hunters Any More

Attackers can also try to hide their packets by generating decoy packets with fake source addresses. The attacker's actual address must be included along with the fake addresses so that the attacker can get the results from the scan back.

Useful Timing Options

Nmap has different options for how fast or slow packets should be sent. Maybe they want to avoid being detected and will spread out the packets. Or maybe they want to conduct a scan as quickly as possible and send out packets quickly.

• Paranoid: Sends one packet approximately every five minutes resulting in a super-slow scan
• Sneaky: Sends one packet approximately every 15 seconds
• Polite: Sends one packet approximately every 0.4 seconds
• Normal: Runs as quickly as possible without missing target ports
• Aggressive: Waits a maximum of 1.25 seconds for any response
• Insane: Waits a maximum of 0.3 seconds for any response
  • This mode will likely report false negatives, listing open ports as closed

A Critical Feature: Active Operating System Fingerprinting

Besides finding out which ports are open, the attacker would also want to know what operating system(s) they're dealing with. That way, they can research particular vulnerabilities for that system.

They do this by taking advantage of the fact that RFCs do not define how a system should respond to invalid combinations of TCP control bits (recall the FIN, Xmas Tree, and Null Scans). Therefore, different operating systems respond to unexpected flags differently.

So this is a list of valid + invalid packets attackers can send:

• SYN packet to open port
• NULL packet to open port
• SYN|FIN|URG|PSH packet to open port
• ACK packet to open port
• SYN packet to closed port
• ACK packet to closed port
• FIN|PSH|URG packet to closed port
• UDP packet to closed port

Another way to help determine the operating system is to analyze the sequence number (similar to idle scanning). Some operating systems have predictable sequence numbers, so an attacker could send SYN packets to open ports and see how the sequence number in the SYN-ACK packets change.

Defenses Against Port Scanning

• close all unused ports
• periodically check to see which TCP/UDP ports are in use
• turn off unused services
  • if the service is started by inetd, you can comment out its line in /etc/inetd.conf
  • if the service is started by xinetd, you can delete the file /etc/xinetd.d/[service]
• scan your systems before an attacker does
• use stateful packet filters or proxy-based firewalls

Determining Firewall Filter Rules with Firewalk

I've briefly mentioned that traffic blocked by a firewall can make the results of scans harder to interpret (if there's no response, was the port closed or was the traffic filtered?). So naturally, if attackers can figure out what the filtering rules are, they can further determine which ports are open.

Firewalk is a tool that helps determine filtering rules.

How Firewalk Works

The main idea behind Firewalk is that it sends a packet to a machine that is on the other side of the firewall (we'll call it the target machine), and if it receives a response from that machine, then the packet is not being filtered by the firewall. If no response is received, then the packet was likely filtered by the firewall.

First, Firewalk determines the number of router hops to the firewall by sending a series of packets with incrementing TTLs (like in traceroute).

Once Firewalk knows how many hops it takes to reach the firewall, it will then start sending packets to the target machine on the other side of the firewall. The packets will have a TTL of (number of hops to firewall + 1).

If a packet gets through the filter, an ICMP Time Exceeded message will be sent by the machine that is exactly one hop away from the firewall. Or, if the machine that is exactly one hop away from the firewall is the target machine, then it might respond with an ICMP Port Unreachable or even a SYN-ACK. Whatever the response is, if the attacker received something, then they know the firewall allowed their packet through.

Firewalk Focuses on Packet Filters, Not Proxies

Firewalk doesn't work against proxy-based firewalls because proxies do not forward packets. Instead, the proxy gets the packet on one side of the gateway and creates a new connection on the other side, wiping the TTL information.

Firewalk Defenses

• make sure your firewall is configured with a minimum set of ports allowed through it
• use proxy-based firewalls

What We Have So Far

What the Attacker Knows	Tools
List of address of live hosts on the network	Ping and Cheops-ng
General network topology	Traceroute and Cheops-ng
List of open ports on live hosts	Nmap port scan
Operating system types of live hosts	Active OS Fingerprinting
List of ports open through packet filters on the target network	Firewalk

Vulnerability-Scanning Tools

Now, the attackers have a lot of information, but that information alone isn't enough for attackers to get into target systems. What they need is a vulnerability to exploit.

Vulnerability scanners automate the process of connecting to a target system and checking to see if there are any vulnerabilities. They have a database of known vulnerabilities and check to see if any of them are present on the target.

• Common configuration errors: Numerous systems have poor configuration settings, leaving various openings for an attacker to gain access
• Default configuration weaknesses: Out of the box, many systems have very weak security settings, sometimes including default accounts and passwords
• Well-known system vulnerabilities: New security holes are discovered and published online

Nessus: The Most Popular Free Vulnerability Scanner Available Today

Because it's free and supports custom scripts (plug-ins).

Nessus is based on a client-server architecture, where the server does all the heavy lifting (vulnerability database, scanning engine) and the client reports the results.

So, What Does an Attacker Do with These Results?

They look for particular exploits based on the vulnerabilities.

Vulnerability-Scanning Defenses

• close all unused ports
• apply patches to your systems
• run a vulnerability-scanning tool against your own network on a periodic basis to identify vulnerabilities before an attacker does

Intrusion Detection System and Intrusion Prevention System Evasion

In case you haven't heard, scanning tools are pretty noisy. Port scanners and vulnerability scanners send (tens/hundreds of) thousands of packets to the target network, and all of this traffic can be detected by IDS and IPS tools.

How Network-Based IDS and IPS Tools Work

Traffic associated with an attack typically looks different from normal traffic. Network-based IDSs and IPSs have a database of attack signatures that they try to match against network traffic. If they think there's an attack going on, they have some way of warning an admin.

How Attackers Can Evade Network-Based IDSs and IPSs

By changing the packet structure or syntax in a way that the IDS or IPS does not expect.

IDS and IPS Evasion at the Network Level

Recall that IP packets can be fragmented and reassembled once they reach the destination.

In order to analyze the traffic, IDS/IPS systems need to store the packets in memory/buffers. One thing attackers can do is to send a bunch of fragments, enough to overload their memory/buffers.

The Tiny Fragment Attack

However, something more interesting attackers can do is to send fragments in creative ways. For example, the attacker can split their packet into two fragments so that neither of them look suspicious on their own, but result in a dangerous packet when combined.

The Fragment Overlap Attack

This one is even more interesting. The fragment overlap attack is based on manipulating the fragment-offset field of the IP header. One fragment has the TCP header, and a piece of harmless-looking data that doesn’t trigger the IDS/IPS. The second fragment has an offset value that intentionally causes this second fragment to overlap the first fragment. When the two fragments are combined, a dangerous packet is created.

FragRouter: A Nifty Tool for Conducting Fragmentation Attacks to Evade IDS and IPS Tools

See title.

IDS and IPS Evasion Defenses

• keep the IDS and IPS systems and signatures up to date

Cryptography

Cryptography is how information is kept secret. It aims to provide the following:

• Confidentiality: keeps information secret
• Integrity: ensures information wasn't changed
• Authentication: proves someone is who they say they are
• Nonrepudiation: proves information was/wasn't sent

Symmetric Cryptography

In symmetric cryptography, the same key is used to encrypt and decrypt information. It's good for encrypting lots of data because it is very fast. But there are issues with using the same key to encrypt + decrypt, and there is no nonrepudiation.

Asymmetric, or Public Key, Cryptography

Asymmetric cryptography provides key management benefits and nonrepudiation by using a public key and private key system. Each person gets a pair of keys uniquely assigned to them. Either key can be used to encrypt information, but only the other key can be used to decrypt. That is, if the public key is used to encrypt, only the private key can be used to decrypt. And if the private key is used to encrypt, only the public key can be used to decrypt. As their names imply, the public key is visible to the public while the private key is meant to be used only by the owner.

Suppose you want to send a secret message to me. You'll do that by finding my public key and using it to encrypt your message. Then I'll use my private key to decrypt the message. There was no need for you to send a key, and even if an attacker intercepted the message, they won't be able to decrypt it without the private key, which only I own.

Digital Signatures

But how do I know the message came from you? You can include your digital signature by using your private key to generate it. Then I can use your public key to verify your signature.

Digital Certificates

What if you never sent a message to me, but I received a message with a digital signature claiming to be yours? In this scenario, suppose an attacker is pretending to be you and puts a public key (the attacker's, not yours) online, advertising that it is "your" public key. Then the attacker uses their private key to create the digital signature and sends it to me. When I use "your" (the attacker's) public key, the signature will verify correctly, and I'll believe the message is yours.

Digital certificates prevent this situation from happening.

You can register your key pair with a certificate authority (CA). The CA issues you a digital certificate with your public key on it and signs it using the CA's private key. Now, if I want to check that an advertised public key is actually yours, I can use the CA's public key on the digital certificate to see your registered public key and compare what's advertised with what's on the certificate.

Link Layer Security

Port Security

A router/switch's port can be configured to only allow certain MAC addresses to connect to the LAN. This mechanism is called port security.

MAC Address Floods and Port Security

Recall that when a switch receives a frame and the destination MAC address isn't in its switch table, the switch broadcasts the frame to everyone. An attacker takes advantage of this by sending a bunch of frames with fake source MAC addresses to a switch, filling up its CAM table. So when a legitimate frame arrives at the switch, the frame's destination MAC address won't exist in the CAM table and the switch will broadcast (flood) the frame to everyone.

This has two effects. The first is that network traffic increases due to flooding, and this can result in a denial of service (DoS). The second is that the attacker can receive the flooded frames.

Restricting the Number of MAC Addresses a Switch Learns on a Port

Limiting the number of addresses that a switch can learn on a port prevents the switch's CAM table from filling up. Note that the CAM table can still learn entries from other ports, so legitimate traffic continues normally.

IP Permit Lists

A switch's IP permit list is a list of IP addresses that are allowed to send traffic to the switch. The type of traffic (e.g. Telnet, SSH, HTTP, SNMP) can also be specified.

Protocol Filtering and Controlling LAN Floods

Broadcast floods can be controlled.

One way is with threshold limits can be set for broadcast traffic. For example, a rule can specify that, at any second, if more than 75% of the traffic consists of broadcast traffic, then all additional broadcast traffic will be dropped for that one-second period.

Another way is to use protocol filtering to allow only certain protocols to send broadcasts. A protocol group can be defined to have certain protocols and ports associated with that group. Then, broadcast messages from only those protocols will be sent to only those ports.

Private VLANs

A normal VLAN allows all devices connected to the switch to communicate with each other. This means that if a device is compromised, other devices on the same VLAN can be attacked from the compromised device.

A private VLAN divides the ports into groups to restrict communication between devices. There are three types of private VLAN ports:

• Promiscuous port: a device connected to this port can communicate with all other ports
  • generally used for communication with the network's router/gateway
• Isolated port: a device connected to this port can only communicate with the promiscuous port
• Community port: a device connected to this port can communicate with the promiscuous port and other community ports

Hosts on isolated ports cannot receive traffic directly from other hosts. All communication is done through the promiscuous port.

ARP Spoofing, Sticky ARP, and Private VLANs

A gratuitous ARP is a message that a device sends to let other machines know its IP address and MAC address. An attacker who has gained access to a compromised device on the LAN can force the machine to send out gratuitous ARPs with addresses that don't belong to the compromised machine. For example, the attacker can spoof the IP address of the network's default gateway in the gratuitous ARPs. This allows the attacker to analyze and/or drop all traffic in the LAN.

Private VLANs protect from this type of attack by providing isolation between the ports on the VLAN.

A sticky ARP also helps against this type of attack. The sticky ARP feature makes sure that ARP entries learned by the switch cannot be changed. So if an attacker takes over a device and tries to send out gratuitous ARPs with different addresses, the switch won't acknowledge those gratuitous ARPs (because the switch already learned the compromised device's address before it was compromised).

Port Authentication and Access Control Using the IEEE 802.1x Standard

802.1x is the standard that defines how authentication should work for devices connecting to LANs.

802.1x Entities

• Supplicant: the device that is trying to connect to the LAN
• Authentication server: the device that performs the authentication
• Authenticator: the middleman that initiates the authentication process and relays messages between the supplicant and the authentication server

802.1x Communications

All three entities communicate using the Extensible Authentication Protocol (EAP).

EAP

There are four types of EAP messages:

• Request
• Response
• Success
• Failure

These four types can be further classified into different types, such as:

• Identity
• Notification
• NAK
• MD5-Challenge
• One-time password
• Transport-Level Security (TLS)

The identity request message is sent by the authenticator to ask the supplicant for its identity information (such as username). The NAK response message is sent by the supplicant to the authenticator if the authentication mechanism offered by the authenticator is unacceptable to the supplicant.

Using EAP as the Underlying Communications Mechanism in 802.1x

These are the steps for what happens when a supplicant tries to connect to a port:

1. The authenticator sends the first EAP-Request identity message to the supplicant to ask for the supplicant's identity.
2. The supplicant returns an EAP-Response message containing its identity, such as its username.
3. The authenticator sends this message to the authentication server.
4. The authentication server sends the supplicant an EAP message corresponding to the type of authentication it wants to do.
5. The supplicant responds with
   • an EAP-Response containing the data the server asked for
   • or an EAP-NAK if the supplicant does not support the requested authentication method
     • the EAP-NAK contains the supplicant's desired authentication mechanism type
6. EAP messages are sent back and forth until the authentication server sends either an EAP-Success or EAP-Failure message to the supplicant.
7. If the authenticator sees that the server sent an EAP-Success, it opens the port that the supplicant has been using for normal data activity.

EAPOL and RADIUS

EAPOL stands for EAP Over LANs. It defines how EAP messages are formatted. Similar to how TCP segments are encapsulated with TCP headers and IP datagrams are encapsulated with IP headers, EAP messages are encapsulated with EAPOL headers.

EAPOL is used for communication between the supplicant and the authenticator. RADIUS is used for communication between the authenticator and the authentication server.

802.1x Functionality

1. The supplicant encapsulates its EAP message in an EAPOL frame and sends it to the authenticator.
2. The authenticator decapsulates the EAP message, repackages it in a RADIUS packet, and sends it to the authentication server.
3. The authentication server sends back a RADIUS packet to the authenticator.
4. The authenticator strips off the RADIUS header, encapsulates the EAP message in an EAPOL frame, and sends it to the supplicant.

Network Address Translation

NAT is the mechanism that changes a packet's IP address to something other than what they originally were. It was primarily a way to reduce IP address consumption, but since it can hide a network's IP address, it also offers some security.

In normal NAT, each RFC 1918 address is converted to its own unique routable IP address. There is also Overload NAT, a.k.a. Port Address Translation (PAT), where all RFC 1918 addresses are translated to one routable IP address.

Security Benefits of Network Address Translation

The router that does NAT/PAT has a NAT table that keeps track of the translations. The NAT table only gets populated if a device sends something out to the Internet.

Here's where the security of PAT comes in. If some random messages destined for the routable IP address arrived at the router without anyone asking for them, the router would drop those messages because it would not know which device to send them to (there would be no entries in its NAT table because no one asked for those messages).

Disadvantages of Relying on NAT for Security

Since NAT only looks at the port number and nothing else, NAT is not that secure. Basically, NAT is not secure because it doesn't do what stateful or proxy-based firewalls do.