Network Concepts Overview
This section provides a brief overview of some network protocols; many books and RFCs are maintained on the subject. Many protocols have had security issues because messages can be piggybacked and protocol services can be faked out into doing something insecure . There is no shame in having a system compromised; the difficulty arises when a system is broken into and no one knows about it. In addition, network protocols provide very important aspects of security; for example, knowing how a packet is transmitted inside a LAN from an outside source is valuable information to determine if the packet is valid, and whether the packet should be stored locally (in a trusted domain). The next sections provide information on some basic concepts and prepare you for the more advanced topics addressed later in this chapter, which are building blocks to subsequent chapters on network security. IP addressesThe IP address is the logical address of a specific machine based on the format of the Internet Protocol. The IP address is based on a subnet mask; it is this mask that specifies what parts of the address are viable for use. The subnet mask can tell the routers which IP addresses make up the segment or LAN. For instance, using 255.255.255.0 tells the router and machine that all addresses except the last digit live on the same segment. So addresses 169.169.169.0 through 169.169.169.255 make up the same segment. The router keeps a routing table. The router uses the routing table to direct all packets to the available machines under the router's segment.
Figure 21-1 shows two LANs with routers and using IP addresses.  Figure 21-1: Two LANs by address These address segments are not arbitrarily assigned. The Network Information Center, which registers protocol ports, IP addresses, and domains for the Internet, also registers these addresses. Although IP addresses accurately describe the relationships within the domain, their format is problematic for administrators and users. To overcome this limitation, the domain and resources within the domain can be managed using a DNS. The purpose of DNS is to resolve a human-readable address to an IP address for specific machines; these human-to-machine mappings are entered through the DNS's services table. This adds another layer of logical names to the addresses. Figure 21-2 shows how the introduction of DNS names affects the two LANs from Figure 21-1; each workstation now has a logical name , there is a DNS server, and the DNS table maps the logical names to the address.  Figure 21-2: Two LANs by domain name The creation of DNS tables simplifies the process of looking for a particular machine and knowing the logical topology for humans . The network does not understand these tables until they are resolved through the DNS. Until that point, the packets are still transported through their IP addresses from a source to a destination. The IP header that contains the addresses is a wrapper for the higher layer protocol, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Figure 21-3 shows the structure of an IP packet . The packet is an individual unit of data that is being transmitted. These units of work contain many more protocols; the protocols identify how the data is to be sent across the networks. The packet across the network takes the form of an IP packet. An IP packet contains information that makes the delivery possible, such as the destination (the IP address to send the packet to) and the source (the IP address that sent the packet). Many of the other fields in an IP packet describe the packet metadata information, such as packet size, IP version, and time before the packet times out (the TTL, or Time To Live). The IP packet is normally created in a device driver; the device driver knows that it will be using IP to communicate across the Internet.  Figure 21-3: IP packet
An IP packet contains an IP address that is a logical address for routing the IP packets. This is not a physical address, but one configured for the machine's and the network's configuration. In fact, the MAC address, which is part of the network card used for a physical connection, is the closest thing to a physical address. The network card's manufacturer assigns the MAC addresses, which must contain different numbers . The networks are connected in tree-like segments, where the router moves packets based on the destination address. A network topology is the mapping of machine addresses. Figures 21-2 and 21-3 give examples of network topologies. Although I have discussed how addresses are resolved for a given packet, I have not tackled the port number and its resolution. The port is the location of the service on the machine. The port number is a logical location for the connection of that process.
Protocols use tables that can usually be found in a services file. The port numbers are not part of the IP packet, so they must be part of the packet that the IP wraps, such as TCP and UDP.
TCP and UDPTCP is normally referred to as a connection-oriented protocol. In contrast, because UDP is used for broadcasting and multicasting, and a full connection is not required for the sending and receiving of packages, UDP is normally referred to as a connectionless protocol. A typical use of UDP is a stock ticker, where a service broadcasts stock information but there is no guarantee by the protocol that the message is received. Figure 21-4 shows the structure of a UDP packet; you can see that the UDP packet is simple and straightforward. It contains a source port and destination port, a checksum to ensure the integrity of the data, the length of the data, and the data itself. There is no guarantee in what sequence the data will come in. It could be that the start of the stream arrives after the middle of the stream. For the example of a stock ticker, each stock should be a separate and independent packet.  Figure 21-4: UDP packet
The TCP packet is a bit more complex because the protocol itself guarantees the delivery. There are six 1-bit flags that help with fulfilling the connection. The flags of the TCP packet are very important, as explained in the following list:
The window size is the number of bytes that can be sent to the receiver beyond the bytes being acknowledged. This byte count is not the total number of bytes allowed in this field, but the number of bytes allowed on top of the acknowledged size; this is the reason why that number needs to be added to the acknowledged size. Figure 21-5 shows a TCP packet.  Figure 21-5: TCP packet A socket or connection refers to the combination of port number and IP address. The term "socket" is a semaphore to a power cord connecting into a wall socket. A socket pair refers to the combination of port number and IP address pairs for both source and destination. It is called a socket pair because it connects at both ends. The term Sockets commonly refers to the socket wrapped into an API. Up to this point, the transportation and the protocol headers managed the data. The content of the data, besides size and checksum, is really unknown to the lower protocols. The lower protocols' responsibility is to transport data reliably regardless of what the data contains. The lower protocols handle the data generically and some of the packetizing of the data is handled at the device-driver level communicating directly to the network card. To communicate to the device driver, the developer uses the Socket API; this API provides a standard way to specify whether the protocol is UDP or TCP, which ports and addresses to use, and to translate the data into the protocol. The Open Systems Interconnection (OSI) has developed a model to show the different protocols that wrap the network transportation of data. Figure 21-6 shows the OSI model and demonstrates that there are several protocols that wrap the data from the physical network.  Figure 21-6: The OSI model The hardware also follows standards such as the Carrier Sense Multiple Access/ Carrier Detection (CSMA/CD) protocol. The CSMA/CD listens for a carrier signal on the wire, and if one is not there, it believes that the wire is clear to send a packet. If a collision happens while sending a signal, it is re-sent. From this point, a packet contains Ethernet frames to signal the beginning and end of digital data and to indicate whether collision signals are detected at signal thresholds. The digital data is the IP information that wraps either TCP or UDP, and the devices will unwrap the protocol (either TCP or UDP) based on the protocol header. The protocol header is defined in the wrapped IP. If the TCP header is used, the device driver knows to respond to the connection and to guarantee the delivery; otherwise , if the header is UDP, the device driver will know not to respond. The device driver and underlying layers may communicate to the protocol services through the socket API. The Socket API is supported in Java in the java.net package. Listing 21-1 gives the SocketServer example: a typical example of a listener that receives a connection, sends some data, and prints what it receives. The start of the work can be seen in the ServerSocket initialization. The initialization in the LOCAL_ONLY block shows a listener being created to receive connections only from the local machine. The other initialization receives connections from any machine on port 2000. The accept() method waits for the client to connect to the listener and returns a reference to the client socket to read and write as a stream. This sample will create a thread to read and write to the client socket. Listing 21-1: The SocketServer class: A socket listener example
package com.richware.chap21; import java.io.*; import java.net.*; /** * Class SocketServer * Description: Demonstrates a listener for connections. * * Copyright: Copyright (c) 2002 Wiley Publishing, Inc. * @author Rich Helton rhelton@richware.com * @version 1.0 * DISCLAIMER: Please refer to the disclaimer at the beginning of this book. */ public class SocketServer extends Thread { protected Socket socket; /** * Port number is set to 2000 to avoid the protocols below 1024. */ final static int PORT_NUM = 2000; /** * True to only accept connections from the local machine. */ final static boolean LOCAL_ONLY = false; /** * Constructor SocketServer * Description: Creates a new Server for Sockets. * * @param socket, the client socket to run. */ SocketServer(Socket socket) { this.socket = socket; } /** * Method run * Description: A thread to send some data and read a response. * */ public void run() { try { /** * For exiting the server */ boolean isExit = false; /** * The in receives the data from the client */ InputStream in = socket.getInputStream(); /** * The out sends the data to the client */ OutputStream out = socket.getOutputStream(); System.out.println("Sending Some Data..."); out.write("Send Some Data\r\n".getBytes()); byte[] buffer = new byte[1024]; int read; while (((read = in.read(buffer)) >= 0) && !isExit) { String readString = new String(buffer); System.out.println("Read Data:" + new String(buffer)); /** * Reset the contents of the buffer */ for(int i = 0; i < 1024; i++){ buffer[i] = 0; } if(readString.equalsIgnoreCase("Exit")){ isExit = true; } System.out.println("Exiting Client Connection"); } } catch (IOException ex) { ex.printStackTrace(); } finally { try { socket.close(); } catch (IOException ignored) {} } } /** * Method main * * * @param args the standard arguments for a main driver. * * @throws IOException to propagate from the any IO exceptions for sockets. * */ public static void main(String[] args) throws IOException { ServerSocket server = null; System.out.println("Starting SocketServer...."); /** * If local, only receive connections from the local host */ if (LOCAL_ONLY) { InetAddress address = InetAddress.getLocalHost(); server = new ServerSocket(PORT_NUM, 10, address); } else { server = new ServerSocket(PORT_NUM); } System.out.println("SocketServer Listening...."); while (true) { System.out.println("Waiting for Connection...."); /** * Accept a new client */ Socket client = server.accept(); /** * Start the current class; */ SocketServer socketServer = new SocketServer(client); /** * Start the Thread */ socketServer.start(); } } }
Listing 21-2 shows a corresponding SocketClient example that creates the connection to the awaiting listener. It needs to know the port number and address of the listener for the connection. Listing 21-2: The SocketClient class: A socket client example
package com.richware.chap21; import java.io.*; import java.net.*; /** * Class SocketClient * Description: Demonstrates a client connection to a Socket Server. * * Copyright: Copyright (c) 2002 Wiley Publishing, Inc. * @author Rich Helton <rhelton@richware.com> * @version 1.0 * DISCLAIMER: Please refer to the disclaimer at the beginning of this book. */ public class SocketClient extends Thread { protected Socket socket; /** * Port number is set to 2000 to avoid the protocols below 1024. */ final static int PORT_NUM = 2000; /** True to only accept connections from the local machine. */ final static boolean LOCAL_ONLY = true; /** * Constructor SocketClient * Description: Creates a new Socket to communicate with the Server. * */ SocketClient() {} /** * Method main * * * @param args the standard arguments for a main driver. * * @throws IOException to propagate from the any IO exceptions for sockets. * */ public static void main(String[] args) throws IOException { Socket socket = null; System.out.println("Starting SocketClient...."); /** * If local, only receive connections from the local host */ if (LOCAL_ONLY) { /** * Communicate with the local server at port 2000. */ InetAddress address = InetAddress.getLocalHost(); socket = new Socket(address, PORT_NUM); } else { /** * Communicate with the server on myserver1 at port 2000. */ InetAddress address = InetAddress.getByName("myserver1.richware.com"); socket = new Socket(address, PORT_NUM); } /** * The in receives the data from the client */ InputStream in = socket.getInputStream(); OutputStream out = socket.getOutputStream(); byte[] buffer = new byte[1024]; int read; if ((read = in.read(buffer)) >= 0) { System.out.println("Socket Read:" + new String(buffer)); } /** * The out sends the data to the client */ System.out.println("Sending Data"); out.write("Received Data\r\n".getBytes()); /** * The out sends the data to the client */ System.out.println("Sending Exit Server"); out.write("EXIT".getBytes()); /** * Close the socket */ socket.close(); } }
The connections are in the Session Layer because they require a reference to each other to communicate. The client output looks like the following lines: >java com.richware.chap21.SocketClient Starting SocketClient.... Socket Read:Send Some Data Sending Data Sending Exit Server The matching server output looks like the following: >java com.richware.chap21.SocketServer Starting SocketServer.... SocketServer Listening.... Waiting for Connection.... Waiting for Connection.... Sending Some Data... Read Data:Received Data EXIT Exiting Client Connection The layers above the Session Layer are protocols that manipulate the data. If the connection is at port 80, the defined port for HTTP, there should be an HTTP service responsible for managing the information. The HTTP service should then look at the data and ensure that it meets the proper format.
After this point, the service protocol parses out and manipulates data according to the HTTP specification. I have now completed all the layers of the OSI model and taken a trip through some samples of wrappers that might encapsulate the various protocols and specifications. Many books have been written on this topic because there are many more specifications and protocols - (Token Ring, FDDI, ATM, Sonet, and ISDN are some examples) that encompass this area and could be addressed here. However, our discussion for all these protocols would follow the OSI model I have used so far: If supporting TCP/IP, the IP header remains the same, the TCP header remains the same, and the sockets and application protocols remain the same. The difference resides in the network card, the framing in the Data Link Layer, and the signaling of the carrier wave. If, instead of HTTP, I use FTP, and the port number and the data change, additional layers of connection may be required to move ports around for commands versus passing of data, but a connection of sockets for TCP and UDP still works in the same manner.
The different OSI layers communicate at the different peers; however, some routing is still involved to reach the destination of the LAN system. The router passes the packet into the organization's LAN and drops the packet, but the security behind it can be increased. Routing basicsAs described in the previous section, the router's responsibility is to examine the packet and check whether it should be passed to the organization's LAN. The router reads the IP address out of the IP packet and, if the IP address is for a machine registered on the LAN, the router sends the packet there. The router is responsible for the support of the lower three layers of the OSI model, as Figure 21-7 shows.  Figure 21-7: The routing OSI model The router maintains a table to know whether the registered machine exists on the LAN; in order to accomplish this task, the router must follow the Address Resolution Protocol (ARP) specified in RFC 826. ARP handles the translation of the 32-bit IP addresses, in the IP header, into the hardware address, in the network card. The hardware address is a 48-bit address that follows the network card. The Routing Information Protocol (RIP) is another protocol that the router uses. RIP gives routers the capability to periodically broadcast to the networks that they are aware of to find out their distance. The ping and traceroute protocols give insight to RIP because RIP is very similar to sending a ping, getting a return echo, and keeping track of the shortest distance to the networks. RIP is used for discovering dynamic addresses across a network that occasionally changes, such as machines configured with dynamic addresses when they register themselves to the domain. The network ping concept can be traced to a submarine ping: A submarine can send a high-pitched noise to find nearby ships by the echo of the signal. The network ping is part of the Internet Control Message Protocol (ICMP). The ICMP packet can be used instead of the TCP and UDP packet in the Transport Layer. Figure 21-8 shows the structure of ICMP packets.  Figure 21-8: ICMP packet The ICMP protocols have multiple types of services for querying information about a machine or network: 0 for ping reply, 3 for a destination unreachable, 5 for redirect, 8 for ping request, 9 for router advertisement, and 10 for router solicitation. Message Types 9 and 10 of ICMP are part of RFC 1256, which is the ICMP Router Discovery Message. This message is used for discovering the different static addresses across the network; machines with static addresses change with less frequency and require less work for router tables. Since static addresses don't change, they must be dedicated to a machine. This scheme gives little address re-use to other machines that could be using the address when the machine (associated with the static address) is down. A machine that has a static IP address is also more susceptible to attacks because, when it is alive , an attacker can find the same machine over and over again with the same address. Based on the type of service in ICMP, a code is returned: For example, for type 3, code 0 means that the network was unreachable and a code 7 means that the host is unknown. These packets change based on the type of the service. Figure 21-9 shows the ICMP packet with type and code.  Figure 21-9: The ICMP packet with type and code Listing 21-3 gives an example ping program run. Listing 21-3: Ping output
C:\>ping ftp-dom.earthlink.net Pinging ftp-dom.earthlink.net [207.217.111.93] with 32 bytes of data: Reply from 207.217.111.93: bytes=32 time=241ms TTL=247 Reply from 207.217.111.93: bytes=32 time=230ms TTL=247 Reply from 207.217.111.93: bytes=32 time=221ms TTL=247 Reply from 207.217.111.93: bytes=32 time=240ms TTL=247 Ping statistics for 207.217.111.93: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 221ms, Maximum = 241ms, Average = 233ms
The ping program uses an IP record route (RR) in the IP header. The RR can be seen from the next example of ping in Listing 21-4. What makes the use of this ping special is that it allows the RR to record 9, which was specified at the command; it represents the hops that it took to reach the destination and back again. In the preceding example, it went to the addresses 209.247.8.235, 209.247.8.242, 209.245.88.33, 207.217.1.125, 207.217.2.34, 207.217.111.5 before reaching the destination of 207.217.111.93, which is the host specified. Listing 21-4: Ping showing an IP record route
C:\>ping -r 9 ftp-dom.earthlink.net Pinging ftp-dom.earthlink.net [207.217.111.93] with 32 bytes of data: Reply from 207.217.111.93: bytes=32 time=231ms TTL=248 Route: 209.247.8.235 -> 209.247.8.242 -> 209.245.88.33 -> 207.217.1.125 -> 207.217.2.98 -> 207.217.111.5 -> 207.217.111.93 -> 207.217.2.62 -> 207.217.1.108 Reply from 207.217.111.93: bytes=32 time=230ms TTL=248 Route: 209.247.8.235 -> 209.247.8.242 -> 209.245.88.33 -> 207.217.1.125 -> 207.217.2.34 -> 207.217.111.5 -> 207.217.111.93 -> 207.217.2.126 -> 207.217.1.44 Reply from 207.217.111.93: bytes=32 time=221ms TTL=248 Route: 209.247.8.235 -> 209.247.8.242 -> 209.245.88.33 -> 207.217.1.125 -> 207.217.2.98 -> 207.217.111.5 -> 207.217.111.93 -> 207.217.2.30 -> 207.217.1.11 Reply from 207.217.111.93: bytes=32 time=220ms TTL=248 Route: 209.247.8.235 -> 209.247.8.242 -> 209.245.88.33 -> 207.217.1.125 -> 207.217.2.34 -> 207.217.111.5 -> 207.217.111.93 -> 207.217.2.30 -> 207.217.1.75 Ping statistics for 207.217.111.93: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 220ms, Maximum = 231ms, Average = 225ms
For all ICMP hosts, the support for the RR in the IP header is optional; however, it is supported by most router systems. Another issue with the support of RR is the size limitation in the IP header, which only allows 39 bytes for this option. Figure 21-10 shows the RR IP address header.  Figure 21-10: The RR IP address header Here is an example of how ICMP can be used to map routes: Traceroute (a similar program to ping) sends a UDP at a very high port, such as 30,000, that should not exist. This causes the destination host's UDP service protocol to generate an ICMP "port unreachable" error. Then three more UDP messages are sent with a Time To Live (TTL) field set to one. This causes the first router on the path to return an ICMP message reporting that the TTL has expired. Next, three more UDP messages are sent with the TTL set to 2, which causes the second router to return that the TTL has expired . This process continues, and the routers are mapped while collecting the return addresses of the routers that are reporting expiration. Now that you understand how addresses can be checked, the next thing to understand is how to maintain a routing table. The routing table is maintained by checking the default entries of the host or router for the host address, its matching network address, and its default entry that is its gateway. The service protocol utility netstat -rn supports this functionality on most platforms. Performing the netstat -rn command on a Windows 2000 machine connecting directly to a direct connection yields the results in Listing 21-5; gateways usually end with the address of 0, but not always. Listing 21-5: netstat -rn run on a Windows 2000 machine
C:\>netstat -rn Route Table =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x1000003 ...00 00 86 56 f5 97 ...... FE575 Ethernet Adapter 0x2000004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 64.156.32.172 64.156.32.172 1 64.156.32.172 255.255.255.255 127.0.0.1 127.0.0.1 1 64.255.255.255 255.255.255.255 64.156.32.172 64.156.32.172 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 209.247.23.216 255.255.255.255 64.156.32.172 64.156.32.172 1 224.0.0.0 224.0.0.0 64.156.32.172 64.156.32.172 1 255.255.255.255 255.255.255.255 64.156.32.172 1000003 1 Default Gateway: 64.156.32.172 =========================================================================== Persistent Routes: None C:\>
To initialize the routing table, a route command is used. These are normally routes to hosts or networks that are not directly connected, usually an address that is currently not in the local segment and requires more than one hop. An example of adding to the routing table on the Windows 2000 machine is shown in Listing 21-6. Listing 21-6: Adding to the routing table
> route PRINT > route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 destination^ ^mask ^gateway metric^ ^ Interface^ If IF is not given, it tries to find the best interface for a given gateway. > route PRINT > route PRINT 157* .... Only prints those matching 157* > route DELETE 157.0.0.0 > route PRINT
To get the information to fill the routing table through RIP is a little more complicated. RIP's version 1 has had a lot of security issues because the client usually accepts any data that is sent. The packages have been able to send not just routes but logging information about hosts. Information about the first version can be found in RFC 1058. To avoid these security issues, the second version uses MD5 authentication of passwords for authenticating the requester; information on the second version can be found in RFC 1388. RIP works by computing a distance vector for the hops. Each hop has a cost, and the total metric distance for a path is the sum of the hops cost. Therefore, RIP knows the distance by adding the cost of each hop and summing the total. RIP is a message wrapped by the IP/UDP packet. RIP can keep track of 25 routes because the packet size is 20 bytes, and it must maintain the packet less than 512 bytes. RIP operates on the router port, which is port 520. The router knows the cost to its neighbor on the path toward the destination address; that router knows the cost to the next neighbor and so on until all the metrics are calculated. The router broadcasts its routing table, or a part of it, to its neighbor every 30 seconds to update its neighbor's routing table. If something special happens, such as a metric for a route changes in the table, it might trigger a new update of the table immediately to tell the neighboring router of the change. These notifications of changes in metrics give the neighbor the capability to know the cost of its closest neighboring router. In 1998, a protocol to replace RIP was started by the Internet Engineering Task Force called the Open Shortest Path First (OSPF) Interior Gateway Protocol. OSPF is public. The OSPF standard describes networks (which are actually subnets) and areas (which are sets of networks). OSPF is designed to scale well because routers only need information about the area that the router serves. A router keeps information on the area (called a database ), and when a change happens the information is propagated through the area. Every router in an area keeps an identical database of the network. When a node is initiated, it gets the information from its network and after that only changes must be propagated. OSPF supports traffic splitting across multiple paths, routing based on type of service, and authentication for routing update messages.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
