TCP and UDP Protocols - USALearning_v401/course/... · TCP and UDP Protocols. Table of Contents ....

TCP and UDP Protocols

Table of Contents

TCP / UDP ........................................................................................................................................ 2

TCP .................................................................................................................................................. 4

UDP ................................................................................................................................................. 5

Ports and Service Identifiers ........................................................................................................... 6

Protocols -1 ..................................................................................................................................... 8

Protocols -2 ................................................................................................................................... 10

Protocols -3 ................................................................................................................................... 12

ARP ................................................................................................................................................ 14

DHCP and BOOTP .......................................................................................................................... 16

DHCP Example ............................................................................................................................... 17

DHCP, BOOTP, and RARP Security Issues ...................................................................................... 19

ICMP Security Issues ..................................................................................................................... 21

Notices .......................................................................................................................................... 24

of 24

TCP / UDP

135

TCP / UDP

Transport Control Protocol (TCP)• Connection-oriented protocol• Guaranteed information delivery; error recovery• Sequencing and acknowledgements• Good for: file transfer, email, web page requests

User Datagram Protocol (UDP)• Connection-less oriented protocol• No guarantee of delivery; “best effort”• Speed advantages over TCP• Good for: audio / video streaming

**135 Let's take that next step and talk about the protocols of TCP and UDP. In TCP what we have is a connection oriented protocol. We want to send lots of data. It could be out of sequence. So, therefore what we'll do is we'll create sequence numbers on that. And you can acknowledge those sequence numbers as we go along. It's good for things like file transfer, email, and web page requests. What happens if we have something that's not nearly as sensitive and not as time sensitive, and we just want to hope that it gets there? Well, then we can use UDP. This is a

of 24

connectionless oriented protocol that is like-- they call it best effort. It's what I call send and pray. When you talk to a DNS server and say resolve this for me, and it responds back to you, well if it doesn't make it because it's such a little tiny request, if it doesn't make it, you'll configure your host so that you have a secondary DNS server that you can go to it. Now, it can be used for audio and video streaming if the upper layer application protocols that you're using all have error correction built into them because UDP does not do error correction. But the nice thing about streaming video is if you miss just a couple of packets, all you're going to get is one of those jerks in there. And that's going to be the only thing that actually happens in that whole thing. Now, if you're losing a lot of packets, and you don't have good error correction on this, then you actually are going to lose your stream. And you're going to have to re-associate. But that little piece of video that you missed when I was here to the one where I was here, and you missed that intervening time, really didn't mess up the conversation for you.

of 24

TCP

136

TCP

Transport Control Protocol (TCP)

Three-way handshake (TCP Flags)

Open Communication

Open Ack

Data

Data Ack

Close Communication

Close Ack

SYN

SYN-ACK

ACK

**136 So, let's look at TCP for a second. When we talk about TCP, we communicate back and forth. And we start this conversation where I say, "I'd like to speak with you." And you acknowledge that I'd like to speak with you. You'd like to speak with me and I acknowledge that you'd like to speak with me. We set up a connection between us and then we do transfer back and forth using the flags of TCP, which are SYN and ACK. The reason why we call it a three- way handshake is because we condense that down to the first as synchronized, SYN. And the response back is SYN and ACK together. That's the only time that we actually put

of 24

two flags in a single packet. Any other time that we put more than-- two or more flags into a single packet, it is abuse of the protocol. It is not programmed for that.

UDP

137

UDP

User Datagram Protocol (UDP)

Send Data

Receive Data

**137 UDP is send and receive. I send this out. I receive the data back. I don't even try. If I fail, I go on to another server. That's how and why we configure two DNS servers in case one is really busy.

of 24

Ports and Service Identifiers

138

Ports and Service Identifiers

TCP and UDP use “ports” aka “service identifiers”

Managed by the Internet Assigned Numbers Authority (IANA)

Ports are numbered 1 through 65535• 0 – 1023 – “Well-known” ports, assigned to specific services

(e.g., DNS = 53, SSH = 22, SMTP = 25)• 1024 – 49151 – “Registered” ports, unassigned, but can be

registered through IANA by developers• 49152 – 65535 – “Dynamic” ports, unassigned and open for anyone

to use

Ephemeral Ports – port used for the source port when establishing a connection

• Linux kernels use 32768-61000• Windows uses 1025-5000

**138 The services are going to listen on particular ports. The most important ports we call the well- known ports, sometimes called the service ports, are from zero to ten twenty-three. And there is a port zero, we just don't use it that often. Now, that's well-known ports. Up above that from ten twenty-four to four nine five-- four nine one five one, we have what are called the registered ports, which are unassigned but people use them by convention for a whole bunch of different items out there, some for a gaming server, some for synchronous

of 24

communication. But they're also restricted use. The last set, what I call the dynamic ports, are above one forty-nine, one fifty-two all the way up to the top. Those are used most of the time for client communications. So, when I, as an end user-- remember my two end users back here for Google? When they came to me and said, "Hey, I want to talk to Google." What I said is, "Well, what's your port?" And they said, "Well, it's twenty thousand." Well, I know that that's probably some upper level ephemeral port. They can use anything that they want. That's fine. I'm going to map the conversation back to them. They should be using four nine one five two and above. So, I get that communication, and I go out and I say, "Okay, here's that communication." What you know as a server on your side Google is that when you come back to me, you know that this firewall is going to hold up in that connection and allow you to pass it through because you came back on the port. You answered back on the port that was requested. And it will map it back to that host. And then that host will go ahead and map that to the application that they are actually using at that moment in time. So, four nine one five two is where you see most of the communication from end user's workstations coming from, up and above there. Now you could call this the ephemeral ports. It's a little bit different. These are

of 24

used for source ports when establishing some sort of connection. Linux users thirty-two thousand. On Windows uses above ten twenty-five. I think it's for them all to be using above forty-nine one fifty-two.

Protocols -1

139

Protocols -1

ARP Address resolution protocol

OSI Layer 2, IP address to MAC address translation

RARP Reverse address resolution protocol

OSI Layer 2, MAC address to IP address translation

PPP Point-to-point protocol

OSI Layer 2, encapsulating protocol for sending data

ICMP Internet control message protocol

OSI Layer 3, diagnostic information and control messages

IGMP Internet group management protocol

OSI Layer 3, multicast transmissions and control

DHCP Dynamic host configuration protocol

OSI Layer 3, provides network settings to hosts

**139 Let's look at some of the protocols here that we've been talking about. But I wanted to roll them all up and say what they're good for. If you're a good WireShark player in the game-- remember I talked about using WireShark? If you're a good player in the game when it comes to WireShark, you will look for these protocols in the stack

of 24

and actually see. You can actually see. You can actually download-- there's a bunch of packet capture libraries that are out there that you can actually look at these protocols. And they'll give you each one of them. So, when we talk about these protocols, sometimes they're also called services. It depends on how you're looking at it. Like for instance ARP is the protocol. It's the address resolution protocol. But all the way at the bottom, DHCP is the dynamic host configuration protocol. But usually what we call it is the IP addressing service. But it is dynamic host configuration protocol. So, for each one of these when you look at these protocols, ask yourself what layer is this at, and how could I abuse this. That will require you to maybe look up the RFC on that particular protocol and figure out how it has been abused, look up OSVDB and see whether the protocol has been abused in the past.

of 24

Protocols -2

140

Protocols -2

RIP Routing information protocol

OSI Layer 3, exchange of routing tables between neighboring routers

BGP Border gateway protocol

OSI Layer 3, makes routing decisions based on path, network policies and/or rulesets

VRRP Virtual router redundancy protocol

OSI Layer 4, provides automatic failover for high availability routers

DNS Domain name service

OSI Layer 5, translates names to IP addresses via DNS tree, port 53

**140 Here are some routing protocols that we pay attention to. Here's our RIP and BGP. Those are the top two on our list. But some times what we need is redundancy. And the example of this is at the edge of our network, we will have two firewalls cross connected to two routers. So, or I'm sorry-- routers from the Internet. There's the big, bad Internet out there. Here's our two routers right here and our two firewalls here. We connect both of them to each other. And then we cross connect them. So, if either one of them fails that the other one could pick up. Well, how would this first

of 24

router know when that second router died, how would they know what the routes were that were communicated in its table? Enter VRRP, virtual router redundancy protocol, which would allow us to do that both at the router, also at the firewall. I think you use in that case you use a different protocol. DNS is our domain name service. It translates fully qualified domain names to IP addresses. And it can do this on port 53 both UDP and TCP. When do we use one versus the other? Well, in UDP the response fits into the little tiny data area of a UDP packet. Suppose that answer is too big, suppose it doesn't fit into this packet right here? Well, what we can send is a response back from the server that says let's switch to TCP because we need to transmit a bit more data. And so, we go from UDP to TCP at that point through that natural convention.

of 24

Protocols -3

141

Protocols -3

SNMP Simple network management protocol

OSI Layer 5, remote administration and monitoring of devices over TCP orUDP port 161

TCP or UDP Port 162 for SNMP TrapsMost implementations use UDP

**141 SNMP, simple network management protocol, is a protocol that runs over port 161 or 162. It depends on how you've got it configured and what tool-- what pieces of it you're using. But this is a management protocol that speaks to all of the devices on your network. If the device can tell you about it's configurations using SNMP because it's turned on and configured, then you can look at the device and see whether it's healthy or not. More importantly, you could also reconfigure it. From an evil standpoint, if we can reconfigure this thing on the fly, that

of 24

could cause us some serious problem. So, we need to think about whether we actually want to expose this to the rest of the world. What I tell a lot of people is I say if you're going to use SNMP, then whatever filtering device you have inbound or outbound, make sure that it does not allow evil on the Internet to request those kinds of things. And more importantly, don't allow those hosts to actually transmit that data out because it could be that the evil can't get through the firewall, but somebody picks up a laptop, carries it into your network, and plops it down. And it's been compromised. And it talks to all these hosts back here and says, "Give me all your SNMP data. And now I'm going to transmit that outbound." So, we don't want some weird rogue host internally transmitting that. Oh, by the way, for attackers, when the attackers are out there, they already know that we're not going to allow that SNMP traffic to go outbound from one of these hosts in here. So, what they do is they usually encrypt it and send it to a webserver. So, unfortunately, even though we could have that detection mechanism in place, it's more for rogue SNMP management consoles rather than true evildoers on the inside.

of 24

ARP

142

ARP

Requests MAC addresses for a given IP address

Maintains a local cache for faster responses

Broadcast messages: “Who has 192.168.1.5, tell 192.168.1.1”

Response to the broadcast is a MAC address

No authentication – very easy to spoof MAC addresses in cache

• First response to an ARP request gets in the cache• Setup for Man-in-the-middle attacks, ARP poisoning

**142 Let's talk a little ARP here for a second. Address resolution protocol will allow us to map a MAC address to a given IP address. In each host and switch, they have a table. And that table keeps a list, on Windows host, it's for the last six hundred seconds, of host it has communicated with knowing their MAC and IP address. So, that when a host above queries and says I don't remember this information, it can check that cache to see whether it's already got this mapping in it. If it doesn't have that local cache, it could check the cache or the cam table that's sitting inside of that switch itself.

of 24

Now, the problem is is that MAC addresses used to be hard wired. And today with virtualization and a whole bunch of other techniques, you can spoof MAC addresses. You can go ahead and mirror somebody else's mac address and knock them off the network. So, ARP is a wonderful tool, but it has been abused at this point. When we attack it, what we're doing is we're trying to knock another host off the network and redirect all the traffic to ourselves thus creating a channel with the original host. When the prior host pops itself back up online, we convince it to map its traffic to us and then pass it through. So, we're not only doing a man-in- the-middle but we're also probably doing a source route exploitation.

of 24

DHCP and BOOTP

143

DHCP and BOOTP

DHCP• Static or dynamic assignment of IP addresses• Administrators maintain a central server which stores configurations• Assignments can be “leased” for a set period of time

BOOTP • Earlier form of DHCP – assigned IP address and pointed host to

a server where it could load its configuration or even O/S

**143 DHCP and BOOTP, these are all how do I get my IP address configuration, how do I know what my sub mask is, where is my router or what's called a default gateway, who are my DNS servers, and tons and tons of other information. In DHCP, we can statically or dynamically assign an IP address. We can even in our DHCP server, we can say I know your MAC address on your computer over there. And I'm going to map it to this IP address. So, that when you pop up and you say, "I'd like to have an IP address." I can say, "Oh I know your MAC address. I usually give you this IP

of 24

address. Here." And I can hand that to you. BOOTP is an earlier version of DHCP. It has a lot less configurations. We don't see BOOTP being used that often these days.

DHCP Example

144

DHCP Example

• Client requests DHCP server.• Server responds with a proposed configuration.• Client requests configuration and sends it back to server.• Server approves request.

If client already has a configuration, it requests same configuration without requesting the DHCP server again.

• Server may respond with DHCPNAK and make a new offer.

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK

**144 When we look at DHCP, what we want to use is the term, DORA, discover, offer, request, acknowledge. That's DORA. That's the standard four step process for getting an IP address. One of the cool things that can happen is if I want a particular IP

of 24

address, and I go to the DHCP server and I say I would like to have an IP address. I've never had one before. You offer me one. And he already owns that IP address. He can respond to me negative acknowledgment, or what's called Naking. And then I can't take that. and we have to start this process over again. By him saying I have that IP address, you also hear it in most cases. And therefore you won't- - you'll say I won't assign that one. I'll assign another one because I saw the nak actually happen. So, it's normally DORA. We don't want to have that nak at the end. The great thing about DHCP is we can assign that. And if I lose my lease, when I come back up and I pop back up, I can say to you, "Hey, I'd like my old IP address back." That can be given to me. But in a dynamic environment, it's not necessary to give somebody the same IP address as long as it's from the same pool.

of 24

DHCP, BOOTP, and RARP Security Issues

145

DHCP, BOOTP, and RARP Security Issues

No inherent security provisions – wide open protocols

No authentication – first response wins – even if it’s a rogue DHCP server pushing malicious configurations to hosts

Denial of service attacks possible against configuration servers

Must rely on Layer 1 security (e.g., physical control), Layer 2 security (e.g., wireless), Layer 3 security (e.g., IPSec)

DHCP Authentication, a standard released in 2001 is available, but not widely adopted.

**145 Now, there's a whole bunch of security issues that we can run into here. Remember there is no security in these protocols. It was never designed for this. There's no authentication. It wasn't designed for this. We could have a host pop up and do a denial of service by sending out a whole bunch of requests, faking the MAC address, and consuming all of the DHCP available addresses from that server. So, what we're going to have to do is we're going to have to rely on other mechanisms like layer one physical control. Or what we can do in the future is DHCP authentication. That's being used more and more often these days. By

of 24

the way, what we're also doing is we're profiling those hosts through 802.1x. And we talk about a NAC before. When we're talking about NAC, and when we communicate with that-- and that's not negative acknowledgment, but that's a network access protocol or network authentication protocol depending on who you talk to. When we do NAC, not protocol-- control, network access control. Sorry. When we do NAC and DHCP together, what happens is we give it a temporary IP address of any kind. And then we profile it based on a whole bunch of other conditions that we can set in place. And then we may give it another IP address later on. So, DHCP authentication is a separate protocol. It is not implemented nearly as much as one of the tools like network access control.

of 24

ICMP Security Issues

146

ICMP Security IssuesICMP normally used for troubleshooting (e.g., ping, traceroute)

Ping of Death – large PING packet (greater than the 65,535 byte size defined by the standard) causes host to crash

Reconnaissance with traceroute – an attacker can map a network using traceroute and the control messages sent from devices

Network mapping with PING – an attacker can find what hosts are alive when they respond to PING requests

ICMP redirect – facilitates a Man-in-the-middle attack by instructing a host to use a different route

Smurf / Fraggle attack – attacker sends an ICMP echo request (Smurf) or a UDP packet (Fraggle) with a spoofed source address

**146 ICMP has a whole host of problems. The ones that we always talk about are the Ping of death and then we also talk about Smurf. When we talk about ICMP as a testing protocol, it's great. But the problem is it's been used as a probing protocol or reconnaissance protocol to see whether hosts are live and communicating and then further the attack after that. What we could also do is we could use the concept of traceroute so we could get a time to live exceeded in transit message back to say we know exactly what routers are in the path from me to you. We can also map

of 24

the network, which is basically the reconnaissance of all the IP address space that we have for IPv4. Interestingly, one of the beautiful things about IPv6 is if we give you a network where the number of IP addresses is that dense, when somebody goes to map an IPv6 network, they can't use the standard network mapping tools because there's too many IP addresses to go after. And the assignment of these IP addresses is random from the entire space of-- well, it's not one cubed meter of bits. It's hundreds of cubes of sand with IP address capability. So, the address space is so big that scanning techniques will take forever. Now, there is a tool that most people use today for IPv4, which is called Nmap that will allow you to scan relatively fast. But it doesn't go fast enough for v6. So, a lot of people are converting over to something called Mass Scan, which is much faster. Both of these tools-- good news, both of these tools can be detected by intrusion detection and intrusion prevention systems. So, we're a little bit better protected. ICMP redirect attacks facilitate the man-in-the-middle attack by instructing the host to use a different router. Do you want to go to the Internet? If you'd like to go to the Internet, and your router is there, I'll tell you that I'm a better router. Talk to me. Come over here, and I'll pass that traffic right through over here. And you go, "Okay. Fine. I'll do that."

of 24

Last attack here is the Smurf. And notice that it also says Fraggle. But from and ICMP standpoint, Smurf sends and echo request to a Smurf amplifier. Okay, so what's a Smurf amplifier? If I am a router on the Internet and you say ping me, or ping a host, that's one to one. But what you can say is ping a subnet. In other words, you know that the host behind me are on this range of addresses. So, you send me a ping 192.168.1.255. And I ping all of the hosts that are back there. Okay, that's pretty cool. That tells you about all those hosts. Now, suppose we want to attack her. The best way that we deal with attacking her is this. We go out and find-- and in this case, now I'm the evildoer. We go out and find a whole bunch of routers that will allow me to ping the broadcast address of all the hosts behind those routers and each one of those Smurf amplifiers. We go back and we find those hosts, those routers that will allow me to pass that, and all those hosts will respond. And instead of saying ping me, which would do a denial of service on me, what we say is I impersonate her. And I say y'all ping her. Everybody do that. And it knocks her off the network. And that's an attack using ICMP echo request to the broadcast of a particular network. That uses Fraggle is just a little tiny bit different. Fraggle does the exact same thing except for a spoof source

of 24

address using UDP packets. And so, what will happen is I will find a Fraggle amplifier. And they will all talk to her. And I will impersonate her so that you will attack her. So, those are our ICMP security issues. I know that reaches over into UDP just a little bit. But we talk about Smurf and Fraggle together.

Notices

2

Notices© 2015 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

of 24

TCP and UDP Protocols - USALearning_v401/course/... · TCP and UDP Protocols. Table of Contents ....

Documents

Transcript of TCP and UDP Protocols - USALearning_v401/course/... · TCP and UDP Protocols. Table of Contents ....