Networking | Commondork

Archive for the Networking Category

Temporal Key Integrity Protocol (TKIP)

Posted August 17, 2009 at 10:44 am in Networking | No Comments

Recently my girlfriend and I moved into a new apartment on Milwaukee’s Lower East Side. We had been using an old Linksys router at our previous quarters but with the new apartment only having a single cable drop in the most inconvenient location possible, we decided to go wireless. I had never used a wireless router at home before so I had a lot of research ahead of me. We wanted speed, range, security, and as inexpensive as possible. We ended up purchasing the Linksys WRT54G2 router due to it being a middle-of-the-road wireless router. The WRT54G2 uses 802.11g, contains two internal antennas and has an output power rated at 18 dBm. These characteristics met our first two requirements but what was there for security? The router offers WPA2, WEP, Wireless MAC Filtering and can use security keys of 128 bits. This seemed like the standard suite and the router was within our price range.

Setting up the router was easy and once everything was in working order I decided to start tinkering with its configuration. Under the Wireless Security settings I noticed a few interesting options. The ‘Security Mode’ option allowed me to select Disabled, WPA Personal, WPA Enterprise, WPA2 Personal, WPA2 Enterprise, RADIUS, and WEP. If I selected WPA Personal I noticed that the ‘WPA Algorithm’ option would set itself to TKIP with no other option. If I chose to use WPA2 Personal I was given a choice of AES or “TKIP+AES”. Having only dabbled with cracking WEP networks before I was curious as to what TKIP was.

Are you wearing your SOCKS?

Posted July 4, 2009 at 8:25 pm in Networking | No Comments

A while ago we looked at using Tor and Privoxy to allow us to remain anonmyous while browsing the web. I briefly mentioned SOCKS while we were configuring our web browser to route traffic through the onion network. This prompted me to take a deeper look at SOCKS.

Demilitarized Zone (DMZ)

Posted August 27, 2008 at 7:31 am in Networking | No Comments

The demilitarized zone (DMZ), also known as the perimeter network, is a physical or logical subnetwork that creates separation between an internal network and an external untrusted network (usually the Internet). The DMZ provides an additional layer of security to the internal network.

External services such as mail servers, DNS servers, FTP servers, and web servers are exposed within the DMZ. These types of servers are commonly targeted by attackers to gain access to the internal network if they reside within the internal network. By relocating them to the DMZ, the attacker will still not have breached the internal network even if they are able to compromise one of these servers.

This rationale may seem a bit confusing but many of these servers and services are not critical to business continuity. All of these servers will have redundancy and readily available backups. If these servers were within the internal network, an attacker essentially has free reign to any trade secrets, financial data, employee data, databases, etc. With these servers in the DMZ the assets essential to business continuity are protected within the internal network.

Any service that is provided to users in an external network should be located within the DMZ. A mail server in the DMZ should forward incoming mail from the external network to an internal mail server and the internal mail server will pass outgoing mail to the DMZ mail server. This creates separation of duties amongst the mail servers while providing an additional layer of security to the network.

There are two common ways to implement a DMZ architecture: single firewall and dual firewall.

Synchronous vs. Asynchronous Communication

Posted August 27, 2008 at 7:28 am in Networking | No Comments

Synchronous and Asynchronous communication refers to the manner in which data is transmitted over a transmission medium.

Synchronous communication devices or systems must use an external clock to synch the devices to the same time. This is commonly done via the use of GPS satellites which provide a timing reference if the systems are geographically far apart.

The reason this timing signal is needed is to provide an agreed upon start and stop condition to the data stream. The receiving device must know when the transmitting device has started to send data and when the transmitting device has stopped sending data. The timing signal is agreed upon before data is exchanged and during periods of idle activity, the devices actually exchange special characters or messages to remain in synch with one another.

Example, if the transmitting device sent the following message in frames: “The”, “Information”, “Systems”, “Security”, “Association” and the receiving device was in disagreement as to when each separate frame began and ended, it may actually interpret this to be “TheInfor”, “matiom”, “Systems”, “Securi”, “tyAsso”, “ciation”. After these frames are processed and presented in the manner they should have originally been, they will be unintelligible.

The timing signal, which is an electrical signal varying in voltage, is usually sent on a separate wire in order to avoid confusion on the data wire, however, this is not always the case. Due to this timing source, synchronous communication devices perform minimal error checking.

Asynchronous communication, which many modems use, has no additional timing source. The transmitting device inserts start bits, stop bits, and optional parity bits into the data stream which inform the receiving device when the data frame began, when it ended, and if it was transmitted with or without errors.

A message is broken up into numerous frames which are limited in their size (MTU) via bytes or ASCII characters. Each frame then receives a start and stop bit and are then transmitted.

Modems employ asynchronous communication due to their unreliable nature. Modems using an RJ-11 connector were often victim to line spikes and induced noise and would unsynch the timing signal needed for synchronous communication.

Examples of asynchronous communication include the RS-232 serial interface (commonly used in communication equipment) and V.2 modems.

An asynchronous communication service or application does not require a constant bit rate (it is variable). Examples are file transfer, e-mail and the World Wide Web. A synchronous communication service can be realtime streaming media, for example IP telephony, IP-TV and video conferencing.

Address Resolution Protocol (ARP)

Posted August 17, 2008 at 10:48 pm in Networking | No Comments

The Address Resolution Protocol is fairly straightforward. Each device on a network contains two types of addresses: an IP address and a MAC address. This protocol was developed to help resolve an IP address to a unique MAC address.

Each device on the network has an IP address that is capable of changing depending on DHCP settings or IP configuration. Each device also has a unique Media Access Control address that is ‘burned’ into each network interface card. ARP matches IP addresses to MAC addresses and vice versa using four message types: ARP Request, ARP Reply, Reverse ARP (RARP) Request, and RARP Reply.

An ARP Request is used when a device wants to know who is using a specific IP address.

An ARP Reply is just what it says. It is a reply to the ARP Request that informs the requesting device that is has the requested IP address and also includes its MAC address. Most of the time when devices do not possess the requested IP address that is within the ARP Request they will ignore the request and only the device containing the requested IP address will issue an ARP Reply.

A RARP Request is just the opposite of an ARP Request. The requesting device wants to know who is using a specific MAC address.

A RARP Reply informs the device issuing a RARP Request that it is using this MAC address and includes its IP address as well. Again, a RARP Reply works in much the same manner as an ARP Reply.

Each device contains an ARP table. This table has a short life span and contains a list of matched IP and MAC addresses. This allows networking devices to avoid broadcasting ARP and RARP Requests across the network which reduces network overhead and increases network throughput.

References: RFC 826 and RFC 903

Network models

Posted August 17, 2008 at 8:19 pm in Networking | No Comments

Network models define a set of network layers (also known as a stack) and how those layers (protocols) interact with one another. There are two commonly used network models in use today, TCP/IP (Transmission Control Protocol/Internet Protocol) and OSI (Open Systems Interconnection). By using network models we enable devices using the same network model to communicate with one another more effectively and we’re better equipped to understand how the network works.

TCP/IP Model
The TCP/IP model is by far the most widely used model in existence today. Just about every modern networking device supports the TCP/IP model including computers, mobile devices, and even a few appliances. This model is also known as the DoD model and the Internet model. It was created by the efforts of the U.S. Department of Defense and various universities in the 1970s.

The TCP/IP model defines an enormous collection of protocols that are governed by their respective Request For Comments (RFC). It is human nature to categorize anything and everything to help us understand and remember. The TCP/IP model is no exception. It separates these protocols into four layers (or categories) to make it easier to understand how these layers (protocols) interact with one another. The four layers of the TCP/IP model are the Application, Transport, Internet, and Network Access layers with each layer providing a service to the layer above it.

The Application layer is the layer most of us will interact with on a daily basis whether we realize it or not. The protocols used in the Application layer provide services to the software running on a computer, such as retrieving the web page of your favorite website. The Application layer doesn’t care what the application looks like, what new features it has, what language it’s written in, or what you think of it. The Application layer defines what services the software might need, such as HTTP (web browsing) or POP3 and SMTP (e-mail). There are many protocols supported within the Application layer, such as HTTP, SMTP, POP3, FTP, Telnet, IRC, IMAP, SSL, PPP, etc. Continue reading..

Page 1 of 11