Network Administration

At the lowest level we have a physical Layer - often the physical layer will be Ethernet, fast Ethernet, gigabit Ethernet, it might be a Token Ring, Fiber Data Distributed Interface (FDDI) amongst many possibilities.

Essentially what that boils down to, is the cabling, the network cards, the switches, the routers what do they talk at a physical layer?

Are they gigabit devices, Ethernet devices or Token Ring devices?

This level would consist of the device driver and network interface card and is responsible for forming the packets and then transmitting them across the physical media.

This layer is referred to as the Media Access Control Layer, the Link Layer or Layer-2.

The MAC layer is responsible for the MAC address of a network card. This is a 12 byte address, commonly the hardware address of the interface card. The MAC address on my only interface card is: 00:01:03:8C:FB:01. Since any two machines can only talk between one another at the MAC level, they each need to know each other's MAC addresses in order to communicate.

The destination address of the packets are checked at this level when the correct destination is reached, the Ethernet header is stripped from the packet and it is passed to the Network layer of that system.

The network layer is responsible for IP addressing in the network. In fact, the network layer is critical to so many aspects of communication and it is where IP gets its name - the Internet Protocol. IP addresses denote the logical network as well as the address of each device on the network.

This layer has the capability of handling two protocols, the first is Transmission Control Protocol and the second is User Datagram Protocol (TCP and UDP).

TCP is responsible for breaking up the message into packets and reassembling the message at the other end. Resending anything that is lost and making sure that the message is put back together from the packets in the correct order.

UDP is designed for applications that do not require the packets to be in any specific order. UDP is therefore termed a connection-less protocol.

At this level the server provides the requested service for the client. For example, the client requests a login into the server, so the client requests a remote login and the server provides the service with the remote login daemon. The service that is provided is the login service.

If you look at a Class A network address for example, it is defined by the first 2 bits of the first byte. The first byte makes up the network portion of the address, while the remaining 3 bytes make up the hosts portion of the address. With this in mind, an IP address of 10.20.30.40 would have the host 20.30.40 on the network 10.

If I gave you an IP address of 152.111.16.10, using our rules, 152 falls into the B class. The B class has the first two sets of bytes in the network portion and the remaining two sets of bytes in the host portion. With this IP address, this would be a host 16.10 on a network 152.111

In Class A the MSB has to be 0 which means the address ranges form 1 to 127 in the first byte, and also where the first byte represents the Network portion, and the remaining three bytes represents the Host on the network. Now if we look at that we can see that on a Class A Network you can only have 128 Networks but you can have a huge number of hosts on every network, how many? You can have a total of 224 hosts on 128 Networks.

In Class B the MSB must be 10 and the range from 128 to 191 and here the first two bytes represent the network and the remaining two bytes represent the Host. In class B we will have 216 Networks and each of those networks can have 216 hosts.

In Class C the first three bits of the MSB is 110 which means the range is from 192 to 224 and for that the first three bytes are the network portion, and the remaining byte is the host portion. And on class C you can have 224 Networks and 28 hosts per network.

Since we are only working with a total of 4 bytes, as the number of hosts increases, the number of networks decrease and visa versa

20 years ago any one of these options would have given most companies enough addresses to work with, but that of course was before the Internet took off.

Now every machine that connects to the Internet needs an IP address. This was do-able 12 years ago but now that more and more devices are Internet ready, and with the growth of Linux and embedded Linux devices, we will see more and more Intelligent devices such as:

As you can see very quickly we will exhaust the number of available IP addresses.

There are a couple of ways that they (InterNIC or IANA - the authorities who hand out valid IP addresses) decided to solve this problem as they couldn't go on handing networks in the class B range, because there were not enough network addresses to go around. So what they did is to come up with a means of sub-netting a range if Internet addresses: sub-netting is a means of chopping up an IP range. In essence, sub-netting involves moving the host and network bits and in this way making the ranges change accordingly.

11111111. 11111111. 00000000. 00000000
 

11000100. 00000110. 00010111. 00001110  (196.6.23.14)
11111111. 11111111. 00000000. 00000000  (255.255.0.0)
----------------------------------------------------------
11000100. 00000110. 00000000. 00000000    (and result) 
                    

11111111. 11111111. 11111100. 00000000 (255.255.252.0)
                    

11000100. 00000110. 00010111. 00001110 (196.6.23.14)
11111111. 11111111. 11111100. 00000000 (255.255.252.0)
--------------------------------------------------------
11000100. 00000110. 00010100. 00000000  (result of AND) (196.6.20.0)
                    

ifconfig eth0 [enter]
                    

So if we return to our five layer stack, you have the physical layer at the bottom followed by the MAC, the network (commonly called the IP), the transport which is usually connection orientated (TCP) or connectionless (UDP) and finally the application layer.

We have now had a look at the IP layer and note that every single device on the Internet needs a unique IP address in order to communicate with the other device(s).

Having now understood IP and the fact that everything needs an IP address. We can now talk briefly about how information is transferred over the Internet.

What happens when workstation A wants to talk to workstation B?

They have the following IP addresses: Workstation A is 196.6.23.14 and Workstation B is 196.6.23.24

Workstation A does is a broadcast. In other words it broadcasts to every other machine on the Network, with what is called an ARP (Address Resolution Protocol).

It does an ARP and basically what that is, is a broadcast over the network, saying "I want the IP address of Workstation B, but before it can get it 's IP address I need to know what the MAC Address of workstation B"

So by workstation A doing a ARP request, it forces all the workstations on the Network to respond by giving up their MAC addresses. All the workstations on the network respond to this request and Workstation A builds an ARP table.

An ARP table will hold all the MAC addresses and hopefully all the IP addresses of everybody on the network.

Testing whether two hosts on a network are alive and can see one another is a fundamental network test. This is done using the Packet Internet Groper command (ping).

Ping 's job is to send an echo request and await an echo reply from the remote host. Thus, two workstations A and B, on the same network can both send and receive echo packets. If workstation A sends an echo to workstation B but does not get a reply, it could mean the remote hosts (workstation B) did not receive the request. Pinging is so fundamental to the troubleshooting of networks that we need a whole section to discuss it. That section appears later. Now however, we can use ping to broadcast to each workstation in order to fill up our arp table. Remember that each time a broadcast request is transmitted over the network, all hosts on the local network will respond to the broadcast. The overall result is that each workstation will have a complete list of hosts on their local network.

ping -b 196.6.255.255 [enter]
                

You have to be root to use this command.

Note that we ping the broadcast address. If you are not using this IP address range, use ifconfig to determine what your broadcast address is.

What this does is to ping every workstation, and every workstation that replies will have to reply with its MAC and IP address. Once you have run this command you can type:

arp -a [enter]
                

This would show all the information in the ARP table.

Once Workstation A has built up an arp table including the information of what workstation B 's MAC address is as well as workstation B 's IP address, Workstation A can start to communicate with Workstation B. They may need to communicate over a connection-orientated protocol like TCP (for something like the 'telnet' application) or perhaps using a connectionless protocol like UDP for DNS updates.

ARP is really a UDP based service, because it does a broadcast by sending out a packet on the network expecting devices to reply. ARP is not interested if the workstations on the network receive the packets. If you Sniff your network (we will talk about that later) you will see these ARP requests being sent out continually by hosts on your network.

The explanation above assumes that everybody is on the same network. We know this is not the case, so we also need to establish the concept of the differences between layer two and layer three networks.

Essentially at Layer Two workstations are only communication at MAC address level. Therefore, while two machines are physically connected to the same local area network (LAN) they can communicate.

Now what happens is that networks were designed to connect computers together, in the simplest case we started off with a network and put some machines on the network.

These machines were able to communicate with each other without any interference, but what happened next is that we found that we had a need for a second network. It might be on another floor in the same building or in another building. The machines on the second network could talk to one another however they could not talk to machines on the original network.

Routers were developed to deal with this problem. Their job is to route packets via different networks. You could think of the router as a traffic policeman on a busy intersection. When you come along road A and you want to go to road C the traffic police(wo)man will direct you down road C. She (traffic police(wo)man) stands in the middle and when she sees you coming along with a big sign on your windscreen saying you want to go to road C, she immediately stops other traffic and directs you to your destination. Routers do a similar job - only with packets rather than cars.

Now what happens here is that Workstation A wants to talk to Workstation E and these are on completely separate networks - not directly connected to one another. An example might be doing an ftp to ftp.is.co.za . In all probability, your host will not be directly connected to the hosts ftp.is.co.za.

Now when we talk about a network, we are not talking about the MAC layer, we are talking about the Network Layer or the IP Layer.

You may have a 196.6.23.x network (netmask: 255.255.255.0) as well as a 147.63.15.x network (netmask: 255.255.0.0).

Now these are two completely separate networks, one is class B the other Class C, and the router is able to route packets between the class B network of 147 and the Class C network of 196. The router 's job is to direct packets.

Now you can imagine if everybody pulled out a loud hailer and started broadcasting it would become a pretty noisy place quite quickly. How do we stop that? Well in networking terms there are not a lot of ways we can stop that.

There needs to be a way to stop these broadcasts from passing from one network to the next. The way that this happens is to force the router to block all broadcasts. So if the router hears a broadcast coming through, it will immediately drop that packet and not allow the transmission of the packet across to the other network.

You can imagine that it would become very noisy if every time somebody sent out a broadcast it was allowed to be transmitted to all networks. How often in the real world does somebody pull out a loud hailer? Well generally at election time when they want to gather some support.

In networking terms computers broadcasts every couple of seconds, they start shouting about who they are and who else is on the network etc. Etc. As you can imagine, this will cause a lot of traffic on the network for no apparent reason. So routers restrict the broadcast domain to the local network.

Broadcasts can only happen on the MAC layer and any broadcast that tries to go across the router will be dropped. One of the things you may want to broadcast across a router (and you can configure a router to allow certain broadcasts) is DHCP (Dynamic Host Control Protocol). However, we will talk about this later.

To summarize routers are responsible for routing Internet Protocol traffic at the Network Layer, from one Network to another. This contrasts with switches or bridges, where bridges work on the MAC layer, and thus have no way to restrict broadcasts.

If a workstation on Network One starts broadcasting, the workstations on network two will be able to receive and respond to the request. Bridged and switched networks are termed "flat" networks and there is little barrier from hosts connected on one switch to another.

OK so we have Routers that allow networks to be connected, and we have switches that create flat networks where you cannot create separate networks on a switch.

We will configure our Linux boxes later on to act as routers. This is an area that Linux has gained acceptance, where you are using your Linux Box to become a router between yourself and the Internet.

If you have three PC 's but just one modem Linux allows modem sharing and has done so since 1993. Windows now also allows modem sharing (ICS) which essentially allows the system to act as a router.

A LAN is a Local Area Network and a WAN is a Wide Area Network.

These barriers seem to be crumbling as we speak. Traditionally LAN's were restricted to a building. A typical example of this is a building that has a number of floors all connected together. The way these floors are connected is via a router in the basement. Thus, each floor has a link to the basement where a large router connects the floors together.

Essentially even though these different networks are routed they are still considered to be Local Area Networks, because they are limited to a building. The minute you go from a single building to connecting two buildings, (you may have a wireless link between the two buildings) you are creating a Wide Area Network between these two buildings.

WAN 's are generally considered to be those networks running over low bandwidth expensive links. Consider the price per packet of transmitting data over a WAN, it would be significantly higher than that of a LAN.

If you look at the speed you get over a WAN versus that of a LAN, you will see that a LAN will be significantly faster than a WAN - although this gap seems to be closing too.

Currently, for example, on a WAN over a wireless network you can currently get up to 54 megabits per second. Whereas on a LAN you can get up to a 1000 megabits per second.

In this Networking course we will look mostly at LAN's. With one exception: connecting the Linux system to an ISP. The minute you connect your Linux system to an ISP you create a WAN.

Run "info" on ifconfig to learn more about this command.

Basically the ifconfig command sets an IP address onto your Ethernet 0 interface.

Once that Ethernet 0 interface has an IP address run "ifconfig eth0" and you should see the following:

In your test network you are going to have to configure, one IP address per workstation, and in the example just done we have already configured Workstation A.

On Workstation B you are going to run a similar command, but instead of 192.168.0.1 it is going to be 192.168.0.2. Testing the set-up with ping

The first thing you're going to want to do now is see if these two machines respond to one another, and the best way of doing that, is to use the packet Internet groper or the ping command

Assuming that you are sitting at Workstation A you might want to ping 192.168.0.2, which is Workstation B.

You may need to understand a little bit about the ping command in order to understand what you are testing. When you ping something it sends a 64 byte packet (echo request) to the other machine that you are setting up, in our case, Workstation B. As soon as Workstation B receives the packet, it replies with an echo reply by sending a 64 byte packet back to workstation A.

When we do a ping we are sending a packet called an ICMP packet, and that stands for an Internet Control Message Protocol.

The ICMP originates from within the network layer.

Look at our two machines and the network layer and the MAC layer. The packet originates at the network layer it proceeds down the stack as we have seen, onto the physical network and then reaches its destination and moves up the protocol stack but it does not go all the way up to the application layer it only goes to the ICMP layer - which is a sub-layer within the network layer.

When the packet is received by Workstation B it is then sent back to Workstation A in the same manner through the stack.

To repeat the process: When you ping something you send a 64 byte packet, a 64 byte ICMP packet from the network layer to the MAC layer, to the physical layer which then goes to Workstation B. The packet then goes up from the physical layer to the MAC layer, from the MAC layer to the network layer and when the network layer receives this package, the packet, it replies.

Ping is a good way of testing whether you get connectivity between two workstations but unfortunately it is not necessarily an end to end service indicator. The reason for this is that an ICMP packet never reaches the application layer, so although you can ping two machines it doesn't mean to say that you can send email between those two machines.

At some higher layer (perhaps at the transport layer or the application layer) the protocol could actually break down and therefore there is no end-to-end connectivity from an application perspective.

So ping is useful and you can use it for a lot of different tests but not necessarily an end-to-end service test and in modern computer terms this is really what people are interested in.

OK, so, once you've got your machines connected and you can see them and you can ping between one workstation and another, you should see that you get a reply for every packet that is sent. We will investigate the ping command in a little more detail shortly, because it is certainly your first port of call when trying to fix problems on a network.

CIDR (pronounced cider), or Classless Internet Domain Routing is another way of expressing our network subnet pair, network netmask pair.

We may have an IP address 192.168.16.65 with a class C network 255.255.255.0 or we could express this as 192.168.16.65/255.255.255.0..... this is quite a mouthful.

CIDR is just another way of expressing the same thing.

You can express the IP address/subnetmask combination as 192.168.15.65/24.

What does 24 mean? It means 3 sets of 8 bits (24 bits on total) where each bit in the byte is a '1'. So if we were using a 10 network 10.25.48.132 and we used "/8" at the end that would tell us we are using a class A network using a class A subnetmask 255.0.0.0

CIDR is just a very easy way of expressing this.

What I want to look at is troubleshooting your network. We do not know enough about networking to be complete gurus but we need to be able to at least troubleshoot any problems that we may have.

We have seen already that we can use the ping command. Now ping tells us more that a device was able to receive and reply to packets sent. It also tells us about reachability. Reachability is one of those criteria or stats that people want to know about their network - can this device be reached on the network.

The second thing it tells us is about delay or latency.

If you look at the right hand column of the ping command you'll notice that it tells us the delay in the packets reaching their destination and returning (usually in milliseconds).

So if you run the command ping -c 10 192.168.0.2 supposing that you are sitting at 192.168.0.1 or Workstation A. There will be 10 icmp requests sent out and hopefully 10 icmp replies returned.

So a ping will send out (by default) 64 byte packets from Workstation A which would be received by Workstation B. Workstation B would then reply with 64 byte packets and that process would be timed which will indicate the latency.

The third thing you will see that ping provides is a sequence number. A sequence number indicates the sequence that the packets were received in.

As an example, what you can try is:

ping -c 100 192.168.0.2 
                

this will send 100 pings instead of just 5 pings.

After hitting enter unplug network cable for 5 seconds or 10 seconds then plug in again. The sequence numbers will start off at 1 and they will increase until such time as you unplug the cable. Let 's say you waited 10 seconds the sequence would get to 10 (at which point you unplugged the cable), you waited say 10 seconds then you plugged it back in. You should see the sequence continue at 20.

This example assumes that ping is sending an echo request every second which is the default frequency request, so you'll see that the sequence indicates that after 10 seconds there were some packets that were lost. How many? About 20.

Finally ping gives you a summary of the response from the remote host. This summary usually appears right at the bottom where it tells you things like your RTT, which is your round trip time, the maximum and the minimum time, the average and the standard deviation as well as telling you about the packet loss.

Now because this is happening at the network layer it would be nice to see what happening one layer below that, at the MAC layer. For this we can use the arp command.

You can do an info on arp to see what options you have.

If you do an arp -a this will show you the full arp table.

If you don't see the MAC address of the workstation that you are trying to ping in arp table then will never be able to ping that MAC address.

In fact, Linux has another nifty command called arping. Arping is used when you get an IP address using DHCP.

So arp will tell us what happens at MAC layer and ping will tell us what happens at network layer and we can use these to troubleshoot our network.

An example of the good use of interoperability is that you may have had a DEC server, a Dec VAX for example, running X 11, the X Windows system. On the client side you have a Unix machine and so the X-server, because it was a standard protocol, could offer it 's services to the Unix workstation.

Another example would be a font server, where we have one or more font servers in the network. Even if the font servers ran on a Dec VAX or on Solaris or an HP Unix machine, X font clients will have access to service. So a Unix or Linux machine would be able to use the font service offered by a VAX machine.

The final reason for the advantages of interoperability I am going to mention here is "central control".

Central control is something that is familiar to those people that were working with Main Frame computers, and in a way it is ‘funny' how IT fashion is coming back on itself as now we have client server technology and this allows us to have central control of, for example, what applications to serve to and what services to serve on a network.

A classic example of client server technology is the Citrix windows client and server technology that we'll see being implemented for Windows clients in a lot of networks today.

So how is this central control implemented?

Well, I think the best way to describe this is to give some more examples.

Sometimes in client server the client and the server reside on the same machine, an example of this is X11, X Windows system, implemented in Linux. In the X Windows system, we would have an X 11 server on top of the Operating System and on top of that we would have client applications.

The client application might be X Clock or say K-Astroids or TUX-Racer. These applications are essentially our client and beneath our client we are running a server.

X is a particularly interesting one because in order to run KAstroid or TuxRacer or X-Clock, we are forced to have a server provide those services. It 's the responsibility of the server to talk to the video card, for example, to explain to the video card how to display a penguin racing down a ice slope

What makes this even more interesting is the fact that because every Unix or Linux system that you are running a GUI on you are going to have an associated X server running.

There is no reason why you couldn't display these aforementioned clients on the server. So in this case we have a machine that's offering itself as the client and we have another machine offering its X11 server as the server. Clearly we could swap those around the crossover line, for example we could run X Clock on machine B but use the services offered by machine A, X 11 server, to display the clock.

Lets have a look at a simpler example with FTP (File Transfer Protocol), in this case we might have access to Internet Solutions that has a repository of all the Linux ISO images that we want to download.

How do we do that?

Well, let us say that on our client 's side we have a client application called GFTP (Gnome File Transfer Protocol) ftp server. This GFTP server is the client and Internet Solutions ftp server, is the server.

We use our client 's to contact the server and this happens on different machines, unless you are running your own ftp server to ftp files from yourself to yourself, which really would make no sense.

This example demonstrates using http or web-based services as client servers.

On the server side we might have an Apache or IIS running as a server and on the client 's side we would have our browser, as in the Firebird, Gallion or Internet Explorer.

In that scenario, we would have an http server, usually running Apache and on the client 's side we would have a browser. Not all processing is done on a server, the server sends a web page and the browser, on receiving that web page, interprets it and displays it in a presentable form.

Because of the structure of Internet Protocol (IP) and because of the fact that we can have different networks, we could take one set of machines on network A, 192.168.0.x and another set of machines of network B, 172.16.4.x.

That means that the two sets of machines are connected physically.

When machines are connected to the same networking backbone (wire), yet are on separate networks, these networks are termed Logical networks. For example you could have 5 machines with the address range on 192.168.0.x and 5 other machines on the address range 172.16.10.x. Although they are connected to the same backbone, they are on separate Logical Networks.

This physical network layout is that they are all connected. The logical network layout is that they are separated because they are on separate IP networks.

In fact workstations, on the 192.168.0 network will be unable to talk in any way to workstations that are on the 172.16.4 network.

Token Ring network can be thought of as a ring of machines connected to each other. Each machine has an opportunity to pick up the Token, almost like a baton in a relay race. What would happen is that a machine would pick up the Token and would get allocated a time period with that Token. Once their time is up they will have to put the Token back onto the wire for the next machine to pick up. Only the machine which has the token may send data at that time.

Token Ring as a topology is a far superior topology to Ethernet, the joy about Token Ring, is if you broadcast, there should be very little shouting on the network.

Token Ring however, has taken a back seat and it 's not implemented any longer - for a number of reasons, mostly because of slow micro data as it could only ever run between 4 Mbs and 16 Mbs.

It was also a very much more complex and expensive technology than Ethernet is.

So Token Ring died and people adopted Ethernet as their topology of choice.

Ethernet was or is what 's called a contention-based network. In other words, every machine on the network shares the same piece of wire. Ethernet is just a topology where "he who shouts the loudest gets to be heard".

Ethernet comes in a whole range of flavors. Ethernet, in its Vanilla flavor, or in the original flavor, ran at 10Mbs.

	Note
	I'm not going to go into exactly how fast that is but you can compare this to a modem that will generally dial up to your ISP at 56Kbps and you can see that 10 Mbs and 56 Kbps is a significant step up in how fast the Internet runs as opposed to a modem.

Development continues on Ethernet with technology called fast Ethernet. Fast Ethernet ran at 10 times the speed of normal Ethernet and this certainly looked like it was going to be the fastest technology around (say 100Mbs).

Now there 's Giga bits Ethernet, which runs at 1000 Mbs, 10 times faster than fast Ethernet and certainly this seems to be the technology that corporate companies are implementing around their networks (currently).

With this CSMA/CD we have what 's known as the MTU (Maximum Transmission Unit).

To continue our previous analogy with the train, the MTU is how long the train can be.

There 's a maximum size that our train can be when we stick it on the railway line. The maximum length a train could be in Ethernet is 1500 bytes and that 's the maximum transmission unit.

If you run the ifconfig command on the command line (logged in as root), you'll see there'll be an entry there called MTU in capital letters and that will be set to 1500 which is the standard size of a Ethernet train.

Now we've seen from the TCP/IP stack, that at the bottom there, we'll have a physical layer and this is what we are now referring to as Ethernet.

	Note
	Of course if you have Token Ring then the physical layer will be Token Ring.

Above that, we have Media Access Control layer, the MAC layer and in fact any 2 servers or workstations, can only talk to one another via the MAC address. They should be using the same physical connection. (Not strictly true but we'll cover that just now.)

In other words, 2 workstations or a server workstation or 2 clients want to talk to one another, they can only talk to one another using their MAC address.

You can use the "ifconfig" command to determine what the MAC address of your NICs are.

You cannot talk between two machines if they contain the same MAC address. It would be like the postman trying to deliver mail to No. 21 in the same street where 2 houses, 3 houses have the same No. 21. Clearly the postman's not going to know which one to deliver to.

Every Network Interface Card on the network needs a unique MAC address and these are supplied by the manufacturers of the NIC.

The MAC address is broken down into 2 by 6 byte numbers. The first set of 6 bytes is the manufacturer 's identifier and the remaining 6 bytes is the unique identifier given to this particular network interface card by that manufacturer. There are hundred of manufacturers of network interface devices around the world.

To find a out the MAC address on the workstation you are on you can type:

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:00:86:3C:A3:0A
              inet addr:192.168.2.233  Bcast:192.168.2.255  Mask:255.255.255.0
              inet6 addr: fe80::200:86ff:fe3c:a30a/64 Scope:Link
              UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:13655 errors:0 dropped:0 overruns:0 frame:0
              TX packets:5502 errors:0 dropped:0 overruns:0 carrier:0
              collisions:6 txqueuelen:1000
              RX bytes:7570021 (7.2 Mb)  TX bytes:632146 (617.3 Kb)
          Interrupt:3 Base address:0x300
                

The MAC address is the hexadecimal number after HWaddr. As in: HWaddr 00:00:86:3C:A3:0A

In our CSMA/CD model we used a couple of terms that we need to define further and the first term is to "BROADCAST packets".

Broadcasts are really exactly what the name implies. It 's a broadcast - for example, KFM Radio is broadcast radio, it doesn't know who is receiving the signal but the radio station still broadcasts the signal. If you turn your radio on, you hear it. If you turn it off, you don't.

Broadcast packets are similar in that a workstation, server or network interface card will broadcast to every workstation on that network, and part of the Ethernet 's job is that if it hears a broadcast, it must hear that broadcast.

The next concept is the concept of "UNICAST".

UNICAST 's are packets where one workstation is talking directly to another. If you are going to have a conversation on the telephone, you're having the UNICAST conversation. Well, provided it's not a conference call.

You're having a UNICAST conversation because you are talking directly to the person on the opposite side.

The final term we used is "MULTICAST".

That would be the equivalent to a conference call as mentioned above where there are a number of recipients who are tuned into that conversation.

Essentially, the distinction between these is the fact that Broadcasts are very noisy, in other words, when I start broadcasting, I hold the loud hailer up and I start calling the odds. Nobody has got any opportunity to talk back to me.

When I have a UNICAST or MULTICAST conversation, it 's a conversation, I'm talking to a client(s), and the client(s) is talking to me.

The same happens on a network and let 's look at a couple of examples.

Broadcast services are noisy. That is, the more broadcast services you have on your network, the less opportunity you have of talking in a UNICAST manner - between client and client, client and server or server and server.

So Broadcast 's aren't desirable to have on your network in large volumes. You will need to use them, but it 's important to realize that broadcasting on the network is far from optimal. A candidate that is particularly prone to generating large volumes of broadcast traffic is the process of master browser selection in a Windows network.

ARP is the Address Resolution Protocol and its job is to match MAC address to IP address and obviously vice versa - to match IP addresses to MAC addresses.

In workstation A 's ARP table, we have stored the information on workstation B and it 's MAC address. If workstation A talks to workstation C, we'll have the same information for workstation C stored on the ARP table.

Workstation B replied to workstation A and therefore will have stored the relevant information. If workstation B also talked to workstation D recently, it will have workstation D 's IP address and MAC address stored in the ARP table.

arp -a
                

Run "arp - a" which will report on all the information it has stored on the ARP table during the usage of the network for that workstation.

The ARP table is a dynamic system table, it is built-up at the time of communicating with the different workstations. After a period of time, if workstation A no longer speaks to workstation B the system will age out the entry in the ARP table.

Now lets complete the circle of logic: If after the entry for workstation B has been aged of the ARP table on workstation A, and once again workstation A again wants to talk to workstation B? Workstation A will once again put out ARP request to broadcast by saying, "Who has the MAC address of workstation B" And again, B will reply saying, "I have it and here it is." Again the information will be stored back into the ARP table of workstation A. Doing arp with the '-an' options will enable you to see all the machines that you've communicated with prior to the aging period being reached.

In some versions of the Linux operating system there 's a command called arping. arping is a MAC based ping program, which has the job to determine whether the IP address for a particular MAC address is already being used on the network.

Unicast services such as ssh, telnet and ftp do not use broadcast mechanisms to communicate. As a result they are less noisy and more efficient on the network.

Up to now we've been talking about Ethernet and I've made reference to the fact that Ethernet is a LAN.

A LAN is a Local Area Network. Local is generally referred to a network contained within a building or an office or a campus.

Examples:

To set up a LAN -relatively speaking- is cheap. If you want to put an extra couple of network points or an extra couple of devices on the network, it 's not very expensive to do that.

Using a similar example, a Wide Area Network is a network that connects campuses.

What I'm going to do is write down some short descriptions of what a WAN is:

1. A WAN is generally slow. If we compare that to a LAN, we said that Ethernet could run up to 1000 Mbs, currently, certainly in South Africa, the fastest WAN is 155 Mbs, so you can see in a LAN we can talk up to 1000 Mbs whereas in a WAN, at the moment, currently, today in South Africa, we can only take, literally a 10th of the speed.

2. WAN's are expensive. If we look at the path of telecommunications, we need to connect two offices, one in Pretoria and one in Johannesburg together - it 's an expensive operation even for a slow line.

One of the differences between a WAN (Wide Area Network) and a LAN (Local Area Network) is the set-up cost. WAN generally are to connect remote offices and when we talk about remote offices we generally refer to the remote offices as those that are outside the campus. For example, if we have an office in Pretoria and we have an office in Cape Town, these are remote offices. There is no chance that we can connect the LAN between Cape Town and Pretoria. In a LAN we connect local offices whereas in a WAN we can connect remote offices.

How do WAN 's work?

Well, a WAN does not use Ethernet, a WAN is something slightly different

Let 's now look at the various components that are used in a LAN and in a WAN.

So in the make up of the LAN, we need something more. Switches don't cut it because they can only talk on a network that 's on the same logical network - they can't talk across networks.

So what do we do?

Well, we use a Router. Earlier technology included routers and gateways.

Show how to look at the routing table in Linux

A router serves the job of translating between one network and another.

A Linux box can be used as a router. In fact on every Linux box you have a routing table.

A routing table tells us a number of things such as what IP addresses are attached and what ports are on the router. It also tells us whether the port is up or not.

In order to see a routing table you can type the "netstat -rn" command and that will show you your routing table.

	Note
	The -n option has to do with network translation and we'll talk about network translation shortly.

ifconfig eth0 192.168.0.1 netmask 255.255.255.0
                    

ifconfig eth0:0 
                    

The final issue we want to talk about is broadcast domain.

Domains are an issue you are going to hear about, a term you are going to hear over and again in a number of different contexts.

In this context that we are talking about, a domain, a broadcast domain is the region that a broadcast on a network is heard.

Just because we have a switched network doesn't mean to say that we don't do broadcasts. For example, ARP is a broadcast and DHCP is a broadcast.

If you do a arp -p, that 's a broadcast. As said before, what happens with a broadcast is that every workstation hears the broadcast, and they respond to the request.

However what happens in our scenario above: Imagine if every broadcast that was put onto the Internet or on to the network was heard by every single machine on the Internet- clearly we would end up with a quite congested network.

So, a broadcast domain is the area that broadcasts are received, and broadcasts are restricted by routers.

In other words, if the router receives a broadcast it is dropped. This is what we call the broadcast domain, where the domain is the extent to which broadcasts are heard on the Internet or on the network.

In our scenario at ACME Widget Company, we have a router connecting to an ISP 's router, connecting to a server and clients.

When client A broadcasts on the network that 's an ARP request which is a broadcast and because it 's a broadcast everybody is obliged to listen whether you're a router or a server of a workstation, you are obliged to listen.

Because the router restricts the broadcast the extent to which the broadcast will be heard is restricted to that network.

In other words, the router to the Internet will not up-broadcast or will not relay that broadcast message and that is called a broadcast domain.

Sometimes there can be problems on your network where for example, you might have two networks connected by a router. In network A you have a DHCP server and network B you have no DHCP server, you want to offer DHCP IP addresses from network A to network B.

DHCP is a broadcast, router at that point of A entering into the router restricts it. So no DHCP request will ever be answered on the B network.

There are ways around these problems but that 's essentially a broadcast domain and because Linux can be a fully-fledged router, it can handle all these jobs without a problem.

What I'm going to do is show you how to set the IP address statically. Setting the IP address statically can be done using a file (in which case the IP address will remain across a reboot) or on-the-fly (in which case the IP address will revert to what is was initially after a reboot). I'm going to show you an on-the-fly set-up using the ifconfig command.

Ifconfig has a whole host of options to it, in Ethernet you need to tell it what Internet address to assign, this works right across all the distributions of Linux.

If we have the Ethernet card 0 with the IP address of 192.168.0.1 then we need to give it a netmask of 255.255.255.0. Once that 's set, if you do an 'ifconfig eth0' (this time without the IP address) you'll see that your IP address has changed and it 's now 192.168.0.1.

It might be worth just having a look at what other information shows up in that ifconfig eth0. We've seen earlier that your hardware address HWADDR shows up and that 's that 12 byte number, 00:01:03:8C:FB:01 (on my computer) number that indicates your MAC address.

It also shows you that the encapsulation later 1 protocol we're using in Ethernet. It shows up our INET address, which is the one we've just assigned. And the broadcast address.

Now from our earlier discussion on IP, our broadcast address is the address where the host portion is all 1 's or 0's. In this case our broadcast address is 192.168.0.255 and there 's the host portion - that is 1. If we take our IP address and we add this with our mask it shows us what network this host is on - in fact we use a standard class C network mask we know that the network with device is on is the 192.168.0 network. Then the next line we see "UP", indicating that this network is currently up.

We could for example run the "ifconfig eth0 -down" command and that would shut the network down and switch our network off.

Of course if we then did an "ifconfig eth0 up" the IP address that we set dynamically on-the-fly would be gone and we would have to run through the ifconfig command sequence again. There 's a whole bunch of other information there - broadcasts (in other words, this card is capable of broadcasting). It is also capable of multi-casting and there is the MTU ( Maximum Transmission Unit), and we saw earlier in the course that the MTU is 1500 bytes. The maximum units in size that Ethernet can carry. There is also a METRIC. A metric is now how many hops we need to get to the correct IP address (network) and in fact the metric here is 1.

Finally there 's information such as the number of received packets, number of errors, overruns, frame, number of transmitted packets, collisions, transmits and receipts of bytes.

All this information is important - without one of the tools working you can't run the network. For example if you get the interrupt incorrect, your network interface card cannot be seen by the operating system.

We talked earlier about plumbing the network card and in this section we can do this on the fly.

Plumbing network card points to two different IP addresses or two different networks on the same network interface card.

In this case, eth0 interface is at the IP address 192.168.0.1 we could say, well eth0:1 must have the address 172.16.4.1.

This actually is using the Linux box as though it were a router, on the one side we've got one IP address and on the other side we've got another IP address.

How do we do that?

Do an ifconfig eth0, that is 192.168.0.1 netmask 255.255.255.0. If we do an ifconfig after plumbing the device, ( i.e. On eth0:1) it will set that to 172.16.4.1 with a netmask 255.255.255.0.

So, that 's the way of plumbing network interface cards. Again, because it 's on the fly if we shut our interface down, then both eth0 and eth0:1 IP addresses would be lost.

So far, we've done a whole lot of changes on-the-fly. We can also set these things statically so that after a re-boot the machine configuration stays the way it was set up. For this you need to look at a file called /etc/network/interfaces

In order to have the IP address stored in a file, in other words, we don't want to get it from DHCP and we don't want to have to configure it every time with an ifconfig command - we will need to edit a file.

The file in Debian is /etc/network/interfaces, and if we look at the interfaces in the file, it will have entries as shown below (or similar):

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo eth0
iface lo inet loopback

#mapping eth0
#       map WORK work-eth0

iface eth0 inet static
        address 192.168.10.1
        netmask 255.255.255.0
        gateway address 192.168.10.1
                

	Note
	This file is not in this location in SuSE (in SuSE, most things are changed through the tool YaST). In RedHat we need to edit a file called "/etc/sysconfig/network-scripts/ifcfg-eth0"

"iface eth0 inet static" will set the interface Ethernet0 and make it static and we could say here that the address is 192.168.0.1 netmask 255.255.255.0.

Once you set it statically you can say "ifdown eth0" and "ifup eth0" and that will re-start the network card for you whilst still having the same address. An interface will come up every time to use the same IP address.

I am going to change my system files as above.

Dynamic addressing is different. Dynamic addressing purely comes from the DHCP server.

DHCP server stands for Dynamic Host Configuration Protocol.

It 's job is to provide DHCP clients with IP addresses and other relevant information, for example, to provide the default gateway, the IP address, the DNS resolver and a hostname etcetera.

The DHCP server is able to offer IP addresses, to re-claim IP addresses and even to expire IP addresses.

There is a protocol called BOOTP, which is the protocol used to boot X workstations and other types of devices. Its job is to offer up an image for the workstation to boot.

Now DHCP and BOOTP are very similar protocols. They both offer similar services and in fact DHCP can service BOOTP requests.

The only difference is that BOOTP servers can't re-claim or expire IP's.

This means that DHCP has become the standard in dynamics of controlling of IP addresses.

Essentially, DHCP was developed to alleviate the problems that arose when assigning static IP addresses throughout a really large network. (If you have 5 hosts, it 's not a problem but if you've got 5000 hosts, it could be a problem and you might re-assign IP addresses and duplicate IP addresses and so on.)

One of the problems with DHCP is that, if the DHCP server is enclosed by routers on either side then this becomes the broadcast domain and the broadcast domain restricts DHCP requests to this subnetwork. This implies that clients wishing to obtain DHCP requests on the opposite side of the routers will not be capable of receiving them.

If another server on the network were to request a DHCP address it would only progress as far as the router at which point it would stop.

Well, if this is a Linux machine, there are some parameters in "sysctl" (System control) that would allow you to forward DHCP requests.

The exact parameter that one needs to specify is in "net/ipv4/conf/eth0/boot_relay", I've only got one Internet address, and you'll see if you do a "sysctl -a | grep bootp" that this parameter is currently set at zero:

debian:~# sysctl -a | grep bootp
net/ipv4/conf/eth0/bootp_relay = 0
net/ipv4/conf/lo/bootp_relay = 0
net/ipv4/conf/default/bootp_relay = 0
net/ipv4/conf/all/bootp_relay = 0
                

When we run the following command:

debian:~# echo "1" >/proc/sys/net/ipv4/conf/eth0/bootp_relay 
                

The Linux router will now be able to forward BOOTP requests, where before it stopped them, it will now forward them to the DHCP server and the DHCP server will respond.

The following screen shot is the result of running the "sysctl -a | grep bootp" command after running the "echo "1" >/proc/sys/net/ipv4/conf/eth0/bootp_relay" command.

 
debian:~# sysctl -a | grep bootp
net/ipv4/conf/eth0/bootp_relay = 1
net/ipv4/conf/lo/bootp_relay = 0
net/ipv4/conf/default/bootp_relay = 0
net/ipv4/conf/all/bootp_relay = 0
                

The process that we've just undergone where we've echoed "1" into the boot_relay field is a dynamic process, it 's an on-the-fly configuration.

To set that field permanently you should edit the file called "etc/sysctrl.conf".

I encourage you to go and read the man pages on sysctrl.conf with "man sysctrl 5" and reading that section will show you how to set up BOOTP relay.

On the client machine we need an application to request the DHCP service from the server. There are a couple of options, "dhclient" is one and "pump" is another.

The workings of DHCP client and pump are not that critical to understand in order to use them.

What is more important is how to set up your address to become statically or dynamically applied each time you restart your network.

In order to use DHCP to find an IP address every time you restart your interface you need to go back to your etc/network/interfaces file. In there you would put an "iface eth0 inet DHCP" which would cause your network to come up every time with a DHCP server provided valid IP address.

/etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo eth0
iface lo inet loopback

#mapping eth0
#       map WORK work-eth0

iface eth0 inet DHCP
        address 192.168.10.144
        netmask 255.255.255.0
        gateway address 192.168.10.1

                

When working with client/server technology, a DHCP server is inter-operable, so even if your DHCP server happens to be a Windows NT server and your client happens to be a Linux client, you will still get an IP address.

The server and the client are operating independently. As long as they stick to the same protocol, we will be able to get an IP address.

This interoperability is shown in that Linux is inter-operable with other alternatives, the DHCP servers could be a Solaris machine or any other type of Unix.

You will notice that at least one network connection is present on your system - the "lo" interface. This is the loopback interface and is common to all systems connected to a network. The loopback interface is a virtual interface and never goes down. It 's primary function is to allow the functioning of the TCP/IP stack on the OS without the presence of a network card.

The IP address assigned to the loopback address (lo) is 127.0.0.1 - a class A address. Try to do an echo test to the loopback interface using the ping command:

ping 127.0.0.1
                

You should get a response. Since this is a virtual interface, you have had to do nothing to ensure that it is up. Of course, just because the loopback interface is up does not mean you can begin talking to others on your local network. For that you need a real network card.

If you do not see an interface called "eth0", it probably means you have not loaded the drivers for your network card. If this is the case, you will need to determine what type of network card (and chip set) you have. It is out of the scope of the course to go into the details here. Instead check our Donald Beckers site - he did most of the coding of network drivers for Linux (http://www.scyld.com/network).

Once you have and interface, you can type:

ifconfig eth0
                

This will show you the Ethernet device 0 - the first network interface card. My output shows:

eth0      Link encap:Ethernet  HWaddr 00:01:03:8C:FB:01  
          inet addr:172.16.1.2  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4537 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4824 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:1822888 (1.7 Mb)  TX bytes:370681 (361.9 Kb)
          Interrupt:10 Base address:0xe800 
                

From this I can see the following:

the IP address on this card is 172.16.1.2 (inet addr)

the broadcast address 172.16.1.255 (Bcast),

the subnet mask, 255.255.255.0 (Mask),

the interface is up (UP and RUNNING),

it is a broadcast interface (BROADCAST), other technologies like token ring were not broadcast devices,

the maximum transmission unit (MTU) of 1500 bytes. This is the maximum for Ethernet, token ring has a higher MTU,

the number of hops to get to this interface (METRIC),

the number of packets transmitted (TX packets),

the number of packets received (RX packets),

the number of received and transmitted bytes ({RX,TX} bytes,

and finally, the interrupt consumed by this device as well as the base address.

The ifconfig command can be used for more than simply showing your network interface card information. It is also the tool you use to bring a network card up (make it active on the network), or to take it down (deactivate it). To activate and deactivate your network card you can:

ifconfig eth0 [up|down]
                

Additionally, you can change the network address on the fly as we discussed earlier. So here is the general syntax for the ifconfig command:

SYNTAX:
ifconfig interface [aftype] options | address ...
                

The options earlier were up or down, but ifconfig can additionally take an address:

ifconfig eth0 10.0.0.1
                

In the absence of other options such as "netmask" or "promisc", the interface is brought up with the address 10.0.0.1 and the standard class A subnet mask for the 10 network namely 255.0.0.0

Adding the word "netmask" allows us to define a network mask for this interface:

ifconfig eth0 10.0.0.1 netmask 255.255.255.0
                

Some of the less well-known things you can do with this command is change your hardware (MAC) address. Try this:

ifconfig eth0 down
ifconfig eth0 hw ether BA:D1:da:d1:20:04
ifconfig eth0 up
ifconfig eth0
                

Bingo, you've changed your hardware (MAC) address. (Bad Dad 2004!)

I've referred to dangers of setting these setting your IP address on-the-fly versus setting it statically. We will focus now on configuring the interface statically - in other words, through a reboot but not relying on a protocol such as DHCP to issue us an IP address.

As with everything in Linux, networking configuration is stored in a file. This time, it 's in /etc/network/interfaces. Typical entries will look as follows:

iface eth0	inet static
		address 192.168.0.10
		netmask 255.255.255.0
		gateway 192.168.0.1
                

This will configure the interface to the IP address 192.168.0.10, with the default gateway being 192.168.0.1 (we'll talk about the default gateway shortly). Assuming you had two interface cards in your hosts, the first using a static address and the second using a DHCP address, you could have two separate entries in the interfaces file as follows:

iface eth0	inet static
		address 192.168.0.10
		netmask 255.255.255.0
		gateway 192.168.0.1
iface eth1 inet DHCP
                

Note

on RedHat and SuSE things differ slightly. On both RedHat and SuSE there is not interfaces file in /etc/network. Everything lives in a directory /etc/sysconfig/network-scripts. Within this directory there are files named according to the interface you are configuring. In the above examples under RedHat and SuSE, there would be two file in the /etc/sysconfig/network-scripts directory namely ifcfg-eth0 and ifcfg-eth1. These files would contain information relating directly to the configuration of the interfaces. I've included the contents of a RedHat ifcfg-eth0 file below. For a dynamic IP configuration using DHCP: DEVICE=eth0 ONBOOT=yes BOOTPROTO=DHCP

Once you have set your IP address statically, it is always a good idea to test it out by forcing a network restart. In Debian, this is done using the ifup and ifdown scripts. These can be used by issuing them on the command line:

ifdown eth0; ifup eth0
                

This will stop and restart out interface. Naturally we would need to do this for every interface we have, so presumably we could get smart (or lazy) and write a loop that could do this for us:

    for i in `seq 0 1`
do
    ifdown eth$i;ifup eth$1
done
                

In fact Debian is a lot smarter than either of the commercial Linux distributions. If you use Debian you do not need to create a for loop like this one to restart your Network interfaces, but there is not time to delve into this here (for more information on magic network configuration, visit http://www.debian.org/doc/manuals/reference/ch-gateway.en.html#s-net-magic-reconf )

	Note
	if you don't understand this for-loop, hang in there and do the Shell Scripting course.

	Note
	In both RedHat and SuSE, the commands to stop and restart daemons/services differ. In RedHat, you would issue the command: service network restart SuSE, you would run: rcnetwork restart

At this point, our network interface is up and able to transmit and receive packets over the network. One of the ways of testing this is by getting a friend to "ping" your interface, assuming they are on the same network as you. Another means of testing the interface is by you "pinging" someone else on your network. I'll assume for now there is another host on your network with the IP address 192.168.0.45. Ping the host using:

ping 192.168.0.45
                

As long as you get a response from the host you are pinging, your network interface is up and A1 OK. We'll spend some time later in the course discussing ping as well as other tools that are invaluable in solving some network related problems.

Note

What response SHOULD you be getting back if everything is fine? I have included some output below from pinging my default gateway (172.16.1.1) on my network in my office: ping -c 5 172.16.1.1 PING 172.16.1.1 (172.16.1.1) from 172.16.1.20 : 56(84) bytes of data. 64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=0.334 ms 64 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=0.329 ms 64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=0.322 ms 64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=0.324 ms 64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=0.321 ms --- 172.16.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 3999ms rtt min/avg/max/mdev = 0.321/0.326/0.334/0.004 ms As you can see from the second-last line, 5 packets were transmitted and 5 packets were received, so there was no packet loss. We'll discuss troubleshooting your network in much more detail later in this course.

The final thing to deal with in this chapter is the default gateway. So, what 's the default gateway? This is the default route out of your network. Still do not understand? I know, now I'm not talking about routes! Well the concept of a route is actually quite simple. If I were to ask you which exit you would use when leaving the stadium after a scintillating cricket match, you would probably reply that you would leave by the exit closest to your seat. So, this would be the default gate on your way home - your default gate way. With IP packets, it is no different. The route (or path) they will follow to leave your network will go through a particular host - the default gateway. In other words, if the host you are trying to talk to (for email, web or other service) does not reside on your local network, your packets will be channeled (routed) to the default gateway.

Setting the default gateway is done using the "route" command. Without going into all the options of the route command, we could add a default route using the command:

route add default gw 192.168.0.1
                

Consult the route(8) manual pages for additional options. In this case, I'm adding the route to the gateway (or host) 192.168.0.1. It is the responsibility of this host to ensure that the packet is routed out of your network.

Again this is a dynamic setting, so we need to make it static using some configuration file. From our earlier discussions on configuration of the default gateway automatically, you simply have to add the gateway to the interfaces file (in /etc/network) in the form described above. On restarting the network interface, your default gateway is set, even across reboots. Once the default gateway is set, a simple stop an restart of the network interface will enable this.

	Note
	while stopping and restarting the interface is not essential since the same can be accomplished using the route command, you may well wish to restart the interface to ensure that all your dynamic settings have been written to files which will ensure things are honkey-dorey even after a reboot.

Note

In the early days of the Internet, people applied to the InterNIC for a legal IP address class. Often they were granted it, and promptly used it around their organizations. Later, when InterNIC realized there was a shortage of IP addresses due to the exponential growth of the Internet, they had to put some mechanisms in place to stem the tide of the use of class A, B and C addresses. One of the ways to do this was to ask organizations to move to "illegal" addresses within their organizations and return blocks of legal IP addresses back to InterNIC. This obviously required many organizations to go through an IP address reshuffle - a time consuming and costly process. DHCP helped to solve some of these problems.

In this part of the course, we merely configure the client, however, in the Advanced Networking Course, there is a more extensive coverage of configuring the DHCP server.

DHCP is a broadcast service. By this I mean that the client will broadcast a DHCP request and wait for an answer. Assuming there is a server that is listening for DHCP requests, it will reply. In general, if there is more than one DHCP server, the first to answer the DHCP request will supply the IP address to the client - which of course might not be quite what you want. DHCP can also supply other parameters to the client including the default gateway, the DNS server, the length of time the client is allowed to retain this address, and, if required, a boot image for the client.

In conclusion, configuration of the client is as simple as we've seen earlier in the notes. Simply supplying the relevant parameter to the /etc/network/interfaces will dynamically obtain the IP address. Client configuration occurs using one of three pieces of software, namely, pump, dhcp-client (of dhclient), or dhcpcd. In it 's default form, the client works properly in it 's unconfigured state, however these programs have a configuration file that allows tweaking of the system.

The process of exchanging email is based upon a number of different protocols, but at the heart of electronic email is the simple mail transport protocol (SMTP).

This protocol is based upon the connection-orientated TCP protocol and is certainly the most widely used email transport in the Internet today. When an email is sent between MTA's, SMTP is the protocol that these email servers "speak". SMTP is situated at the top of the TCP/IP stack - pretty much on top of TCP.

We will spend some time later conducting a conversation with an SMTP server. For now though, we have a little more groundwork to cover.

When I send a mail to joe@mailprompt.co.za, my MUA delivers the email to my local SMTP server.

The SMTP server (let 's call it smtp.QEDux.co.za) resolves the IP address of the mail server for mailprompt.co.za and attempts to contact that server on port 25 - which is the default SMTP port.

Note

The SMTP server is able to resolve the IP address for the mailprompt.co.za mailer using a special DNS record - the MX record in the DNS server for mailprompt.co.za. Although this point is out of the scope of this course, it is at least nice to know how one SMTP server is able to just "know" who the mail server is on the other side. In the DNS elective course you will learn how to use "dig" command to determine IP addresses for specific URL's, including how to use the MX records to determine the IP addresses of MTA's.

Once my SMTP server has made contact with mail.mailprompt.co.za (I'll assume this is the name of the mailprompt.co.za email server), it will begin transmitting the message to the remote side.

Only once the email has been completely and successfully sent, will the local MTA (my side) delete this email from the list of email's to be sent. Once deleted, my mailer marks this email as "delivered" while the receiving SMTP server has the responsibility of ensuring the mail is delivered to the recipient.

(Delivery is a topic that is dealt with later in this module.)

Since this is essentially a point-to-point service, it is highly unlikely that email can get lost en-route. Obviously mail does sometimes get mislaid, which proves that even with this "fail-safe" mechanism, snags can still plague it.

So, what does the 'conversation' between the two mail servers look like? I have included a sample conversation below.

Simply put, there are a number of commands a SMTP server understands. In this session, the commands HELO, MAIL FROM, RCPT TO, DATA and "." are all SMTP commands:

telnet smtp.uninetwork.co.za 25
Trying 168.210.56.254...
Connected to smtp.uninetwork.co.za.
Escape character is '^]'.
220 mail.uninetwork.co.za ESMTP
HELO QEDux.co.za
250 mail.uninetwork.co.za
MAIL FROM: hamish@QEDux.co.za
250 OK
RCPT TO: andrexxxxxxx@richemont.com
250 OK
DATA
354 go ahead
This is a test email Andre,
Please discard
Cheers
Hamish
.
250 OK 1079988036 qp 12140
                

Here I have simulated a simple conversation. You can do the same on your mail server, and you should achieve a similar result.

This same conversation happens for each piece of email routed through the Internet.

	Note
	I am not discussing how MS Exchange works as firstly I am not qualified to do so, and secondly these courses have nothing to do with Microsoft products.

When the email is delivered from the sending mail server, it has to be stored somewhere while time elapses until you, the user decides to retrieve it.

In general, most email servers store your email locally in a file or files on their hard disk drives.

Assuming then you are the client that will be reading your email, and you already have a login to the mail server, your email client will merely need to look inside the file(s) or inside the directory that stores the files.

There is another whole issue of what mailbox type you are using to store email, but we'll leave that until the advanced networking course where we actually configure a mail server.

For both Category 2 and 3, we will want to implement a retrieval protocol. Categories 2 and 3 are similar in many respects, but differ in the fact that in Category 3, you, the client have little to do with the organization offering the service.

A typical office environment (as is prevalent in many large corporate companies) is that describing Category 2, while a user that dials into their ISP to retrieve their email would be an example of Category 3. Of course these are not mutually exclusive, and one could implement both Categories in an environment.

In the case of Category 2, we do not want to log onto a separate machine in order to read our email.

Let 's make it a little more concrete. In the case of a large corporate, they may require that all their clients keep all email on a central server for the purposes of security, backups and the ability to roam around the office.

For this there is a protocol called the Internet Message Access Protocol or IMAP. IMAP is used in this scenario (office environment) since it encourages email to be stored on the server rather than an individual workstation client.

Thus, IMAP is a central point of storage of the email. Naturally, given this type of system, the system administrator will need to make the necessary arrangements to have the email backed up and will need to provide a good level of service delivery. You will not believe how fast users will moan if their email is not available.

The other method of email retrieval is that offered by the majority of ISP's.

ISP 's generally don't want to store your email permanently (perhaps they have limited storage capacity for all their clients to store email). As such, they are happy to store (for a very limited time) the email that arrives at their mail servers addressed to you, but as soon as you dial in to collect it, they expect you to take it away with you. They are usually not responsible for your mail once it is accessed by you (contrast with this, a corporate client who stored the email of everyone in the organization on a central email server).

Thus, in the ISP scenario, it makes little sense for the ISP to implement IMAP, since this implies our email will be stored in a central repository at the ISP - pretty pointless when you need to read something off-line.

Additionally, if the ISP has implemented IMAP, then when we do go online, all the messages will need to be downloaded to the client (in fact only the headers are downloaded with IMAP, the message body remains on the server until such time as it is accessed). This is a costly process in both time (you will be waiting for the email to download) and money (you will be paying phone charges while waiting - come to think of it, no wonder Telecoms companies are so wealthy!!). In this scenario, it may be wise to have a protocol that has the ability to pop the mail off the mail server and store it locally (on your machine) - enter the Post Office Protocol version 3 (POP3).

POP3 was designed to retrieve email from a mail server in "batch" mode and save it as files on the hard disk of the client machine. This system has the advantages in terms of time and money saved, as well as the ability to read your email anywhere, any time. However, the disadvantage is that if your hard disk fails (aka crashes), you loose all your email. But of course, you are a good system administrator and you have done adequate backups!

POP3 and IMAP are often bundled together in the same package. In this way, when you install a POP3 server, you get a free IMAP servers thrown in, or of course visa-versa. Now who said Linux was not good value for money!!!! POP3 and IMAP serve different purposes and it is wise to consider carefully what is required before offering one or the other. In general, MS Exchange is a modified IMAP type service.

POP3 and IMAP serve different purposes and it is wise to consider carefully what is required before offering one or the other. (In general, MS Exchange is a modified IMAP type service.)

In much the same way as we were able to walk through a SMTP conversation, we are able to walk through a POP3 and IMAP conversation. There are a variety of POP3 and IMAP commands, and we will look at some in the trouble shooting section later in this course.

Finally, POP and IMAP are inherently insecure. They send passwords unencrypted over the wire and are therefore prone to eavesdropping and packet sniffing. One method of solving this is by means of using certificates and implementing the secure sockets layer (SSL).

Thus in addition to POP3 and IMAP, there is POP3S and IMAPS and this will be covered in the advanced networking course when you configure a POP3 and IMAP server.

In conclusion then, when setting up an email client like Ximian's Evolution or Mutt, you need to supply an outgoing mail server (the SMTP server) as well as an incoming mail server (a POP3 or IMAP server). Once that is done, you should be able to send and receive email.

It is also worth noting that, on the whole, outgoing SMTP servers do not usually require that you authenticate in order to send email, while naturally incoming POP3 and IMAP servers will require one form of authentication.

The Internet has grown uncontrollably over the past 10 years, and with that has grown the ability to communicate with people that you have never met - and often will never meet.

This has resulted in a number of fundamental security issues:

In the virtual world, I may well claim to be John Cleese. The question is how can the recipients of my email verify whether I am John Cleese or not?

A not unrelated question is how the recipient knows this message really came from you. This is where GNU Privacy Guard comes into play. GPG is an open source implementation of PGP (Pretty Good Privacy). Since PGP is proprietary and not open to public scrutiny, it cannot, and should not, be used without purchasing it. In response to not being able to use PGP without having licensing issues, GPG was developed.

Transmitting a message from one mail server to another over thousands of kilometers to places I never even knew existed, poses the problem of whether someone or something in between the source and destination has intercepted the email, modified it and sent it on to the recipient. Neither I, nor the recipient, would have any idea that the email had been modified until I received a message in reply from the receiver.

Finally, given the nature of communication today, we all require some degree of privacy and knowing that someone could intercept your email's and read them (even if they don't wish to cause any damage) is a little disconcerting. I certainly would not like everyone to have access to every letter that arrived in my post box at home. We need some means of encrypting sensitive email's.

Data encryption can be categorized broadly into:

a) the use of symmetric keys and

b) public/private key infrastructure (PKI).

In this case, although you don't need to decrypt the email, you will want to check that it was me who sent it.

Signing is slightly different to encrypting. Put differently:

"A major benefit of public key cryptography is that it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information 's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information." - Introduction to Cryptography

In order the achieve this signature, I would sign an email or a document with my private key.

The recipient would merely receive the signed email and check it against my public key. If they match, bingo, the email could only have originated from me.

Setting up the PKI is slow sometimes waiting from 1 to 5 minutes while an email is signed.

Clearly, we need a faster mechanism.

Here we can introduce the concept of "one-way hashing", take a document, email or a piece of text. I hash it, and this produces a "short" number. If the original document is changed (even by a single letter), the resulting hash will be a completely different number.

Let 's bring this all back to a real-world application. Suppose I have an email that is of no real value to require that it be encrypted. For example, I may be wanting to send my family an email with my intended arrival time on an international flight. I do want them to know that the email was from me, so I wish to sign it. My email client will generate a one-way hash creating a unique string from the contents of this email. This string is known as a message digest. It ensures that the recipient knows the email has not been changed since it was sent.

However, we still need to encrypt the message digest.

Why? Well if you give this just a little thought, you will realize that an eavesdropper could easily intercept this email. Change the contents and re-hash it, attaching the new hash to the email. My family would receive it, check that the hashes match (which they do since the modified document was rehashed), and would assume that the document was the one sent by me. Of course this is not so, and so our signing did not work.

If I encrypt the hash using my private key, then the receiver could use my public key decrypt the hash, rehash to original plain text email and compare the hashes. If they match, there can be no doubt that

a) the message has not changed since I sent it, and

b) it was in fact me that sent it.

I hear you ask whether the attacker (eavesdropper) couldn't just use my public key to decrypt the hash, change the document and rehash as before, and then forward the modified document to the recipient?

They could indeed do that, but signing a document involves both the hash as well as encrypting the hash.

This is the part where they (the eavesdropper) would need my private key, which of course they don't have. So, the recipient would know the email was not from me and would therefore not trust it.

Again, in summary, while encryption is done using the recipient's public key (Ed:decryption is done by the recipient, using the public key that you have sent him which corresponds to your private key CHECK), signing is done using your private key.

Back to reality?

Let 's get down to some practical applications of keys.

GNU Privacy Guard or GPG, is the package that we will use to sign and encrypt data. Like any system, the efficacy of the system is as good as the people who manage it.

If your operating system is insecure and others can obtain your private key, then the system will break down.

If on the other hand, you never check a person 's public key - (i.e. That is really belongs to that person), then the system will break too.

So the system is as good as the people are vigilant.

We need to generate our public/private keys, and for this we will use the "apg" command.

The "gpg" utility has a number of switches, one of which is to generate the key:

gpg --gen-key

If you have not run this before, it will generate an error because the relevant working directories have not been created. Running the program the first time will create the directories.

You will need to run it again to begin key generation.

Now, it will ask what type of cipher you wish to use. In general, you can choose the default.

Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) (5) RSA (sign only)

Then, choose the number of bits for the DSA key. The default should be fine here too.

Naturally, the higher the number of bits, the more difficult is will be to crack, but for now, 1024 should be OK. ^[6]

I suggest that you never expire your GPG key (option 0 in the menu).

Now you're ready to enter your personal details - your name, a comment and your email address. Mine would be:

Real name: hambo Email address: hambo@QEDux.co.za Comment: Hambo the Sambo

Once you're happy with these details, choose OK.

Now comes the rub. You need to enter a pass phrase. This should be enough of a phrase that it is not easily crackable. Note that this is not a password. It wants a phrase. "The cat sat on the mat" would be such a phrase ummm, perhaps that 's more of a clause (-;

All the principles of a good passwords apply to a pass phrase. Remember that you will need to type this phrase each time you wish to sign, encrypt anything.

Generation of your public and private keys begins. Read the output as its happening, as sometimes it requires that you move the mouse around to generate more random numbers.

Finally, the keys are produced and you can sit back at this point and smirk at your ingenuity! I've included my output here.

gpg: /home/hamish/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. key marked as ultimately trusted. pub 1024D/A6B68161 2004-03-28 hambo (Hambo the Sambo) \ <hambo@QEDux.co.za> Key fingerprint = 6CAF EBE7 1299 CB3E B293 D729 20FA \ 26C7 A6B6 8161 sub 1024g/22CA1FAD 2004-03-28

	Note
	This is just an example. My real public key is available from my website www.QEDux.co.za

Now that you've generated your public/private key pair, ensure that the .gnupg directory is well and truly secured.

ls -ald .gnupg drwx------ 2 hamish users 4096 Mar 28 14:28 .gnupg

Notice that only the owner (hamish) has access to this entire directory.

ls -al .gnupg total 36 drwx------ 2 hamish users 4096 Mar 28 14:28 . drwx------ 41 hamish users 8192 Mar 28 13:59 .. -rw-r--r-- 1 hamish users 7793 Mar 28 13:59 options -rw-r--r-- 1 hamish users 909 Mar 28 14:28 pubring.gpg -rw-r--r-- 1 hamish users 0 Mar 28 14:01 pubring.gpg~ -rw------- 1 hamish users 600 Mar 28 14:28 random_seed -rw------- 1 hamish users 1367 Mar 28 14:28 secring.gpg -rw-r--r-- 1 hamish users 1240 Mar 28 14:28 trustdb.gpg

Here the secure (private key) is "secring.gpg". It has permissions of read and write, but only for the owner (hamish). The "pubring.gpg" (and that is not the ring for the last round either;-), is the public key.

You still need to "export" the public key so that others may download it and import it onto their keyring.

This can be done with:

gpg -a --export hambo > hambo.asc.pubkey
                

Take a look at the resulting output. This key can now be emailed to your friends, or put on your website or included in the NIS map for your site to make it available to others.

Now, since you will probably be working on a single machine when doing this and not in an environment that you can swap keys with others, you will need to create a second user on your machine and pretend that this user and yourself are swapping your keys.

Once you've exported and imported each other's keys, we can begin talking about signing each others keys. So, at this point, you need to complete the exercises.

Once you have the public key of someone else, import it using:

gpg -import hambo.asc.pubkey
                

It is no use obtaining someone 's key without first verifying that the key belongs to them.

There are many methods of doing this, but probably the easiest one (for now) is to check their fingerprint, call them up and verify it.

gpg -fingerprint hambo
gpg -fingerprint sam
                

These commands should do it. Ensure that you and Sam read your fingerprints out to one another.

If the fingerprints don't match, you can simply delete the key and begin again. If they do match, then you will want to sign their key.

That raises the last concept of this signing and encrypting section.

In an organization, you soon get to know those individuals that spread rumors. Can these people be trusted with a secret you want to share with them? There are others however that, no matter how important the secret is, they will simply never tell another soul without your permission.

So it is with public keys. Suppose I have exchanged public keys with Sam. I know Sam is a complete stickler for detail and checks and rechecks each key on his keyring before signing it. Now Mary sends me her key and this key has been signed by Sam. Sam trusts Mary ultimately (because Mary is also vigilant about her keys). Even though I don't know Mary (she happens to be a friend of Sam's), can I trust her key? Yes, because it has been signed by Sam.

Jakes on the other hand is a little less reliable. Sam has sent me Jake's key, but he's been known to sign keys without properly verifying the signatures. Can I trust signed documents from Jakes? Well, I may trust them partially, but in order to completely trust anything from Jakes, I would probably want to verify the key from another source too. If the other source verifies the signature is valid, only then can I trust it.

This process of trust is known as the web of trust. When listing a uid (a users ID) with "edit-key", there is a "trust" section that determines:

a)the level of trust you have in the person from whom you have received the key

b)the validity of the key - did you verify their fingerprint?

Examples may be:

trust m/f
                

Person XYZ is trusted marginally (m), but a full (f) verification of their fingerprint has been done.

From the gpg(1) man page, the following trusts are documented:

Signing keys is imperative since it increases the web of trust. ^[7]

This is a relatively involved subject and one that takes time to assimilate.

In sum then, digital signatures, hashing and public/private and symmetric keys ensure that:

1.You are who you say you are, and that this message really come from you (digital signatures)

2.You are able to keep messages from being tampered with during their transmission (hashing)

3.You are able to keep messages secret (encryption) - only to be viewed by individuals for whom they are intended

The first and certainly the oldest is our host file and that lives in /etc/hosts, and this is a very primitive name to IP address look-up mechanism.

A host file would look similar to:

riaan@debian:~> cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts

168.210.56.151   linux.local     debian

                

A little word of warning, if you don't put the fully qualified domain name as the first entry in the file, then when you try and access a host name on your machine, you will not get a fully qualified domain.

The first thing in your host file should be your fully qualified domain name and every other entry in your host file can be an alien. If I want my machine to also be called Hamish or Linux1, I can add it to my host file and in fact you can add any number of entries to your host file.

You are not restricted to just a single entry.

Names can also be looked up in the DNS name servers.

Host names can also be look up by using the NIS service (Network Information Service).

NIS's job is to have a central repository of network services. The host's file is a network service so NIS can distribute the host's file to a whole bunch of different machines on the network.

We'll talk about NIS later.

The danger of having so many places of looking hosts up is which one does it use?

Well, for that you have a file called /etc/nsswitch.conf and this file dictates how a name is looked up.

It's the Name Service Switch file and if you edit that file you'll see entries that are enabled as follows: the password for example comes from file or it might be 'compat' which means that it's compatible and it comes from file.

There are hosts, which come from file but it can also come from DNS. Networks for example, might come first from file and then from NIS and then from DNS and then from NIS+.

debian:/etc# cat nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          dns files
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
                

This file defines the order in which hosts will be looked up, they are firstly looked up in file, in other words, in /etc/host and only after that, they will be looked up in DNS.

In fact in the example above the hosts will never be looked up because DNS would be used before the /etc/hosts file

Now if we wanted our host to first be looked up in DNS we could obviously switch the entries around.

Firstly we need to determine if is it a DNS problem?

One of the quickest ways of doing that is to PING one of the addresses. So if we PING www.QEDux.co.za and we get no response - that's one thing (maybe your network is not connected to the Internet). If you have access to the Internet then it is possible that "ping" cannot access a DNS service to determine which IP address it needs to send a packet to. ("ping" uses "dig" to determine the IP address of a host, before it starts sending echo requests to the host).

We might also try "host www.QEDux.co.za" and if it cannot resolve the name into an IP address then we know that there might well be a DNS fault.

Another way of testing is to do an "arp -a". If the "arp -a" takes some time to return, it probably means it's trying to do a DNS look-up and that might be an indication that we have the DNS problem.

Lastly then, we can use our trusty dig. If we say "dig www.QEDux.co.za" we should get a response from our DNS server to tell us exactly what the IP address for www.QEDux.co.za is.

If you look at dig you can see that it gives us the question section and the answer section and it also tells us how long it took to answer that question. In my case, it took 39ms to answer the question, which probably means our DNS server, locally, is performing fine. If it took a long time this would indicate an issue or problem with the DNS Server.

debian:~> dig qedux.co.za

; <<>> DiG 9.2.2 <<>> qedux.co.za
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38401
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;qedux.co.za.                   IN      A

;; ANSWER SECTION:
qedux.co.za.            86170   IN      A       196.25.102.2

;; Query time: 4 msec
;; SERVER: 196.14.187.146#53(196.14.187.146)
;; WHEN: Thu Mar 11 10:58:41 2004
;; MSG SIZE  rcvd: 45

                

debian:~> host qedux.co.za
qedux.co.za has address 196.25.102.2
debian:~>
                

Another thing to check when you are trying to resolve DNS issues is to check in which order your DNS is looked up.

A possible scenario is that it is first looked up in files (like /etc/hosts) and then NIS and then DNS.

In the exercises you would need to go and remove the DNS out of your nsswitch.conf to see whether it is able to resolve your IP address.

You can use "nslookup" to check the DNS.

linux:~ # nslookup
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  
Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
> qedux.co.za
Server:         196.14.187.146
Address:        196.14.187.146#53

Non-authoritative answer:
Name:   qedux.co.za
Address: 196.25.102.2
                

If I try and look up www.ananzi.co.za it shows me that ananzi.co.za has the IP address 196.4.90.16 - it also tells me that this is a non-authoritative answer from the server and in my case, the server is my DNS server, locally.

debian:~> nslookup
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead. 
Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
> www.ananzi.co.za
Server:         196.14.187.146
Address:        196.14.187.146#53

Non-authoritative answer:
Name:   www.ananzi.co.za
Address: 196.4.90.16
                

I can request to use a different DNS server if I edit my resolve.conf.

I've now changed my DNS server to use a different DNS server and now when I do an nslookup on mail.goodle.com its using a different DNS server.

"nslookup" is one of the ways to look things up. I'm not going to dwell on it, its being replaced by dig so I want to spend a bit more time looking at dig.

Once we have established that a Windows machine has some worthwhile stuff to share, it might be nice to have that available at our fingertips each time we use our Linux machine. Perhaps the Windows server is sharing music, or video, or perhaps better still, a software repository. Smbclient has it's uses, but it might be undesirable to transfer this information back and forth as we find a use for it. In this case, a simple answer is to mount these drives on the Linux host as we would any other drive. This is simple to achieve - and works in a fairly similar fashion to what NFS might in an all UNIX environment.

smbmount \\\\172.16.1.3\\c$ /mnt/thumb -o username=jwhittal
                

This time, the smbmount command takes the share name, a mount point (/mnt/thumb in my example above) and finally some options. Clearly, since C$ is not a guest based share (and so it should not be), I will need to supply a username for the share. I will be prompted for the password for the user "jwhittal". Since this 'drive' is now mounted, we can begin copying information to and from the mount point. Clearly, this implies that it is being copied to the Windows server. One might additionally place this in the /etc/fstab file on your Linux client workstation and therefore have the Windows share reloaded on every reboot of the Linux client workstation.

Smbumount is the command used to unmount the Windows share. In fact, smbmount and smbumount are just synonyms for the mount and umount commands in Linux. An alternative to the smbmount command above is:

mount -t smbfs -o username=jwhittal \\\\172.16.1.3\\c$ /mnt/thumb
                

Clearly, this would require that the smbfs module is compiled into the kernel and that it is able to mount SAMBA file systems.

nmblookup is a command that can be used to do a number of meaningful operations. In the example below, it shows us that this workstation is the master browser for this workgroup, that this machine is a member of the workgroup domain "WORKGROUP", and that the user who is currently logged into this workstation is "jwhittal".

nmblookup -A 172.16.1.3
Looking up status of 172.16.1.3
	006097EFC730    <00> -         B <ACTIVE> 
	WORKGROUP       <00> - <GROUP> B <ACTIVE> 
	006097EFC730    <20> -         B <ACTIVE> 
	006097EFC730    <03> -         B <ACTIVE> 
	WORKGROUP       <1e> - <GROUP> B <ACTIVE> 
	WORKGROUP       <1d> -         B <ACTIVE> 
	..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> 
	JWHITTAL        <03> -         B <ACTIVE> 
                

In the example below, the -M option indicates which machines are eligible to be master browsers on the network.

nmblookup -M -- -
querying __MSBROWSE__ on 172.16.1.255
172.16.1.3 __MSBROWSE__<01>
172.16.1.1 __MSBROWSE__<01>
                

This is a useful command when you require your Windows system to be backed up to a Linux/UNIX client machine with a tape drive. Smbtar will tar the data to the tape that is on the Linux/UNIX system.

This, in a nutshell, is a summary of some of the SAMBA client utilities. They not only allow a Linux machine to operate seamlessly with other hosts on the network, but they offer the ability to treat Windows shares as something akin to NFS in Linux. Thus, it becomes a simple operation to work in an all-Windows environment.

If that device is alive, it will send an echo reply back.

Now this is probably one of the most important commands that you'll use with troubleshooting but often switches put very low priority on "ping packets" and so what can and often does happen is that the ping packets get blocked even though they are a valid packet, and even though there is a reply from PING the packets get dropped.

Nevertheless, let's not concern ourselves with what modern technology is doing, the issue is that there's a request sent by yourself to a device on the network and that device, if it's alive, if it's up, it routes an echo reply.

If I just leave the PING running it tells us a good number of things.

riaan@debian:~> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.411 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.369 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.375 ms
...
                

Firstly, it tells us that 64 bytes were sent and that 64 bytes were received. And if we look at this, the 64 bytes that were sent was the echo request and the 64 bytes received was the echo reply. The second thing it tells us is that you've got a reply from the client or from the device being pinged.

riaan@debian:~> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.411 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.369 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.375 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=0.383 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=255 time=0.378 ms

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.369/0.383/0.411/0.019 ms
riaan@debian:~>
                    

If you run the command "ping -c10" to the opposite workstation, ping sends 10 x 64 byte packets and then stops. (Take note of the statistics for this transmission.)

This can be quite useful when we need to do troubleshooting.

To further this example, let us send a 5 packet transmission -we know that the maximum transmission unit for Ethernet is 1500 bytes, so if we sent a packet of 2400 bytes that would really mean that every packet has to be split up. This time I'm going to send a packet with size of 2400 bytes and you'll see it sends that packet size of 2408, an extra 8 bytes because of headers.

If you then compare the report from sending a packet size of 64 bytes and one of 2400 bytes you will see a difference in speed with which it can transmit large packets.

In my case, the average time went up from 0.1ms to 1.2ms to transmit a large packet size.

There are other options that can be used with ping; you could for example ping every 10 seconds instead of every second.

riaan@debian:~> ping -help
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
            [-M mtu discovery hint] [-S sndbuf]
            [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

riaan@linux:~> ping -i10 -c10 -s 2400 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 2400(2428) bytes of data.
2408 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=6.02 ms
2408 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=4.93 ms
2408 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=4.90 ms
2408 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=4.92 ms
2408 bytes from 192.168.1.1: icmp_seq=5 ttl=255 time=4.92 ms
2408 bytes from 192.168.1.1: icmp_seq=6 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=7 ttl=255 time=4.93 ms
2408 bytes from 192.168.1.1: icmp_seq=8 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=9 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=10 ttl=255 time=4.92 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 90009ms
rtt min/avg/max/mdev = 4.905/5.031/6.023/0.343 ms
riaan@debian:~>
                

Essentially there are 2 types of things that would happen when we ping something.

1.We could ping the device and get a response

2.or we would not be able to ping it at all, getting no response. In this case the device would not know how to get back to us.

Ping uses a protocol called ICMP protocol (Internet Control Message Protocol) for in fact this protocol has any number of responses.

Some examples of ICMP messages would be:

"destination host is unreachable"

Respond with nothing at all

"ICMP re-direct"

ICMP time-outs if the device is not responding.

So ICMP can provide a whole number of responses depending on the state of the device it is attempting to reach.

If we try and PING something that's not available we will get no response whatsoever, and this could then mean that the device is down.

If we try and PING a device we might get an ICMP re-direct, in other words, the PING responses don't go to that particular machine, they get re-directed to some other machine.

A firewall is a router-like device that exists between a trusted network and an untrusted network.

A typical example of an untrusted network is the Internet.

A typical example of a trusted network is your own internal network. Although this is not quite strictly true because most internal networks have been shown to be a source of a lot of security breaches, certainly more breaches than with the Internet.

A firewall is the mechanism that control access in and out of your network.

Almost every network that can be connected to the Internet is restricted through the use of a firewall and that generally blocks people from logging in and doesn't have to block people logging out.

So anybody logging in from the Internet to the Intranet will be blocked at the firewall, people trying to leave via the web browser to surf the net will generally be allowed through the firewall.

A firewall is a packet based device and what that means is that every packet is looked at, considered, weighed up and if meeting the required criteria may be passed through the network.

Many companies believe or have been lead to believe that having a firewall is the beginning and the end of their security set up. In fact, a firewall is only the tip of the iceberg although it is essential because it does block the gremlins from coming in from the outside in many cases.

Certain protocols like ICR for example, are blocked at the firewall whereas HTTP, SMTP (mail) and FTP might well be allowed through.

Protocols that would be blocked from coming in are things like pingsweep or just pings in general, because there's a whole wad of problems that can occur on the network if one allows a ping enter onto your network.

Firewalls offer a degree of protection from the Internet or from an untrusted network.

Often the internal network may have an illegal class address, for example 010.0.1.X, but of course the Internet can only cope with valid addresses, for example 196.7.14.X. As a result, the firewall does a process called NAT, Network Address Translation, where it will translate between the illegal internal address and the legal external address.

This is one of the ways that they've managed to overt the crisis of running out of version 4 (IPv4) IP addresses. Big companies have given back huge stocks of ip addresses for use on the Internet. They use NAT to translate their illegal IP addresses they use on their Intranet to those used in the Internet.

On a Linux machine, Linux can act as both a firewall and a NAT filter and it can also provide all sorts of services like http, sftp and ssh etcetera.

What services is your Linux box providing right now?

root@debian:/etc# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address   State
tcp        0      0 *:printer              		*:*                     LISTEN
tcp        0      0 *:1011              	   	*:*                     LISTEN
tcp        0      0 *:2049              	    	*:*                     LISTEN
tcp        0      0 *:www                   		*:*   	             LISTEN
tcp        0      0 *:webcache              		*:*                     LISTEN
tcp        0      0 *:3128                  		*:*                     LISTEN
tcp        0      0 *:ssh                   		*:*                     LISTEN
tcp        0      0 *:netbios-ssn           		*:*                     LISTEN
tcp        0      0 *:nntp                  		*:*                     LISTEN
tcp        0      0 *:1025                	  	*:*                     LISTEN
tcp        0      0 *:auth                  		*:*                     LISTEN
tcp        0      0 *:smtp                  		*:*                     LISTEN
tcp        0      0 *:ftp                   		*:*                     LISTEN
tcp        0      0 *:telnet                		*:*                     LISTEN
tcp        0      0 *:daytime               		*:*                     LISTEN
tcp        0      0 *:discard               		*:*                     LISTEN
tcp        0      0 *:1024                  		*:*                     LISTEN
tcp        0      0 localhost:953           		*:*                     LISTEN
tcp        0      0 debian.zoo.org.za:domain 	*:*                     LISTEN
tcp        0      0 localhost:domain        		*:*                     LISTEN
tcp        0      0 *:sunrpc                		*:*                     LISTEN
udp       0      0 *:1008                  		*:*
udp       0      0 *:2049                  		*:*
udp       0      0 *:icpv2                 		*:*
udp       0      0 debian.zoo.o:netbios-dgm *:*
udp       0      0 debian.zoo.or:netbios-ns 	*:*
udp       0      0 *:netbios-dgm           	*:*
udp       0      0 *:netbios-ns            		*:*
udp       0      0 *:ntalk                 		*:*
udp       0      0 *:talk                  		*:*
udp       0      0 *:discard               		*:*
udp       0      0 *:1026                  		*:*
udp       0      0 localhost:921           		*:*
udp       0      0 *:1025                  		*:*
udp       0      0 *:791                   		*:*
udp       0      0 *:1024    			*:*
udp       0      0 debian.zoo.org.za:domain *:*
udp       0      0 localhost:domain        	*:*
udp       0      0 *:sunrpc                		*:*
raw        0      0 *:icmp                  		*:*                     7
raw       0	     0 *:tcp                   		*:*                     7
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node 	Path
unix  0      [ ACC ]     STREAM     LISTENING     184  	/var/run/news/nntpin
unix  0      [ ACC ]     STREAM     LISTENING     327   	/tmp/.gdm_socket
unix  0      [ ACC ]     STREAM     LISTENING     234    	/tmp/.font-unix/fs7100
unix  0      [ ACC ]     STREAM     LISTENING     53122  	/dev/printer
root@debian:/etc#
                    

root@debian:/etc# cat inetd.conf
# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Lines starting with "#:LABEL:" or \
                        "#<off>#" should not
# be changed unless you know what you are doing!
#
# If you want to disable an entry so it isn't touched during
# package updates just comment it out with a single \
                        '#' character.
#
# Packages should modify this file by using update-inetd(8)
#
# <service_name> <sock_type> <proto> \
                        <flags> <user> \
                        <server_path> <args>
#
#:INTERNAL: Internal services
#echo           stream  tcp     nowait  root    internal
#echo           dgram   udp     wait    root    internal
#chargen        stream  tcp     nowait  root    internal
#chargen        dgram   udp     wait    root    internal
discard         stream  tcp     nowait  root    internal
discard         dgram   udp     wait    root    internal
daytime         stream  tcp     nowait  root    internal
#daytime        dgram   udp     wait    root    internal
#time           stream  tcp     nowait  root    internal
#time           dgram   udp     wait    root    internal

#:STANDARD: These are standard services.
telnet          stream  tcp     nowait  telnetd.telnetd \
                        /usr/sbin/tcpd  
	/usr/sbin/in.telnetd
ftp             stream  tcp     nowait  root   \
                        /usr/sbin/tcpd  
	/usr/sbin/in.ftpd

#:BSD: Shell, login, exec and talk are BSD protocols.
talk            dgram   udp     wait    nobody.tty      
	/usr/sbin/in.talkd      in.talkd
ntalk           dgram   udp     wait    nobody.tty     
	/usr/sbin/in.ntalkd     in.ntalkd

#:MAIL: Mail, news and uucp services.
smtp            stream  tcp     nowait  mail   \
                        /usr/sbin/exim exim -bs
#pop-3          stream  tcp     nowait  root   \
                        /usr/sbin/tcpd  
	/usr/sbin/in.qpopper -f \
                        /etc/qpopper.conf
#imap2  stream  tcp     nowait        root   \
                        /usr/sbin/tcpd  \
                        /usr/sbin/imapd
#imap3  stream  tcp     nowait        root   \
                        /usr/sbin/tcpd  /usr/sbin/imapd

#:INFO: Info services
ident           stream  tcp     wait    identd  \
                        /usr/sbin/identd        identd
#finger         stream  tcp     nowait  nobody  \
                        /usr/sbin/tcpd 
	/usr/sbin/in.fingerd

#:BOOT: Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."

#:RPC: RPC based services

#:HAM-RADIO: amateur-radio services

#:OTHER: Other services
#<off># netbios-ns      dgram   udp     wait    root    
	/usr/sbin/tcpd  /usr/sbin/nmbd -a
#<off># netbios-ssn     stream  tcp     nowait  root   
	/usr/sbin/tcpd  /usr/sbin/smbd
#<off># swat            stream  tcp     nowait.400      root    
	/usr/sbin/tcpd  /usr/sbin/swat
391002/1-2 stream rpc/tcp wait root /usr/sbin/famd fam

root@debian:/etc#
                    

TCP wrappers are an important part of securing your hosts. Thus, they are a complete chapter on their own.

Inetd is controlled by the /etc/inetd.conf file. Services such as telnet, finger, bootp and others are started from the superdaemon. Placing a comment (#) in front of the relevant entry in the inetd.conf file will stop this service. In so doing, root will need to send a signal to the inetd daemon to ensure that is re-reads it's configuration file and stops/starts the relevant services. Disabling inetd services can be simply enabled or disabled using the update-inetd command in Debian and the chkconfig command in the commercial distro's.

Xinetd is similarly controlled using a global configuration file (/etc/xinetd.conf). In addition however, each service has an entry in the /etc/xinetd.d/ directory. Entries are a little more complex than their inetd counterparts, but with a quick glance over the files in this directory, the astute reader will quickly discover their syntax and how to enable or disable services. The advantage that xinetd has over it's older counterpart is that services can be configured in more complex and restrictive ways. Simply put though, it is evident that the system administrator should disable all unnecessary services on the server prior to deployment.

Using both the chkconfig command (in SuSE, RedHat, Fedora or Mandrake), or the update-inetd command in Debian will automatically restart the superdaemon. Modifying the /etc/inetd.conf or /etc/xinetd.d/<file to modify> will require that we send a SIGHUP (-1) signal to the superdaemon.

An application called nmap is useful for checking what services are running on a system. Running the command:

nmap <ip address>
                

on the IP address of the server will show what services are currently enabled. Output from an nmap to my server shows the following output:

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-22 08:28 SAST
Interesting ports on mtnkiosk (127.0.0.1):
(The 1654 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
972/tcp  open  unknown
2049/tcp open  nfs

Nmap run completed -- 1 IP address (1 host up) scanned in 0.988 seconds
                

Once all unnecessary services are removed or disabled, we can begin to address issues of connection to our host. Without implementing a firewall, both xinetd (the older inetd is far more permissive and is not able to control security of the services running to the same degree as it's younger cousin xinetd) and tcp-wrappers give us the ability to control who has access to our services.

NIS is a hierarchical system of servers. At the top of the hierarchy is the NIS master server. This is the "authoritative" server for the NIS domain.

What is a domain? Well in any organization there may be a number of domains based upon the department one is in, or the seniority in the company, Etc. These are "human" domains.NIS domains are similar. There may be an "ENG" domain for the engineers, a MGMT domain for the management people, and an "ACCT" domain for the accounting people.

The NIS master server has a number of slave servers too. Their jobs are to act as backups to the master servers. If there is a problem with the master, then the slaves will stand in. In addition, a single master server may become inundated by the amount of requests it receives. So clients will be configured to point to the slave servers instead. Therefore, the master will have MUCH less work to do.

However, let's consider NIS, how it works and how to configure it from the client. How do we connect to a NIS server?

There are a number of methods as with everything in Linux. The easiest is probably to run the client configuration utility "authconfig". This will ask you to enter your NIS server as well as your NIS domain. Once done, it will try to start the NIS client. The client is called "ypbind", and if the domain or the server is unavailable, it will give up after a couple of seconds.

The authconfig file modifies a file in /etc called yp.conf. The format of this file can be found in the manual page of ypbind (man 8 ypbind), but here is a brief summary with an example of two:

domain nisdomain server hostname e.g.

domain QEDux server 192.168.1.2
                

domain nisdomain broadcast e.g.

domain QEDux broadcast
                

Then a restart of the ypbind should see you right.

Now, how do we know we are connected? The "domainname" command will return the domain to which we are currently connected.

$ domainname
                

returns,

QEDux
                

(Or whatever your domain name is.)

	Note
	to see the DNS domain name, one needs to use the command "dnsdomainname" rather than just "domainname"

The last thing that needs configuration is the /etc/nsswitch.conf. Remember, this file determines in which order things are looked up. The general order for many things is first FILES, then DNS, then NIS and NISPLUS. Supposing the NIS server has exported their /etc/networks file. To look this up using NIS first, we would need to change the entry in the nsswitch.conf as follows:

networks:   nis files
                

Now, the network information will be looked up first in NIS and then in FILES. Notice too that if the NIS is unavailable, then networks entries will ONLY be looked up in files.

Did this work? Well the way to see that is to run the netstat command.

netstat -r
                

Notice I ommitted the 'n' switch. That would have got me only the numbers, I want the names of the networks too. These names are coming from the NIS server.

I've cited the use in the networks file, or for obtaining an up-to-date list of the public keys of people on you network, but this all seems rather trivial. One of the places NIS is most useful is in the management of user accounts.

Image for a minute you have 100 Linux machines in your environment and each has to have 50 user accounts. I can see you grimacing already! Enter NIS and bingo, we can administer all 50 users, on all 100 machines from a single NIS master server. Simple, efficient and easy. No mess, no fuss.

Linux offers a system for sharing disk space between hosts called the Network File System. NIS or the Network Information Service is a systems of providing information to hosts on the network.

It is a hierarchical system based upon a master-slave configuration. While it is not essential, it beats having to make copies of common files for each user on the system.

The downside of NIS and NFS is that these products are not available to non-Unix based clients so if you are running Windows on your desktop, you can't use NIS to authenticate your Windows desktop back to your Linux server.

While this may seem a problem in Windows heavy environments, is not since you can use LDAP- Light Weight Directory Access Protocol. This is out of the scope of this course but LDAP allows you a way of authenticating users across different platforms.

Let us review the public and private key infrastructure, which we did look at earlier when we were talking about GPG.

Do not become confused between GPG and SSH:

GPG uses public and private key to encrypt and sign email's. SSH uses public and private keys to verify who you are.

Essentially the purpose is similar but these two are not the same.

Connecting to a remote machine and signing an email is very different processes. Secure Shell needs a public and private key pair just as GPG does.

Now in terms of secure shell and public and private key infrastructure, similar as GPG, you have things like RSA and DSA encryption algorithms. And RSA seems to be the favored option for creating key pairs. You also need a length of a key. So for example the length of the key could be 1024 bits. What this creates for us is a public key, which we can exchange with any other systems. And a private key that would remain private on our machine under all circumstances, you should not share it.

And in order to create the key pair we needed to supply a pass phrase.

So understanding the facts that we have a public key that we can share and a private key that we keep private at all costs and use as needed. And really what is happening at the OS level is that on our machine we have our private key and on the remote machine we have our public and we encrypt with our private key, which can only be decrypted with our public key. Now you will recall with GPG we could encrypt and sign, here there is no real signing involved, here it is more focused on encrypting the data we send and receive over the network.

The first thing we need to do is to create our public private key pairs using an application called ssh-keygen.

"ssh-keygen" takes a number of parameters so you need to, at this stage, log-in as an user.

Once logged in, issue the ssh-keygen command as expressed below:

1.Using the"-t" option generate a RSA key.

2.How big is my key going to be? 1024 bits it asks if we generate the key (thus the command is ssh-keygen -t rsa -b 1024).

3.Now it needs to save this key somewhere and by default it's going to save the key in "/home/riaan/.ssh/" called id_rsa.pub . (In fact it will save your public key as that and your private key will just be saved as id_rsa.)

4.So once we've run the ssh-keygen command, we then enter a pass phrase note that the same philosophy is applied to entering pass phrases as with gpg.

riaan@debian:~> ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/home/riaan/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/riaan/.ssh/id_rsa.
Your public key has been saved in /home/riaan/.ssh/id_rsa.pub.
The key fingerprint is:
15:9e:85:1d:fc:23:2c:ed:81:8c:d3:5a:94:21:93:19 riaan@linux
riaan@debian:~>
                

Once the pass phrase is generated or entered, ssh-keygen returns a "fingerprint" of this particular key.

As an example to demonstrate the usefulness of the key just generated, let us take a scenario with two machines - machine A and machine B.

We want to be able to log-in from machine A to machine B. On machine A we've created a public private key pair and we're going to put our public key on machine B (remote) so that machine B can authenticate who we are.

As part of this authentication, machine B would need to be able to encrypt data flowing between one and the other machine. If it was just a matter of connecting and we weren't worried about encrypting passwords or encrypting usernames or whatever, we would just use telnet to connect between one and the other.

Assuming that you want to connect on a regular basis to machine B and assuming that you are the system administrator on machine A, you send your public key via email to the administrator of workstation B.

Now workstation B is going to get that key and it's going to add the key to their authorized_keys.

Administrator B will create a user on their machine for you to use, and will add your public key to the authorized key of that user.

For our purposes we create a user for Riaan on workstation B called "riaanbre", Riaan generates his public private key pair on workstation A. He then sends me his public key.

Once Riaan's key is in his home directory, the System administrator for workstation B would run the command:

ssh-keygen -l -f
                

-l would display the fingerprint of the encrypted key

-f would give it a file

Riaan puts his key in the /home/ directory for the user called "riaanbre" on workstation B we could then could test it against Riaan.key.pub (in this case this is the name of the file that Riaan sent to the administrator of machine B).

Once the administrator at workstation B has verified Riaan's fingerprint, he adds Riaan's fingerprint (key) to a file called /home/riaan/.ssh/authorized_keys.

Once Riaan's key is an authorized key he should be able to secure shell into machine B by using:

ssh -l riaanbre 192.168.1.144 
                

or he could have said

ssh riaanbre@192.168.1.144 
                

That would then prompt him for a password. Before he gets that password, it would send him a fingerprint of the host he's connecting to.

Now, why would the host send a fingerprint?

Primarily because if workstation B was masquerading or if there was another work station, call it workstation 5, masquerading as workstation B, then when Riaan tries to connect to workstation B, he's actually connecting to the private machine.

In this case the fingerprint of the host is used to check that Riaan is not connecting to the masquerading workstation(s) but actually to the correct workstation.

How do you check that this is the workstation that you are expecting to connect to?

Well, in the directory /etc/ssh/ssh_host_rsa or dsa (as the case may be) key.pub is the public key for that host. The way we test our public key is by using the command "ssh-keygen -l -f":

riaan@linux:/etc/ssh> ssh-keygen -l -f ssh_host_rsa_key.pub
1024 d7:aa:e9:09:1c:eb:f6:04:f7:15:ef:fa:8d:b8:f9:70 ssh_host_rsa_key.pub
riaan@linux:/etc/ssh>
                

The system administrator of workstation B has verified with Riaan that the fingerprint that he's receiving when he's trying to connect to workstation B is actually the fingerprint of workstation B. Riaan can then accept it with a yes at that point.

riaan@debian:~> ssh 192.168.10.144
The authenticity of host '192.168.10.144 (192.168.10.144)' can't be established.
RSA key fingerprint is f6:11:d9:54:32:37:18:e1:f4:5b:4a:06:37:1e:98:68.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.10.144' (RSA) to the list of known hosts.
riaan@192.168.10.144's pass phrase
                

Riaan accepted the fingerprint for the host, workstation B, it's now added to his main known hosts lists so it won't ask him again whether this is in fact the fingerprint for his host because it will have it recorded.

It now asks him to enter a pass phrase and this pass phrase is not the login password, this is his pass phrase that he entered when he created the key with the initial "ssh-keygen -t rsa -b 1024".

So Riaan is now able to log in, using his pass phrase, to the remote machine workstation B. Even though he's got a password on workstation B, he's not using that password, and this is quite important, because an encrypted password of his pass phrase is the thing that's passed across the network, not the unencrypted password on workstation B.

When Riaan accepted workstation B's fingerprint it was added to a file in Riaan's home directory, so that would be home/riaan/.ssh/ to a file called known_hosts and Riaan could quite easily go and delete that host out of there so that the next time he connected to workstation B, it will again ask him, "Is this the correct fingerprint"?

Why would you want to do that? Well, perhaps the machine has changed, perhaps there's a new administrator, who knows why, perhaps the administrator of workstation B re-created his host key.

The known_host is just a public file because all it obtains are a whole bunch of public keys for the host that you are connected to.

As part of this process, you will have seen that Riaan's public key travels from workstation A to workstation B and it got assigned to his .ssh in his home directory.

The question is, why would you want to exchange keys? Because ultimately you still have to type in a password. Well, the reason that you're exchanging keys is that you know, from workstation A, Riaan can type his pass phrase rather than his password on workstation B, and that ensures that all transactions are encrypted including the username and the password.

And how does he pass his public key around to the various machines? Well, he can ftp it or he can secure key copy it or he can send it via email.

You can copy it in a number of ways, remember it's a public key so it's not that critical if other people get hold of his public key as there's not much they can do with it.

Let's assume that Riaan's having to open a number of sessions over and over again. Well, he's going to get pretty hacked-off at having to continually type his pass phrase every time he opens a new session between workstation A and workstation B.

So he decides to use a tool called ssh agent and ssh agent's job is to keep track of the public keys that are being used in connecting to hosts.

Essentially, what happens is when Riaan, on workstation A, needs to connect to workstation B, the ssh agent will verify that this key does come from Riaan. In other words, the ssh agent's responsibility is to handle the key. The first time Riaan connects between workstation A and workstation B, he gets prompted for his pass phrase.

Once he's given his pass phrase he can then add the fact that he has been granted access and the ssh agent's job for that session is to remember the key.

He then starts off a second ssh and what happens? Well the ssh agent responds with the verification on the key and so he can connect to workstation B as many time as he wants without being asked to enter his pass phrase.

There is a catch - the catch is, is that any session, any secure shell session has to be started off of the sibling of the ssh agent. So if you started a terminal and we ssh'ed into workstation B, you then did a sshadd to add the public key to the agent, then you started a new terminal session and you ssh'd into workstation B, it would again ask you for a pass phrase.

The first thing Riaan has to run is "exec ssh-agent /bin/bash" and what that does is replace the current shell with "ssh-agent" which starts a new shell. At this point Riaan needs to use "ssh-add" to add his public key to the agent.( read the man page for ssh-add to learn how this is done)

Once Riaan has done an ssh-add, he's asked for his pass phrase and the pass phrase that it's asking for there is the pass phrase that Riaan supplied when the private and public key pair was created.

Riaan added his public key to the agent and when he tries to secure shell into workstation B, it didn't ask him for his pass phrase. Why? Because when he added the user to the ssh-agent, at that point it's asking for his pass phrase. (If he tried to open a different terminal it would again ask him for his pass phrase because that new terminalouldn't be a sibling of the ssh-agent that we started earlier.)

If you administrate a good number of machines you would not want to type a password every time you connected to one of these machines. To get around this create an account and a public private key pair but instead of entering a pass-phrase, enter no pass phrase at all. Not entering a pass-phrase is the equivalent of secure shelling without a password.

The downside of this is that if control is lost of the administrators' workstation, whoever gets hold of this workstation has then got access to the other workstations on the network.

This time you're going to destroy your public private key pair using the "ssh-keygen -t rsa -b 1024" command. When asked for a pass phrase hit enter.

It will probably say something like I'm going to over write the current RSA public private key pair and you say Yes - you do want to over write them.

When it asks for a pass phrase hit enter, in other works you don't give it any pass phrase at all and it will create a public private key pair - id_rsa and id_rsa.pub.

It will also produce a fingerprint.

riaan@linux:~/.ssh> ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/home/riaan/.ssh/id_rsa):
/home/riaan/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/riaan/.ssh/id_rsa.
Your public key has been saved in /home/riaan/.ssh/id_rsa.pub.
The key fingerprint is:
4d:86:ee:58:66:71:c1:65:01:98:14:46:92:82:7d:d8 riaan@linux
                

At this point you need to copy this to workstation B and over write your authorized key, or you append it to your authorized key file. Log out of workstation B.

At that point you should be able to secure shell from workstation A to workstation B, as a user without a password.

Now you can run remote commands such as:

ssh riaan@192.168.1.114 (or whatever your second machine's IP address is) uptime

and this runs the "uptime" command on the remote machine and returns the output to the local screen, without having to log in to the remote machine. This pretty much gives you full control on the remote machine.

So we've been able to verify the fingerprint of the host we are connecting to, we've been able to generate public private key pairs in order to authenticate who we are and where we're coming from, and we've been able to generate entry pass phrase public private keys which allowed us to log in automatically without entering a password from one host to another.

The secure set of utilities, Secure Shell, Secure FTP will now use the public private key sets in order to encrypt and decrypt traffic flowing between the two.

Of course, we've gone through a whole wad of effort there to exchange key pairs but in fact if you were to log in as root from workstation A to workstation B, it would still encrypt the whole conversation. You would be encrypting using the password from workstation B rather than the pass phrase from workstation A.

We have X which interacts with the hardware. A window manager which provides us the functionality for managing our screen real-estate, and toolkits which allow our clients to have the nifty features we expect in a GUI environment. However, perhaps we are running Netscape Navigator, which used the Motif toolkit, xcalc which used Athena, and other clients which use Qt and Gtk. Many different toolkits equals many different toolkits clogging up our memory. Not only that, but the look and feel of one is different from the look and feel of the next. What are we going to do Bob? Enter the final component of our X environment: the desktop environment.

The desktop environment provides the consistency we as users expect from our window environment. That all similar buttons work the same, that the windows all look and feel similar, that there is a file manager to manage our directories. These are all functions of the desktop environment and a place to put our useful applications like a clock. An analogy of the taskbar in Windows springs to mind here. This is something that Microsoft got right from day 1 and we see where it has got them today. However, MacOS got it right before that - and just to lend counterweight to my argument - it got them less far.

Why all this complexity in the UNIX/Linux environment? Simply to provide flexibility and functionality. These are two words that are not known in those environments mentioned earlier. If you don't like the way MS Windows looks or works, how much can you do about that? Similarly for MacOS. These layers of abstraction allow us to run an environment that we want - not that we are told we will have. Unfortunately this is all rather confusing for the user and possibly a little daunting for the newbie. But, that how it is.

You will need to know a number of things from your ISP, so here is a checklist before you begin:

Armed with these answers, you can begin the following checklist.