Commonly Used Commands
| < Day Day Up > |
| This section looks at many commands that you can issue from the command line to view and set networking-related parameters, including ping, netstat, route, ifconfig, rpcinfo, arp, and iptables. pingping is one of the most commonly used networking commands. ping stands for Packet InterNet Groper. This command determines whether a connection exists between two networking components. ping is a simple command that sends an ICMP echo packet to the host you specify once per second. You'll find that the options to ping differ on Linux and UNIX. The following example shows issuing ping with a count (-c) of 5, and interval of 5, and a packet size of 1024: # ping 192.168.1.1 -c 5 -i 5 -s 1024 PING 192.168.1.1 (192.168.1.1) from 192.168.1.102 : 1024(1052) bytes of data. 1032 bytes from 192.168.1.1: icmp_seq=1 ttl=150 time=2.79 ms 1032 bytes from 192.168.1.1: icmp_seq=2 ttl=150 time=2.80 ms 1032 bytes from 192.168.1.1: icmp_seq=3 ttl=150 time=2.79 ms 1032 bytes from 192.168.1.1: icmp_seq=4 ttl=150 time=2.79 ms 1032 bytes from 192.168.1.1: icmp_seq=5 ttl=150 time=2.77 ms --- 192.168.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 20036ms rtt min/avg/max/mdev = 2.775/2.792/2.804/0.048 ms # Many useful statistics are produced as a result of ping. Notice that it took around 2.75 ms for the 1024 packet size. This is substantially less if you use the default 64 bit packet size: # ping 192.168.1.1 -c 5 -i 5 PING 192.168.1.1 (192.168.1.1) from 192.168.1.102 : 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=150 time=0.655 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=150 time=0.626 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=150 time=0.608 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=150 time=0.626 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=150 time=0.659 ms --- 192.168.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 20007ms rtt min/avg/max/mdev = 0.608/0.634/0.659/0.037 ms [root@linuxdev etc]# The default packet size results in a much shorter transfer time. In the event that you're an experienced UNIX user, I've included the following examples from some UNIX variants. You can adjust the packet size and number of iterations on most UNIX variants as in the HP-UX example shown here, which specifies a packet size of 4096 and interval of 5: # ping l2 4096 5 PING l2: 4096 byte packets 4096 bytes from 10.1.1.12: icmp_seq=0. time=2. ms 4096 bytes from 10.1.1.12: icmp_seq=1. time=2. ms 4096 bytes from 10.1.1.12: icmp_seq=2. time=2. ms 4096 bytes from 10.1.1.12: icmp_seq=3. time=2. ms 4096 bytes from 10.1.1.12: icmp_seq=4. time=2. ms ----l2 PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 2/2/2 # netstatFrom the description of the subnet mask in the previous chapter, you can see that routing from one host to another can be configured in a variety of ways. The path that information takes in getting from one host to another depends on routing. You can obtain information related to routing with the netstat command, or the route command. The -r option to netstat shows the routing tables, which you usually want to know, and the -n option can be used to print network addresses as numbers rather than as names. In the following examples, netstat is issued with the -r option (this is used when describing the netstat output), and the -rn options, and the -rnv options, so you can compare the outputs: # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 * 255.255.255.0 U 40 0 0 eth0 127.0.0.0 * 255.0.0.0 U 40 0 0 lo default 192.168.1.1 0.0.0.0 UG 40 0 0 eth0 # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 192.168.1.1 0.0.0.0 UG 40 0 0 eth0 # These two outputs are very similar. The first and second outputs show that our system, 192.168.1.102, has one network interface card. The first line shows this card as eth0. The second is the loopback interface called lo0. The last line is for the default route. This entry says to send packets to 192.168.1.1 if you don't know another route. I also use netstat to obtain networking statistics on Linux system interfaces. The following example shows a lot of statistical information for eth0: # netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 7801580 0 0 53 5249311 0 0 0 BMRU lo 16436 0 616 0 0 0 616 0 0 0 LRU # You can see from this output the receives and transmits that are OK are huge numbers (RX-OK and TX-OK respectively). There are no errors reported in this output. If you're an experienced UNIX system administrator, you can see that this output is substantially different than what you will see on UNIX systems. Yet another use of netstat is to show the state of network sockets. netstat -a produces a list of protocols, queues, local and remote addresses, and protocol states. All this information is useful for showing active communications, as shown in the following Linux example: # netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:1024 *:* LISTEN tcp 0 0 localhost.localdom:1025 *:* LISTEN tcp 0 0 *:swat *:* LISTEN tcp 0 0 *:netbios-ssn *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:x11 *:* LISTEN tcp 0 0 *:10000 *:* LISTEN tcp 0 0 *:ftp *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:telnet *:* LISTEN tcp 0 0 linuxdev:1180 64.12.29.100:5190 ESTABLISHED tcp 0 138 linuxdev:telnet F4457MXP:4846 ESTABLISHED udp 0 0 *:1024 *:* udp 0 0 linuxdev:netbios-ns *:* udp 0 0 *:netbios-ns *:* udp 0 0 linuxdev:netbios-dgm *:* udp 0 0 *:netbios-dgm *:* udp 0 0 *:10000 *:* udp 0 0 *:sunrpc *:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 2053 /tmp/orbit-root/orb-1523613880190 4627091 unix 2 [ ACC ] STREAM LISTENING 2063 /tmp/orbit-root/orb-7610255132067 156537 unix 2 [ ACC ] STREAM LISTENING 2075 /tmp/orbit-root/orb-6806623012888 86487 unix 11 [ ] DGRAM 947 /dev/log unix 2 [ ACC ] STREAM LISTENING 2100 /tmp/orbit-root/orb-1053351818121 2229376 unix 2 [ ACC ] STREAM LISTENING 2136 /tmp/orbit-root/orb-4011262787838 1447 unix 2 [ ACC ] STREAM LISTENING 2166 /tmp/orbit-root/orb-3523674863949 39250 unix 2 [ ACC ] STREAM LISTENING 2305 /tmp/orbit-root/orb-1746122099132 2113508 unix 2 [ ACC ] STREAM LISTENING 1495 /dev/gpmctl unix 2 [ ACC ] STREAM LISTENING 2320 /tmp/orbit-root/orb-1566553237209 6623112 unix 2 [ ACC ] STREAM LISTENING 2351 /tmp/orbit-root/orb-6282964742254 79129 unix 2 [ ACC ] STREAM LISTENING 2386 /tmp/.fam_socket unix 2 [ ACC ] STREAM LISTENING 1852 /tmp/.ICE-unix/1037 unix 2 [ ACC ] STREAM LISTENING 1607 /tmp/.font-unix/fs7100 unix 2 [ ACC ] STREAM LISTENING 1714 /tmp/.X11-unix/X0 unix 2 [ ACC ] STREAM LISTENING 1962 /tmp/.sawfish-root/linuxdev:0.0 unix 2 [ ACC ] STREAM LISTENING 3276 /tmp/gaim_root.1505 unix 3 [ ] STREAM CONNECTED 14884 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 14883 unix 3 [ ] STREAM CONNECTED 3282 /tmp/gaim_root.1505 unix 3 [ ] STREAM CONNECTED 3278 unix 3 [ ] STREAM CONNECTED 3274 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 3273 unix 3 [ ] STREAM CONNECTED 3270 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 3269 unix 3 [ ] STREAM CONNECTED 2392 /tmp/.famDZd9xZ unix 3 [ ] STREAM CONNECTED 2391 unix 3 [ ] STREAM CONNECTED 2395 /tmp/orbit-root/orb-6282964742254 79129 unix 3 [ ] STREAM CONNECTED 2384 unix 3 [ ] STREAM CONNECTED 2369 /tmp/orbit-root/orb-7610255132067 156537 unix 3 [ ] STREAM CONNECTED 2368 unix 3 [ ] STREAM CONNECTED 2364 /tmp/orbit-root/orb-6806623012888 86487 unix 3 [ ] STREAM CONNECTED 2363 unix 3 [ ] STREAM CONNECTED 2371 /tmp/orbit-root/orb-1566553237209 6623112 unix 3 [ ] STREAM CONNECTED 2358 unix 3 [ ] STREAM CONNECTED 2357 /tmp/orbit-root/orb-7610255132067 156537 unix 3 [ ] STREAM CONNECTED 2356 unix 3 [ ] STREAM CONNECTED 2360 /tmp/orbit-root/orb-1746122099132 2113508 unix 3 [ ] STREAM CONNECTED 2353 unix 3 [ ] STREAM CONNECTED 2349 /tmp/orbit-root/orb-6806623012888 86487 unix 3 [ ] STREAM CONNECTED 2348 unix 3 [ ] STREAM CONNECTED 2343 /tmp/orbit-root/orb-1053351818121 2229376 unix 3 [ ] STREAM CONNECTED 2342 unix 3 [ ] STREAM CONNECTED 2339 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2338 unix 3 [ ] STREAM CONNECTED 2335 /tmp/orbit-root/orb-1053351818121 2229376 unix 3 [ ] STREAM CONNECTED 2333 unix 3 [ ] STREAM CONNECTED 2330 /tmp/orbit-root/orb-7610255132067 156537 unix 3 [ ] STREAM CONNECTED 2329 unix 3 [ ] STREAM CONNECTED 2325 /tmp/orbit-root/orb-6806623012888 86487 unix 3 [ ] STREAM CONNECTED 2324 unix 3 [ ] STREAM CONNECTED 2317 /tmp/orbit-root/orb-3523674863949 39250 unix 3 [ ] STREAM CONNECTED 2315 unix 3 [ ] STREAM CONNECTED 2312 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2311 unix 3 [ ] STREAM CONNECTED 2302 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2301 unix 3 [ ] STREAM CONNECTED 2219 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2218 unix 3 [ ] STREAM CONNECTED 2216 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2215 unix 3 [ ] STREAM CONNECTED 2205 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2204 unix 3 [ ] STREAM CONNECTED 2158 /tmp/orbit-root/orb-4011262787838 1447 unix 3 [ ] STREAM CONNECTED 2153 unix 2 [ ] DGRAM 2135 unix 3 [ ] STREAM CONNECTED 2130 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2129 unix 3 [ ] STREAM CONNECTED 2128 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2126 unix 3 [ ] STREAM CONNECTED 2127 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2125 unix 3 [ ] STREAM CONNECTED 2097 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2096 unix 3 [ ] STREAM CONNECTED 2092 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2091 unix 3 [ ] STREAM CONNECTED 2088 /tmp/orbit-root/orb-6806623012888 86487 unix 3 [ ] STREAM CONNECTED 2087 unix 3 [ ] STREAM CONNECTED 2079 /tmp/orbit-root/orb-6806623012888 86487 unix 3 [ ] STREAM CONNECTED 2077 unix 3 [ ] STREAM CONNECTED 2073 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2072 unix 2 [ ] DGRAM 2071 unix 3 [ ] STREAM CONNECTED 2061 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2060 unix 3 [ ] STREAM CONNECTED 2057 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2056 unix 3 [ ] STREAM CONNECTED 2052 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2051 unix 3 [ ] STREAM CONNECTED 2048 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2047 unix 3 [ ] STREAM CONNECTED 2039 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 2038 unix 3 [ ] STREAM CONNECTED 1957 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 1956 unix 3 [ ] STREAM CONNECTED 1869 /tmp/.ICE-unix/1037 unix 3 [ ] STREAM CONNECTED 1868 unix 3 [ ] STREAM CONNECTED 1867 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 1866 unix 3 [ ] STREAM CONNECTED 1857 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 1856 unix 3 [ ] STREAM CONNECTED 1724 /tmp/.font-unix/fs7100 unix 3 [ ] STREAM CONNECTED 1723 unix 4 [ ] STREAM CONNECTED 1726 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 1717 unix 2 [ ] DGRAM 1689 unix 2 [ ] DGRAM 1610 unix 2 [ ] DGRAM 1518 unix 2 [ ] DGRAM 1451 unix 2 [ ] DGRAM 1155 unix 2 [ ] DGRAM 1011 unix 2 [ ] DGRAM 959 # Some of the connections are ESTABLISHED (such as the linuxdev:telnet connection early in the listing). This is the connection you have initiated to this system. You are connected from F4457MXP with a telnet session open to the system linuxdev. Most of the remaining tcp protocol entries are listening, such as swat. This means that they are listening for incoming connections, as indicated by the LISTEN. They have a wild card in the Foreign Address field, which will contain the address when a connection has been established. Your connection is one of the few connections that has been made, as indicated by the ESTABLISHED. All the send and receive queues, shown as Recv-Q and Send-Q, are empty as indicated by 0. The UNIX domain sockets at the end of the output are stream and datagram connections for a variety of services such as X11. This output gives you an appreciation of the immense amount of activity taking place from a networking perspective on your Linux system. Networking and connectivity have been among the most advanced aspects of Linux since its inception. routeThe information displayed with netstat -a includes the routing tables for your system. Some are automatically created with the ifconfig command when your system is booted or when the network interface is initialized. Routes to networks and hosts that are not directly connected to your system are entered with the route command. Routing is required if your system is connected to a network with multiple subnets. Most of the time, your Linux system is aware of three routes. The first is the loopback route, which points to the loopback device which was lo in the earlier netstat -r example. The next route is to the same LAN to which the system is connected, which means that packets are sent directly to a system. The third is the default route, which is the destination for packets not on the same LAN as the system. If you type the route command on your Linux system with no options, you'll see an output similar to netstat -r, as shown in the following example: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 # From this output, you see the Destination, which is the network to which you want to route, and the Gateway for getting there. These include a route for 192.168.1.0 which is the LAN to which the system is connected, the loopback, and then the default which is the router that takes care of packets sent to a different LAN. If the default route was not set to the desired address, you could add it with the following command and example: # route add default gw address # route add default gw 15.32.160.1 You could also delete an erroneous default gateway using the same command with delete in place of add. The netmask in this output is shown as the genmask. Note also that there are Flags in the route output that also appeared in some of the netstat outputs. The following list summarizes some of the most often seen Flags values including the two that appear in our output:
A Metric that defines the cost of the route in "hops" is not used by the Linux kernel, but is used by advanced routing protocols. The Ref is the number of references to this route also not used by the Linux kernel. Use is the number of successful route cache lookups that can be seen with the -F option. In addition to viewing information with route, you could modify the routing setup with this command. If the default route were not set to the address shown in the previous route output, you could issue the following command: # route add -net default gw 192.168.1.1 dev eth0 First is the route command. Second, specify that you want to add a route; the other option is to del a route. Third, specify a -net for network or -host for router. Fourth, specify the destination; in this case, the default. Fifth, specify that routes will go through the gateway of 192.168.1.1. Finally, specify a dev of eth0. Before issuing route with the add option, you can first use the delete option to remove the existing default route, which is not working. ifconfigOn Linux systems, ifconfig configures the kernel-resident network interfaces. It is used at boot time to set up interfaces. Other than that, it is usually only needed when debugging or when system tuning is needed. It is used for debugging because it can be very informative. The following is an ifconfig output with no options: # ifconfig eth0 Link encap:Ethernet HWaddr 00:10:4B:64:D4:3E inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7820857 errors:0 dropped:0 overruns:53 frame:0 TX packets:5250880 errors:0 dropped:0 overruns:0 carrier:3 collisions:572 txqueuelen:100 RX bytes:2097256998 (2000.1 Mb) TX bytes:490813036 (468.0 Mb) Interrupt:9 Base address:0xfc80 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:622 errors:0 dropped:0 overruns:0 frame:0 TX packets:622 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31930 (31.1 Kb) TX bytes:31930 (31.1 Kb) # With no options, ifconfig produces a detailed output for all active interfaces. ifconfig can also be used to set up network interfaces. Many excellent tools, such as neat, webmin, and netconf, are used to configure network interfaces as well. You could set the IP address of a network interface with ifconfig, as shown in the following example: # /etc/ifconfig eth0 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255 In this example, you set the IP address, netmask, and broadcast address of eth0. Because this is a Class C address, you did not have to specify the netmask and broadcast because the values specified are the calculated values. For other classes, you would have to specify these values. The network address you have falls into classes such as A, B, or C, as covered in the previous chapter. You want to be sure that you know the class of your network before you start configuring your LAN interface. For a Class B network, the netmask is defined as ffff0000 (typical for a Class B address), as opposed to ffffff00, which is typical for a Class C network. The netmask determines how much of the address to reserve for subdividing the network into smaller networks. rpcinfoAs a user, you may have a need to NFS mount a directory on another system or perform some other function that you haven't before used on your system. You can determine whether various pieces of functionality have been enabled by evaluating the daemons running on your system. rpcinfo allows you to generate a Remote Procedure Call (RPC) on a system, including your local system, by issuing the command rpc -p system_name. The following example shows issuing rpcinfo -p on the local system: # rpcinfo -p program vers proto port service 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 777 status 100024 1 tcp 779 status 100021 1 tcp 783 nlockmgr 100021 1 udp 1035 nlockmgr 100021 3 tcp 787 nlockmgr 100021 3 udp 1036 nlockmgr 100020 1 udp 1037 llockmgr 100020 1 tcp 792 llockmgr 100021 2 tcp 795 nlockmgr 100068 2 udp 1040 cmsd 100068 3 udp 1040 cmsd 100068 4 udp 1040 cmsd 100068 5 udp 1040 cmsd 100083 1 tcp 1036 ttdbserver 100005 1 udp 976 mountd 100005 1 tcp 978 mountd 100003 2 udp 2049 nfs 150001 1 udp 1003 pcnfsd 150001 2 udp 1003 pcnfsd 150001 1 tcp 1006 pcnfsd 150001 2 tcp 1006 pcnfsd # As you can see many daemons are running on the local system. mountd is running, which indicates that a server could NFS mount file systems on this computer. There is other setup required for the mount to take place, but at least the daemon is running to support this functionality. In addition, pcnfsd is running, which means you have support for Windows-based NFS access. arp (Address Resolution Protocol)The mechanism used to maintain a list of IP addresses and their corresponding MAC addresses is the ARP cache. The mapped addresses are only held in the cache for minutes, so if you want to see what addresses have been mapped recently, you can use the arp command. The following command produces information on eth0 on the system on which the examples will take place: # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:30:6E:06:79:7C inet addr:192.6.175.244 Bcast:192.6.175.255 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:233 errors:0 dropped:0 overruns:0 frame:0 TX packets:27 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:17807 (17.3 Kb) TX bytes:2268 (2.2 Kb) Interrupt:9 Base address:0x8000 The address of the networking card is 192.6.175.244. Now populate the arp cache. ping the broadcast address of 192.6.175.255 for this interface, which will make entries in the arp cache. Note that I have shortened ping output: # ping -b 192.6.175.255 WARNING: pinging broadcast address PING 192.6.175.255 (192.6.175.255) from 192.6.175.244 : 56(84) bytes of data. 64 bytes from 192.6.175.244: icmp_seq=1 ttl=64 time=0.102 ms 64 bytes from 192.6.175.160: icmp_seq=1 ttl=255 time=0.257 ms (DUP!) 64 bytes from 192.6.175.192: icmp_seq=1 ttl=255 time=0.406 ms (DUP!) 64 bytes from 192.6.175.185: icmp_seq=1 ttl=255 time=0.417 ms (DUP!) 64 bytes from 192.6.175.199: icmp_seq=1 ttl=255 time=0.432 ms (DUP!) 64 bytes from 192.6.175.236: icmp_seq=1 ttl=255 time=0.458 ms (DUP!) 64 bytes from 192.6.175.206: icmp_seq=1 ttl=255 time=0.469 ms (DUP!) 64 bytes from 192.6.175.229: icmp_seq=1 ttl=255 time=0.504 ms (DUP!) 64 bytes from 192.6.175.171: icmp_seq=1 ttl=255 time=0.516 ms (DUP!) 64 bytes from 192.6.175.178: icmp_seq=1 ttl=255 time=0.553 ms (DUP!) 64 bytes from 192.6.175.215: icmp_seq=1 ttl=255 time=0.616 ms (DUP!) 64 bytes from 192.6.175.164: icmp_seq=1 ttl=255 time=0.654 ms (DUP!) 64 bytes from 192.6.175.138: icmp_seq=1 ttl=255 time=0.708 ms (DUP!) 64 bytes from 192.6.175.140: icmp_seq=1 ttl=255 time=0.794 ms (DUP!) 64 bytes from 192.6.175.140: icmp_seq=1 ttl=255 time=0.805 ms (DUP!) 64 bytes from 192.6.175.142: icmp_seq=1 ttl=255 time=1.56 ms (DUP!) 64 bytes from 192.6.175.133: icmp_seq=1 ttl=255 time=2.63 ms (DUP!) 64 bytes from 192.6.175.134: icmp_seq=1 ttl=255 time=2.64 ms (DUP!) 64 bytes from 192.6.175.165: icmp_seq=1 ttl=64 time=4.36 ms (DUP!) 64 bytes from 192.6.175.161: icmp_seq=1 ttl=64 time=4.83 ms (DUP!) 64 bytes from 192.6.175.254: icmp_seq=1 ttl=64 time=6.89 ms (DUP!) 64 bytes from 192.6.175.252: icmp_seq=1 ttl=64 time=150 ms (DUP!) 64 bytes from 192.6.175.244: icmp_seq=2 ttl=64 time=0.070 ms 64 bytes from 192.6.175.206: icmp_seq=2 ttl=255 time=0.145 ms (DUP!) 64 bytes from 192.6.175.192: icmp_seq=2 ttl=255 time=0.153 ms (DUP!) 64 bytes from 192.6.175.254: icmp_seq=2 ttl=64 time=1.76 ms (DUP!) 64 bytes from 192.6.175.161: icmp_seq=2 ttl=64 time=1.79 ms (DUP!) 64 bytes from 192.6.175.244: icmp_seq=3 ttl=64 time=0.072 ms 64 bytes from 192.6.175.192: icmp_seq=3 ttl=255 time=0.145 ms (DUP!) 64 bytes from 192.6.175.199: icmp_seq=3 ttl=255 time=0.153 ms (DUP!) 64 bytes from 192.6.175.236: icmp_seq=3 ttl=255 time=0.163 ms (DUP!) 64 bytes from 192.6.175.185: icmp_seq=3 ttl=255 time=0.173 ms (DUP!) 64 bytes from 192.6.175.206: icmp_seq=3 ttl=255 time=0.183 ms (DUP!) 64 bytes from 192.6.175.229: icmp_seq=3 ttl=255 time=0.192 ms (DUP!) 64 bytes from 192.6.175.178: icmp_seq=3 ttl=255 time=0.202 ms (DUP!) 64 bytes from 192.6.175.215: icmp_seq=3 ttl=255 time=0.212 ms (DUP!) 64 bytes from 192.6.175.140: icmp_seq=3 ttl=255 time=0.222 ms (DUP!) 64 bytes from 192.6.175.171: icmp_seq=3 ttl=255 time=0.232 ms (DUP!) 64 bytes from 192.6.175.160: icmp_seq=3 ttl=255 time=0.241 ms (DUP!) 64 bytes from 192.6.175.164: icmp_seq=3 ttl=255 time=0.251 ms (DUP!) 64 bytes from 192.6.175.138: icmp_seq=3 ttl=255 time=0.261 ms (DUP!) 64 bytes from 192.6.175.140: icmp_seq=3 ttl=255 time=0.271 ms (DUP!) 64 bytes from 192.6.175.142: icmp_seq=3 ttl=255 time=0.361 ms (DUP!) 64 bytes from 192.6.175.133: icmp_seq=3 ttl=255 time=0.831 ms (DUP!) 64 bytes from 192.6.175.134: icmp_seq=3 ttl=255 time=0.848 ms (DUP!) 64 bytes from 192.6.175.254: icmp_seq=3 ttl=64 time=1.17 ms (DUP!) 64 bytes from 192.6.175.252: icmp_seq=3 ttl=64 time=1.32 ms (DUP!) 64 bytes from 192.6.175.161: icmp_seq=3 ttl=64 time=1.76 ms (DUP!) --- 192.6.175.255 ping statistics --- 4 packets transmitted, 4 received, +84 duplicates, 0% loss, time 3005ms rtt min/avg/max/mdev = 0.070/2.446/150.539/15.913 ms You established a connection to many devices on the 192.6.175 subnet and should have entries for these systems in the arp cache. We'll issue the arp -a command in the following example, which shows the systems from the ping included in the cache: # arp -a ? (192.6.175.178) at 00:30:6E:1C:22:5E [ether] on eth0 ? (192.6.175.252) at 00:30:C1:52:F1:80 [ether] on eth0 ? (192.6.175.254) at 00:30:C1:79:4C:8C [ether] on eth0 ? (192.6.175.185) at 00:30:6E:2C:15:8F [ether] on eth0 ? (192.6.175.215) at 00:30:6E:38:32:B9 [ether] on eth0 ? (192.6.175.206) at 00:30:6E:2C:32:98 [ether] on eth0 ? (192.6.175.164) at 00:30:6E:0A:30:33 [ether] on eth0 ? (192.6.175.236) at 00:30:6E:38:72:2A [ether] on eth0 ? (192.6.175.129) at 00:E0:52:92:EC:56 [ether] on eth0 ? (192.6.175.171) at 00:30:6E:13:96:FC [ether] on eth0 ? (192.6.175.199) at 00:30:6E:2C:12:0C [ether] on eth0 ? (192.6.175.140) at 00:01:02:47:EB:4B [ether] on eth0 ? (192.6.175.138) at 00:10:83:B9:80:AA [ether] on eth0 ? (192.6.175.192) at 00:30:6E:2C:62:AD [ether] on eth0 ? (192.6.175.229) at 00:30:6E:38:72:64 [ether] on eth0 Current arp entries are displayed with the -a command. If an entry was missing that you want to have in the cache, you can create it with the -s option. iptablesiptables is used at the command line to implement packet filtering. This is accomplished by inserting and deleting rules from the kernel's packet filtering section. iptables is a newer method of packet filtering that is considered superior to the method it replaced, called ipchains. ipchains was available in kernel release 2.2 and iptables became available in 2.4 that was used as the basis for the examples in this book. ipchains is still available and, as a side note, the following URL contains an excellent "how to" document for working with ipchains: http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html An excellent potables "how to" document is: http://www.linxguruz.org/iptables/howto Packets are the basis of network traffic on a Linux system. The beginning of a packet is the header and the data of the packet is in the body. potables is a packet filter which means it determines whether your Linux system will ACCEPT (let the packet through,) DROP (discard the packet,) RETURN (stop traversing this chain and resume at the next rule in the calling chain,) or QUEUE (pass the packet to user space.) You may want to control packets coming to and from your Linux system for a variety of reasons, most of which are related to security. For example, you may not want those without accounts on your system to be able to establish a telnet connection to your system. It may be that your system may be used for a specific function and you don't want anyone from an outside network to connect to your system. This is not a security section and it only provides an introduction to iptables. If you are interested in security, you may want to read a document dedicated to network security. If you believe you are vulnerable to attack, you may want to implement more extensive security measures than what's covered here. This section covers only the basics of iptables. The changes you make using iptables are not permanent because they're stored in the currently running kernel. If you want these changes made permanent, the iptables commands you issue can be included in a script and run at the time of system boot to be reinitiated. Be sure to make the script executable by root and run it. Two commands help with saving and restoring iptables, called iptables-save and iptables-restore, that also help with re-running iptables commands. With iptables, you are inserting and deleting rules that govern packet filtering in the kernel's packet filtering section. When a packet is received it is compared to a checklist of rules and appropriate action is taken with the packet. This list of rules, called a chain, are compared to the packet header and if there is a match between the rule and the packet, action is taken based on the rule. There are three core chain types: INPUT, FORWARD, and OUTPUT. A packet is evaluated based on it's type. The DROP, ACCEPT, QUEUE, or RETURN action is taken relative to which of the three types of chain is being used. Figure 8-1 shows the relationship between the three types of chains. Figure 8-1. iptables Processing
This is a widely used diagram that you'll see in almost any document that describes iptables. Look at a couple of simple examples to see how iptables is used. To DROP ftp for everyone, we would issue the following command: #iptables -A INPUT -p tcp --destination-port 21 -j DROP -i eth0 # iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:ftp Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # Any attempts to connect to port 21 will now DROP as indicated by the output of the iptables --list command. The iptables command appends a new rule to the input chain (with -A), specifies a protocol of tcp(with -p), specifies a destination port of 21, which corresponds to ftp (with --destination-port 21), specifies a rule of DROP (with -j), and specifies an interface of eth0 (with -i). Attempts to initiate an ftp connection to eth0 will now be dropped. FTP requests coming from another interface such as eth1 are not dropped. Remove this rule with the following command: # iptables -D INPUT -p tcp --destination-port 21 -j DROP -i eth0 # iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Again, the -D has removed the ftp restriction on port 21, so you could now initiate an ftp session with port 21 on eth0. Keep in mind that what we have done with the first command was to DROP any attempt to use port 21 which corresponds to ftp. As you can see in the following output, both ftp and wu-ftp are configured to run: # chkconfig --list | grep ftp ftp: on wu-ftpd: on # If you don't know the port numbers for your internet services, you can view the /etc/services file. It contains mappings between internet services and their assigned port numbers. The following shows the first 30 or so lines of /etc/services on the system used for the iptables examples: # /etc/services: # $Id: services,v 1.31 2002/04/03 16:53:20 notting Exp $ # # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, most entries here have two entries # even if the protocol doesn't support UDP operations. # Updated from RFC 1700, ``Assigned Numbers'' (October 1994). Not all ports # are included, only the more common ones. # # The latest IANA port assignments can be gotten from # http://www.iana.org/assignments/port-numbers # The Well Known Ports are those from 0 through 1023. # The Registered Ports are those from 1024 through 49151 # The Dynamic and/or Private Ports are those from 49152 through 65535 # # Each line describes one service, and is of the form: # # service-name port/protocol [aliases ...] [# comment] tcpmux 1/tcp # TCP port service multiplexer tcpmux 1/udp # TCP port service multiplexer rje 5/tcp # Remote Job Entry rje 5/udp # Remote Job Entry echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users systat 11/udp users daytime 13/tcp daytime 13/udp qotd 17/tcp quote qotd 17/udp quote msp 18/tcp # message send protocol msp 18/udp # message send protocol chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp-data 20/udp # 21 is registered to ftp, but also used by fsp ftp 21/tcp ftp 21/udp fsp fspd ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp # SSH Remote Login Protocol telnet 23/tcp telnet 23/udp . . . This is a long file so I included only the beginning of it. You can see port 23 is defined for telnet. You could disable the ftp and wu-ftp services using one of the procedures in the service, xinetd, and chkconfig section of this chapter. What you have done with iptables is not allow access to the port, which is different than disabling the service. You could allow access to the port in a less restrictive manner by specifying a group of IP addresses that will be restricted, using the full name of system(s) to be restricted, or specifying a specific IP address to be restricted with iptables. There are many options in iptables for controlling access to ports. You could restrict access to many other commonly used ports, such as finger, telnet, X Windows, and any others that are not important to the operation of your system. The more services you enable, the more ports you'll have open. An NFS example in this chapter made you notice that several ports were open. Because it opens ports and shares data with the network, NFS is not without some security risks. The following example shows a partial output of the nmap command: # nmap -sT -O localhost Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Insufficient responses for TCP sequencing (0), OS detection may be less accurate Insufficient responses for TCP sequencing (3), OS detection may be less accurate Interesting ports on localhost.localdomain (127.0.0.1): (The 1592 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 111/tcp open sunrpc 989/tcp open ftps-data 1024/tcp open kdm 1031/tcp open iad2 1032/tcp open iad36000/tcp open X11 . . . You can see from this output that several ports are now open, including the telnet session used to obtain these examples from the system and several ports related to the NFS work. You used the -sT option, which is the most basic form of TCP scanning. You also used -O, which guesses the operating system of the machine. The following example is the output of the same command from the NFS client in the example: # nmap -sT -O localhost Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1590 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 111/tcp open sunrpc 139/tcp open netbios-ssn 901/tcp open samba-swat 1024/tcp open kdm 1025/tcp open NFS-or-IIS 6000/tcp open X11 10000/tcp open snet-sensor-mgmt Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.5.25 or Gen- too 1.2 Linux 2.4.19 rc 1-rc7) Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds You have new mail in /var/spool/mail/root This system has additional ports open such as 901, which is for the swat tool used to configure samba. No unknown ports are in these two outputs, so we at least know that the ports are used for known services (which are defined in /etc/services.) To find out more about the sunrpc service listings, we could use the following two commands: You could easily include the iptables commands in a file and run it as a shell program. The iptables commands you issue modify the running kernel and must be re-run after a reboot. The iptables-save and iptables-restore allow you to save and restore iptables information to STDOUT and from STDIN respectively. This chapter only scratched the surface of iptables of the extensive capability of iptables in this section, so I'd recommend the "how to" guides listed earlier to get a detailed understanding of iptables and ipchains. service, xinetd, and chkconfigA couple of miscellaneous startup-related programs and files related to enabling and disabling network services are xinetd and service. For more information about ports and services in relation to networks, see "Networking Background." nslookup and dignslookup is used to resolve a hostname into an IP address. You issue nslookup hostname and nslookup will access either the /etc/resolv.conf file or /etc/hosts to resolve the host name. The following example shows a system using /etc/hosts to produce the IP address of system l2: # nslookup mxf4458nt1 Server: 15.227.128.51 Address: 15.227.128.51#53 Name: mxf4458nt1.esr.hp.com Address: 15.32.161.3 # This example shows the server and address used for the nslookup command. Then the fully qualified name of your system appears and its IP address. You may get a message indicating that nslookup may be replaced in the future. You can use dig, which provides more detailed information on host lookup. dig is a newer command than nslookup and will be available in future releases. /etc/hostsAs mentioned earlier, this file contains information about the other systems to which you are connected. It contains the Internet address of each system, the system name, and any aliases for the system name. /etc/securetty for Equivalent root AccessIf you have a highly self-contained environment, you can set up your Linux systems so that root can run remote commands from one system to another, login to a remote system without a password, and perform other such functions by making entries in /etc/securetty. /etc/hosts.equiv performs nearly the same function for other users. Using /etc/securetty is considered a severe security risk, so please use this technique for system-to-system openness only if you have an environment that is not exposed to any users who are potential security threats. The secure shell (SSH) and other such tools is highly preferable to this technique because they use encryption. To have root as an equivalent user on multiple systems, enter the desired services into /etc/securetty. The following example shows entries for rexec, rsh, rlogin. To allow root to log in using these tools via telnet, make the following entries in /etc/securetty: rexec rsh rlogin pts/0 pts/1 After making these entries, run the following command: # /sbin/service xinetd restart At this point, you now have this functionality enabled for root. This is not required for other users. Other users require only /etc/hosts.equiv to get this functionality, as described in the next section. /etc/hosts.equivYour system may be set up so user's don't have to issue a password when they rlogin to a remote system; they can set up equivalent hosts by editing this file. As with /etc/securetty, this is technique considered a security risk. The login names must be the same on both the local and remote systems for/etc/hosts.equiv to allow the user to bypass entering a password. You can either list all the equivalent hosts in /etc/hosts.equiv or list the host and user name you want to be equivalent. Users can now use rsh and other such commands because they are equivalent users on these systems. I usually just enter all the hostnames on the network in this format: host_to_trust#1 host_to_trust#2 host_to_trust#3 Keep in mind the potential security risks of using /etc/hosts.equiv. If a user can log into a remote system without a password, you have reduced the overall level of security on your network. Even though users may find it convenient to not have to enter a password when logging into a remote system, you have given every user in /etc/hosts.equiv access to the entire network. If you could ensure that all the permissions on all the files and directories on all systems were properly set up, then you wouldn't care who had access to what system. In the real Linux world, however, permissions are sometimes not what they are supposed to be. Users have a strong tendency to "browse around," invariably stumbling upon a file they want to copy to which they really shouldn't have access. Secure Shell (SSH)SSH is a method of establishing a secure session between two systems. The client initiates a session with the server in which all communication is encrypted. Passwords and all data are encrypted so that programs monitoring networking traffic, often called "sniffing," or employing other techniques to breach security, are less of a threat and thereby security is increased. An SSH client component and an SSH server component are both supplied with most Linux distributions. SSH is available for almost all client and server systems. The client programs are ssh, scp, and sftp and the server program is sshd. Two versions of Secure Shell are available called SSH1 and SSH2. The protocols for these two version are different and incompatible with one another. SSH2 provides sftp which is a replacement for ftp. You may notice some performance degradation when using sftp in place of ftp when copying large files. This is because encryption takes place for all packets that are transferred. OpenSSH is used on Linux distributions, which has system-wide configuration files in /etc/ssh. User-specific files are stored in the ~/.ssh directory. The ssh and sshd manual pages contain a lot of information regarding the configuration of SSH. Many SSH clients are available for many different systems. When establishing a connection through an SSH client, you are asked the hostname or IP address of the system to which you want to connect, the protocol such as telnet, rlogin, or others, and then you connect to the server. Operation of telnet through SSH is similar to non-secure telnet operation from a user standpoint, even though encryption takes place at the transport layer. SSH is strongly recommended to increase network security. It is easy to implement and provides a much higher level of security over non-SSH communications. |
| < Day Day Up > |
EAN: 2147483647
Pages: 100