Basics about Networking On Linux:

If you read my article on the OSI model, you got a good overview on communications from that model's perspective, but how does that relate toTCP/IP? We're going to take it a step further, getting into the idea behind thetwo address concept. How does an IP address and a MAC address work together? If you want to hijack sessions and all sorts of lulz like that, you need to understand these concepts. Let's get into it, mates!

OSI, TCP and What's Going on Here?

A good way to understand what a protocol is, would be to view it like a language. If people were network interfaces and all spoke their own language, there would be no way for them to properly communicate. A protocol works the same way, by agreeing to use certain methods or standards, many groups can build and create things that can all communicate with each other. So when you see TCP/IP protocol, think of it like a collection of rules computers must all follow to allow the millions and millions of networked machines called the Internet to function.

OSI was never meant to be just a model. Back in the 1970s, it was a competing protocol against TCP/IP and was actually a better protocol in design. The main reason it didn't take hold was that its addresses werehexadecimal and very complex. In fact, it was thought back then, that it hadtoo many available addresses. Being based in hex, it allowed far more than the current protocol standard of IPv4. I should point out that the next version of IP, version 6, uses hex addresses which allow many more available ranges then IPv4. Go figure.

Examples of addresses include:

• Hexadecimal - 12:34:56:78:9A:BC
• IPv4 (current standard) - 74.125.225.98
• IPv6 (new format) - fe80::223:4eff:fec0:5b48

A Tale of Two Models

OSI is still used today to describe network communication and for standards to unite, while the TCP model is used to show relation between the various protocols it contains. Below is a diagram of how the two map out to each other.

The first thing you might notice is that TCP/IP is not just one protocol, but an entire suite of protocols. Next, you should notice that the layers of the TCP/IP architecture and the OSI model line up more or less the same.

Layers one and two of the OSI model are considered to both be physical and local, so they are simply grouped together as the Network Interface Layer under TCP/IP. The Network layer is just renamed the Internet layer and carries the same functions. Following that, you can see layers five through seven of OSI have been compiled into the Application layer, as that is where they operate.

Still with me? Now let's take a look at all of these three- and four-letter abbreviations in the suite. This is the good stuff coming up here.

The TCP/IP Suite

The TCP/IP suite is where we talk about things like FTP, DNS and other protocols you might have heard and read about before. Again, looking at the picture above, we can see what protocols are used in what layers.

An entire book could be written on the TCP/IP suite—and they have. To keep things in focus, we are only going to discuss a few protocols here. Feel free to ask any other questions about the protocols in the comments.

A good example of this is the Transport layers of both the OSI and TCP models. When data arrives there, it has two options for transport, TCP and UDP. TCP allows for reliable transit, where as UDP is unreliable. If you are wondering why you would ever want to send something unreliable, here is the answer...

TCP vs. UDP

In a very short nutshell, when you send a request with TCP, you will always get a confirmation of its receipt. This is like me throwing you a ball, you yelling "I got it!", then throwing it back to me, where I would then yell "I got it". But what if I drop it? I would simple yell back, "I need it again!", and would wait until you threw me a new one.

In contrast, UDP is like you throwing me ball after ball and just hoping I catch them. If I drop one or sixteen—it doesn't matter—because you have no way to know.

UDP sounds pretty bad right now, but listen to this: services like VOIP and online games are too fast for TCP. Imagine you were playing Halo and you dropped a packet or two. Can you stop and wait for it? Of course not. You would see a little jump in the frame rate and you'd keep going. If you had to wait for it to get back to you, you would surely be fragged. The same applies if you were talking to your mate on Skype and you dropped a few packets; it makes no sense to pause the conversation to retrieve them.

TCP is great when you need to make sure all the packets arrive and in order. Web browsing and the like would be awfully hard without having reliable transportation.

It is the Transport layer that determines, based on its parameters, what protocol to use.

IP and MAC Addresses

Every single packet being sent around has two addresses inside of it—anInternet Protocol and a Media Access Control address. An IP address really only identifies your network, as all internal IP addresses are actually privateand handled by Network Address Translation (NAT) at the router. You might have an IP address from your ISP of 201.95.87.98 that identifies your network, and your actual computer might have a private, inside-the-network address of 192.168.1.67.

This is done so that many devices, like your PlayStation and your computer, can get on the Internet at the same time, while only needing one IP address. If every single device online today had its own address, we would have already ran out of new ones to use!

So, where does a MAC address come in? As it is, IP addresses are of no use inside of your network, as your machines don't use them to talk to each other.

Where IP addressing functions at the network layer, MAC addressing works at the data link layer. It's a slight oversimplification, but one can think of IP addressing as supporting the software implementation and MAC addresses as supporting the hardware implementation of the network stack. The MAC address generally remains fixed and follows the network device, but the IP address changes as the network device moves from one network to another.

So, how in the world does this actually work? Your network maintains a mapping between the IP address of a device and its MAC address. This mapping is known as the ARP Table.

Putting It All Together: Address Resolution Protocol

ARP stands for Address Resolution Protocol and it is used to associate aNetwork layer address (IP address) with a Data Link layer address (MAC address).

Let's say you have some data to send. When the data gets to the Networklayer, it will put on the destination IP address. All of this info (the Networklayer datagram, aka packet) is passed down to the Data Link layer where it is taken and placed within a data link frame.

Based on the IP address and subnet mask, your computer should be able to figure out if the destination IP is local to your network or not. If the IP is local, your computer will look in its ARP table, the table where the responses to previous ARP requests are cached, to find the MAC address.

If it's not there, then your computer will broadcast an ARP request to find out the MAC address for the destination IP. Since this request is broadcast, all machines on the network will receive it and examine the contents. If the IP address in the request is their own, they'll reply back. On receiving this information, your computer will update its ARP table to include the new information and will then send out the frame addressed with the destination hosts MAC address.

Request for Comments

With all this talk about protocols, I'm sure you have some questions about specific ones you have come across. It turns out the Internet Engineering Task Force has put together a memorandum describing, collecting, and categorizing details about protocols, research, and ideas on how the actual Internet functions. This is needed because there's no one authority that mandates certain protocols to be used over other ones, and in fact, you can create and submit your own for review and use!

Want to learn the more technical components of UDP, ARP and TCP? Check out those RFC white papers describing the protocols.

Imagine you're in Paris and you need to get to Versailles. Looking around for directions, you come to a cold realization—you do not speak a lick of French! How are you going to get to Versailles and what happens if there is a detour? It will be a difficult struggle, and you'd probably get lost and eventually fail. This is why it's important to know some of the country's language before taking that trip in the first place.

This is the same approach you should take with IT security. Only this time, you are not in Paris, you are in your bedroom looking for open and vulnerable machines on some host ranges. You look at the IP addresses in slight confusion—you know what an IP address is, but do you know what it does? Can you tell how large the network is from its IP? This is the language of the Internet.

In this article, I will provide a gentle technical introduction to IP addresses, explaining how they are more then just a bunch of numbers that point to a resource. These networking topics will slowly ramp up, and by the time all is said and done in this series, you will find yourself much more comfortable at the helm.

What Is an IP Address? Really?

In a nutshell, an IP address is a unique identifier for a location and/or resource on the Internet or TCP/IP network. I am sure most of you reading this knew that, so let's break those numbers down a little bit.

The current version of Internet Protocol, or IP, is version 4. This version allows four octets of data to represent an IP address. Each octet is considered to be the same as a byte, and there are 8 bits in every octet for a total of 32 bits. A bit itself can be one of two values, usually represented as 1 or 0. Finally, each octet is separated by a period.

The newer IP version 6 (IPv6) standard features addresses 16 bytes (128 bits) in length, however this has not gained widespread support yet, and IPv4 remains the standard still today.

There are two notations to show an IPv4 address—decimal and binary. You are most likely familiar with the former example of 86.118.34.65. Probably less so with a binary address like 11000001 10000011 00011011 11111111. 

Want to learn more about binary? Click here.

IP Address Classes

An address is also divided into three classes; A, B, and C. While there aretwo more classes, they lay beyond our scope right now, as they are only used for special roles like multicasting. These three classes have a fixed number of IP addresses, as shown below. In each address, there is a "class identifier," a "network identifier" and a "host identifier" encoded.

As you can see, an A-class network has a large amount of possible hosts, whereas a C-class network only has 254 available.

I know you're already burning to know why a C-class only has 254 host addresses available, and not the full 256. If you calculated the number of hosts for the B- and A-classes, too, you'll have realized that they are also smaller by two hosts from the theoretical maximum. The answer is that the lowest address, the one with all bits in the host part set to 0 is used to address the network itself, and the highest address, having all bits of the host part set to 1, is used as broadcast address, meaning all hosts in this net.

• A bit can be one of two values, usually represented as 1 or 0.
• A byte is 8 bits.
• As a binary sequence of eight 1's or 0's. Ex: 11001100
• As a decimal number. For example, the above binary number's decimal equivalent is 204.
• As there are 8 bits in a byte, each byte can represent 256 possible values.

So, the binary would be 11111111.11111111.11111111.11111111, making the address you see 255.255.255.255.

Likewise, a binary address of 00000000.00000000.00000000.00000000 would be 0.0.0.0.

This all might seem confusing now, but hang tight, because it will make much more sense in my next article about subnets and diving up a network. For right now, just file this little bit of information away. The key is to take away the idea of separate classes and how they determine network size.

Domain Name System

Humans, being somewhat different from computers, have difficulty remembering lots of similar numbers. Working with names is much easier for us and less prone to errors. That's why you rarely see the bare numbers on the Internet. In fact, when you enter a URL into your browser to view a website, your request must first be translated from the readable written address, into an IP address that can be routed. This translation is done by the Domain Name System, in short: DNS.

If you send off a request to connect to a certain website, let's say www.yahoo.com, you actually first send a request to the DNS server to lookup and translate into the correct IP address of 209.191.122.70. With this IP address, you then make the actual connection to the website. This happens behind the scenes and usually quick enough you don't notice.

Also note, there is nothing stopping you from just typing an IP address into your web browser and connecting that way either.

I will go into how to divide your networks up using subnetting. We will then go over DMZs and why you must know how to work through them in order to get to the real target and all of the juicy data.

Commonly Used Addresses and Values

• 127.0.0.1 — The loopback interface address. All 127.x.x.x addresses are used by the loopback interface which copies data from the transmit buffer to the receive buffer of the NIC when used.
• 0.0.0.0 — This is reserved for hosts that don't know their address and use BOOTP or DHCP to determine their addresses.
• 255 — The value of 255 is never used as an address for any part of the IP address. It is reserved for broadcast addressing.

Wouldn't it be nice to just sit at your buddy's house, plug into his network, and see exactly what he's doing? What if it was as easy as that? What makes packet sniffers like Wireshark such potent tools is that a majority of local area networks (LANs) are based on the shared Ethernet notion.

In a shared Ethernet, you can think of all of the computers in a LAN as being plugged into the same wire, and all of the traffic that travels through it can be captured. Packet sniffers are more formally known as network analyzers and protocol analyzers. But what traffic are we talking about?

Everything. Granted encrypted data will be unreadable to you, you can still see it, and anything that is sent plain text (not encrypted) can be grabbed very easily. This includes passwords, logins, instant messaging conversations, emails, etc. Everything.

For example, assume that your network card picks up a packet fromsomeone else's network. Normally, once the packet is handed off, the operating system must determine exactly what type of packet it is. To do so, it strips off the Ethernet header of the packet and looks at the next layer. Perhaps it's an IP packet.. Well, the OS must now strip of the IP header and determine which type of IP packet it is. Finally, let's say it's determined that the packet is a UDP packet. The UDP header is stripped off and the packet payload (the data) is handed over to the application that the packet was sent to.

Now, this is an oversimplified version of what really goes on, but I'm trying to illustrate a point. Packet capture allows us to intercept any packet that is seen by the network device, and grab it in its entirety, headers and all. Regardless of which port is being sent to, or even which host, for that matter.

Before we get into grabbing frames and causing mayhem for lulz, we need to explain what a packet is and the concept of a frame. I believe knowing how something works is much better than just learning to do it, so let's dive into some networking!

The Open Source Interconnection (OSI) Model

The OSI model is a layered model that describes how information moves from an application running on one networked computer to an application running on another networked computer. Think of it this way, the OSI model describes the steps to be used to transfer data from one networked device to another. Easy.

The model is divided into seven layers, as shown below. If you are serious about learning networking and information security, my advice is to memorize this image. I know it looks long and complicated at first, and trust me it is. But the more you use this (and you will) the faster it will come to you.

The reason for using a layered networking approach is that a layered model takes a task, such as data communications, and breaks it into a series of tasks, activities or components, each of which is defined and developed independently. OSI layers also allow extensibility. New protocols and other network services are generally easier to add to a layered architecture.

The basic idea behind the OSI reference model is this—Each layer is in charge of some kind of processing and each layer only talks to the layers immediately below and above it. For example, the sixth layer will only talk to the seventh and fifth layers, and never directly with the first layer. Remember this and it gets easy.

When your computer is transmitting data to the network, one given layer will receive data from the layer above, process what it received, add some control information to the data that this particular layer is in charge of, and send the new data with this new control information added to the layer below.

When your computer is receiving data, the contrary process will occur. One given layer will receive data from the layer below, process what it received, remove control information from the data that this particular layer is in charge of, and send the new data without the control information to the layer above.

What's important to keep in mind is that each layer will add or remove control information that it is in charge of. An acronym to help remember the model from bottom to top is “Please Do Not Throw Sausage Pizza Away.”

Layer 1: Physical

The physical layer describes the physical medium that data travels through. Think Ethernet cables, Network Interface Controllers, and things of the like. It also provides the interface between network and network communication devices.

Layer 2: Datalink

The datalink layer is where the network packets are translated into raw bits (00110101) to be transmitted on the physical layer. This is also a layer that uses the most basic addressing scheme, Media Access Control addresses. Think of a MAC address like a diver's license number—it's just a number that is unique from anyone else's.

Now, think of an IP address like a person's mailing address. The mailing address groups people into zones by using the zip code, city, state, and street identifiers.

Summary of Layer 1 and 2

When a network card receives a stream of bits over the network, it receives the data from the wires (the first layer), then the second layer is responsible for making sense of these 1s and 0s. The second layer first checks the destination MAC address in the frame to make sure the data was intended for that computer. If the destination MAC address matches the MAC address of the network card, it carries on.

Layer 3: Network

The network layer determines how data transmits between network devices. It also translates the logical address into the physical address (computer name into MAC address). It's also responsible for defining the route, managing network problems, and addressing. Routers also work on the network layer.

The most important part of understanding this third layer is knowing that routers make decisions based on layer three's information. Routers are machines that decide how to send information from one logical network to another. Routers understand the Internet Protocol (IP) and base routing decisions on that information.

Layer 4: Transport

The transport layer accepts data from the session layer and breaks it into packets and delivers these packets to the network layer. It's the responsibility of the transport layer to guarantee successful arrival of data at the destination device. Transport Layer Security also runs on this layer.

Layer 5: Session

The session layer manages the setting up and taking down of the association between two communicating end points, called a connection. A connection is maintained while the two end points are communicating back and forth.

Another way to look at it—picture your computer. You're browsing the web, downloading from an FTP server, streaming some music, and who knows what else, all at the same time. All that data is coming into your computer, but it would make little sense if the FTP data was being sent to yourPandora tab, wouldn't it? It's in this layer that ports are used and that data is properly directed.

Layer 6: Presentation

The presentation layer resolves differences in data representation by translating from application to network format, and vice versa. It works to transform data into the form that the application layer can accept. Remember, each layer can only 'talk' to the layer above and below it.

This layer is mainly concerned with the syntax and semantics of the information transmitted. For outgoing messages, it converts data into a generic format for the transmission. For the incoming messages, it converts the data to a format understandable to the receiving application. This layer also formats and encrypts data to be sent across a network, providing freedom from compatibility problems and issues.

Layer 7: Application

The application layer is the top layer of the model. It provides a set of interfaces for applications to obtain access to networked services. This layer also provides application access security checking and information validation.

Common services that will seem familiar include streaming music, email, and online games. When you think of the application layer, think of just that—applications.

Let's Steal Some Data!

Now that we have a grasp on the OSI model, we want to get into Wireshark. If you're running BackTrack, you already have this set up in your /pentest directory. Otherwise, let's go ahead and grab the packages. If you want the latest version of 1.6.5, you must download and compile the source code. If you don't mind the older 1.6.2 version, you can use the repositories. In this case, I recommend the repos if you feel shy about compiling from source and handling dependencies. If you want the bleeding edge, grab the source. As of this writing, it's a small difference.

Free BSD users can type:
$ sudo pkg_add -r wireshark

Debian-based systems can type:
$ sudo apt-get install wireshark

Arch users can type:
$ sudo pacman -S wireshark-gtk

If you do wish to compile from source, follow along below:

Step 1 Get All The Required Packages

Make a new temporary directory, because we're going to download some files. Wireshark also requires libpcap, glib, and GTK+ as dependencies. Backtrack users should again be good to go, but others might need to get these packages first.

Download the source code with Wget and compile it up.

$ wget http://www.tcpdump.org/release/libpcap-1.2.1.tar.gz 
$ wget http://ftp.gnome.org/pub/gnome/sources/glib/2.30/glib-2.30.2.tar.bz2
$ wget http://ftp.gnome.org/pub/gnome/sources/gtk+/3.2/gtk+-3.2.2.tar.bz2

Windows users can grab the 32-bit and 64-bit versions of Wireshark. Linux users can simply retrieve the source code by typing:

$ wget http://wiresharkdownloads.riverbed.com/wireshark/src/wireshark-1.6.5.tar.bz2

Step 2 Build and Install the Dependencies

Untar each package you downloaded, then move into the new expanded directory and type the following for each:

$ ./configure
$ sudo make
$ sudo make install

Step 3 Build and Install Wireshark 

Now we can get to installing our network protocol analyzer, Wireshark. If you have any issues or problems at this stage with dependencies, check out this helpful link.

To get started, let's type:

$ tar xvjf wireshark-1.6.5.tar.bz2 && cd wireshark-1.6.5
$ ./configure
$ sudo make
$ sudo make install

Step 4 Configure, Capture and Conquer

Now that we have everything up and running, let's go ahead and fire up Wireshark. We should be greeted with the following screen:

You'll see a section titled Capture Help—I highly encourage first time users to give it a whirl. Also notice that if you had captured packets on another computer, you could import that file into Wireshark for analysis, as well.

Under Capture, it lists all the interfaces on your system Wireshark can use to listen in on. /dev/eth1 is my wireless interface, so let's click on that.

Here, we listened in on the interface only for a few seconds and picked up 24 packets. The first column lists the packet number, ordered in how they were received. The next column lists the time in seconds, which began when Wireshark started that session.

Source and Destination

The Source and Destination columns list the addresses contained in the header. You will notice packets that are addressed for you will show your internal IP address. This is because right now we are listening to the wireless traffic inside a network and as such, are behind the router. Packets coming to the receiving computer have already been stripped of the network IP address by the router. Remember how each layer of the OSI model can only talk to the layers above and below? That's because as the data travels up and down the layers, the control info is added to it, and stripped off as it passes.

Next to that lists the Protocol of the packets received. Notice in the image where it says TLSv1 and Encrypted Alert in the info status? TLS stands for Transport Layer Security and if you remember from above, it runs on the transport layer.

Packet Overview

Under that lies an overview of the packet, giving you details such as size and what ports it was addressed to. Click on one of the entries and move your keyboard arrows up and down. See how the highlighted block of jumbled letters and numbers moves along with it? All those jumbled letters and numbers are actually hexadecimal code, and next to it is a quick decoded overview of the data. If items are being transmitted encrypted, then this won't be enough yet, but anything sent plain text will show up here.

In Action

Here, I opened my browser and typed www.google.com into the bar. As I briefly explained in my darknet article, your computer sends a request to aDNS server to find out the IP associated with google.com. The server then returns the address back to you and your browser connects to it. We can see this in action by sniffing the traffic as it happens.

Here you can see the protocol is DNS. The first packet is querying the server and the second packet is responding.

In Closing

We are another step further in giving you the skills you need to navigate the Internet like a pro. If some of this didn't quite make sense, I encourage you to check out some more back knowledge. 

Questions? Comments? Have anything to add to this walkthrough? Leave us a comment.