CyberLab User Manual

Chapter 0 - Access to the CyberLab

Copyright(c), 2014-5 Fred Cohen - All Rights Reserved

You will learn:

Quick Quiz: Try each of the items below to see how quick quizzes work.

Basics of CyberLab Access and Use

The CyberLab is on online facility located in various data centers and other locations across the Internet. It operates by remote access using:

Instructions are provided on videos for a variety of specifics under different operating systems and software tools. We will focus on one particular set operating under Mac OS-X. Similar tools under other operating systems are demonstrated in the CyberLab videos available at under "Courses / Webinars".

Secure shell under OS-X and other operating environments is operated by a command line from athe Unix "shell", typically, but not always, a program called bash. Normal users see this through a terminal interface. An exmaple is shown here:

A command line terminal with an ssh command entered

From this point forward, we will present command and results in text rather than graphical format. For example, the previous picture will be represnted as follows:

Boldface is used to represent user input while output is not boldfaced. Italics is used for comments.

Computers in the CyberLab and many other places differentiate between UPPER and lower case, digits (e.g., 0, 1) and letters that look like them (e.g., O, l), and generally require that inputs match exactly to expectations in order to be acted upon as desired. While spelling errors in human readable text (such as this one) may be intrepreted reasonably by humans, computers will produce results that may be unporedictable and/or undesirable, in some cases in the extreme. For that reason, it is often easier and more effective to "cut and paste" complex sequences than to try to type them. This is done by use of the mouse and/or keyboard in different ways on different systems. We assume you have this figured out for your system. As an example, if we ask you to enter the URL into your browser, and instead, you enter you may get very different answers. To make sure you do it right, try copying and pasting the URL into the browser window where URLs go. Here's what it should look like...

The URL pasred into a browser

This may take you several tries. Make sure you copy the URL after the "URL" and not the one with the link you can click on. Make sure you paste it into the right place in your browser - where URLs go, and not where searches go. Get this right before we contine on.

Now, let's try another one. Put this URL into your browser:

Again, be careful to put it in the URL area and not the search area. After you succeed, remember this technique for future use.

Quick Quiz: Pick from the selections below:

Using secure shell (ssh) to communicate

Secure shell (ssh) is a program that runs on one computer to connect it to other computers over encrypted end-to-end connections. Encrypted connections are intended to prevent others from being able to read the content communicated while the ssh protocols also provide assurance of non-alteration of the content in transit, if properly used. Note that intent does not always meet reality, but for ssh it usually does. End-to-end encryption means that, between the user's "end" of the communication and the server's "end" of the communicaiton, everything going back and forth is encrypted and authenticated. That means that computers in the middle of the communication cannot alter or observe the content. However,

In the CyberLab, we only use ssh to provide for encryption of the content and integrity of the message stream. The purpose is to make it hard for a user to accidentally allow an attack in the cyberlab to spread outside of the CyberLab. We have no secrets, and we don't track who uses what when or anything else of that sort. We just want to grant access to authorized parties at authorized times. As such, ssh provides the tunnel between the user's mouse, keyboard, and screen and the virtual mouse, computer, and screen of the CyberLab area they are accessing.

Secure shell is typically run by issuing commands like this:

In this case, ssh was told to open an encrypted communication channel with the remote computer with an IP address ( associated with the name and it did so, logging into the remote computer. Unless told otherwise, ssh assumes the user identity (name) on the remote computer is the same as on the local computer. But if we wanted to login as another user, we would be able to specify it as we will see below.

Since there was no previous communication with a computer of this name the protocol warns the user that this might be any computer, and provides the "DSA key fingerprint" for the remote computer. You can check this against a known value (if you have it) to verify that this is the computer you intended to talk to, and this is the mechanism used to try to reduce or eliinate man-in-the-middle attacks. From now on, after the "yes" answer is given, unless the remote DSA key fingerprint changes or the user removes the key from their local key listing, no warning will be given and access will be assumed acceptable.

Next, the user is prompted for a password. If the user ID and password are valid, the user is logged in and the session proceeds as if the user's local terminal were a local terminal on the remote computer. They can type another command and it will be executed on the remote computer.

However, in the CyberLab, this is not what happens...

Quick Quiz: Pick from the selections below:

Making Virtual Network Console (VNC) connections

VNC makes it appear as if there is a display screen, mouse, and keyboard for a remote computer on your local computer. Here is an example of a VNC display of a remote computer on a local computer:

A VNC session screen

As you can see, it looks just like a local computer screen and mouse and keyboard actions in the windows work pretty mush as if the computer were the one you were using locally. If you want to see the picture at its full size, use your Web browser to view the picture - but it is reduced here so it doesn't take up your whole screen.

Quick Quiz: Pick the best answer:

While VNC is a very useful protocol, it is inefficient in many ways, and perhaps more importantly, it is easily broken into for alteration and surveillance purposes, and has poor quality authentication. As a matter of principal, the CyberLab doesn't want to run such insecure mechanisms between distant computers.

However, ssh has a few features that weren't mentioned before. One of those features is that it allows other protocols to be "tunneled" through the ssh secure tunnel between computers. That means that, for example, you can tunnel VNC through ssh tunnels and gain the advantages of VNC and the advantages of ssh in combination. Secure (end-to-end encrypted and autenticated) VNC sessions (over ssh) is how the CyberLab operates for remote access.

It turns out that the example depicted above runs VNC over ssh to do its work. The way this works is a bit complicated, and would take about a page to explain. But since the CyberLab is built to be easy to use, you don't have to know the details to be able to use it. We just like to tell you so you understand it better. So if you like, you can skip the next paragraph and remain ignorant of the details. But don't skip too many or you will miss the part about how you can use ssh to transfer files.

VNC uses transmission control protocol (TCP) ports (sessions between endpoints with specific bit sequences in datagrams sent between computers are used to encode the specific sessions so input and output on one side of the connection are connected to the right programs on the other side of the connection and vice versa). These ports are associated with specific positive integers in the range from 0 through 65535. VNC usually uses ports starting at 5901 and working their way up to as far as they need to go to accomodate the sessions in use. In the case of the CyberLab, we typically use anywhere from 3 to 30 ports, different ports for different virtual machines.

In order for ssh to "tunnel" protocols through encrypted sessions, it provides the means to remap ports on the initiating machine to different ports on the receiving machine so that if a local port is in use, a different port can be used for the secure shell connection on the other side. For example, ssh normally runs from a user port to server port 22. But in order for VNC running on port 5901 to pass through the tunnel, it has to actually travel over port 22. So en router, port 5901 gets tunneled through port 22, and ssh provides the ability to make it appear on the local computer on any port desired (for example port 5902 if there is another VNC session to another remote computer already running on port 5901). That means you can have as many different VNC sessions running through different ssh tunnels to as many other computers as you like (up to 65535 of them) by assigning each a different local port to connect to the remote port.

As it turns out, you can do this on both ends of the ssh connection. So that's what the CyberLab does. When you login remotely with ssh, on the local end, it maps the session into port 5901 (unless you specify otherwise). On the remote side, it maps the port into the port number of the VNC session running on the virtual machine running on the physcal machine associated with your user identity for the reserved time period for your lab session. It does this by executing a man-in-the-middle attack on the ssh protocol. You come into a ssh session on a computer that decrypts the session, remaps it to the proper internal session on a different IP address and port, remaps the VMC tunnel from the one you used to come in to the one necessary to work on the internal side of the CyberLab based on your user ID, password, and the port you used, and re-encrypts the session and tunnel into the virtual machine within the CyberLab that you use to work in.

Quick Quiz: Pick the best answer:

All of this is transparent to you, the user, so you don't have to worry about the various DSA keys for the various virtual machines in the various physical machines at the various IP addresses within the various CyberLab facilities. It all appears as one and the same thing to you. You just see a VNC session to a remote computer on your screen and use it as if nothing happened between you and it.

In theory, we could watch all the sessions going back and forth, alter traffic, and so forth. And anyone breaking into the computers performing these tasks could also do that. Of course we could also do that on the endpoints within the CyberLab. So:

A short note on user privacy

Quick Quiz:

Using Secure File Transfer Protocol (sftp) and File Transfer Protocol (ftp) to transfer files

Of course you might like to be able to store some things for some time longer within the CyberLab. That's why we support secure file transfer (sftp).

The sftp protocol and software uses ssh as a tunnel to store and retrieve files to and from file servers. Like VNC, sftp transfers files through encrypted authenticated tunnels. It has all the limitations and issues as ssh in terms of protection by cryptography. However, the sftp system in the CyberLab has a few interesting added features. They are (1) the diode and (2) the internal file server.

The diode

The diode is a way to get content into the CyberLab. You send files into the server, they disappear from the external file server and appear on the internal file server. The files go in but they don't come out and they don't stay around, so you cannot get them back or have someone else retrieve them. Here's what you type from your computer:

Don't forget the ':' at the end... You will have to enter your user ID and password at that point. Some time later, within the CyberLab, the file (myfile) will appear on the internal file server and you or anyone else in the CyberLab can get it from there.

To transfer more than one file, list the files one after another. To transfer directories, use the "-r" switch as follows:

The '-r' switch indicates "recursive" transfer - in that it will recursively send all files and directories, their files and directories, and so forth.

For more information on things you can use ssh and sftp for, you might want to try using the "man" command under Unix-like systems or look for manuals on the Web by searching the Web for further details.

Quick Quiz: Note - there can be more than one right answer to many of our questions...

The internal file server

Within the CyberLab, you will have access to a virtual machine (VM). You will be the superuser (e.g., 'root') on the computer and able to do anything you like to it. This includes wiping out all the files including the operating system and accounting files, crashing the VM, and then having to wait till your next session to have a clean try at it.

Since your storage in the VM is wiped out between sessions, you might want to save your critical work between sessions. That's why internal to the CyberLab, we have a file server. The file server uses the file transfer protocol (FTP) to allow any CyberLab user to place their files on the server and retrieve them at a later time.

To use ftp, you typically have a session like this:

The "ftp" command runs a program called ftp that initiates a session between the computer it is running on and the computer specified on the command line. In this case, the computer is identified by the Internet Protocol (IP) address which is an example of an internal address used within the CyberLab for the FTP server.

Passive mode FTP makes certain that all communications sessions to and from the FTP server are started from the local computer you are running 'ftp' on. This is important in the CyberLab because all of the real and virtual computers communicating to the FTP server do so using network address translation (NAT). The actual addresses used to communicate may differ, and in order for the server to return information, it has to rely on the sessions started by the initiating computer.

A "dir" (directory) command can be used to see what is on the FTP server. In this case, there is one directory called "files". This directory is protected "drwxrwx-wx" and owned by user 0 and group 0 (as the listing shows). The proteciton settings (rwx for the owner, rwx for the group, and wx by others) identify that the root user and group can read, write, and execute (enter) the directory. However, other users (including "anonymous") can only write and enter the directory. There is no "root" login to the FTP server, so don't bother trying to guess passwords. That means that the ONLY users are "anonymous" with no password required, and that you, as an anonymous user, can put things into the directory, read them back out, delete them, but you cannot see what is in the directory. Since this is the only place you or others can put files in the FTP server, once you or they put files there, you and they cannot see what they were called. Nobody can.

To use the "files" directory, this example did a "cd" to change directory to "files". Then it did "put NOTES" to put (copy) the file NOTES from the current directory on the local computer to the file names "NOTES" in the FTP server under the "files" directory. Next, a "dir" command was used to list the files in the directory on the FTP server, and as you can see, nothing was shown.

To prove that NOTES was there, we did a "get NOTES" to get (copy) the remote file NOTES from the current directory on the file server to the current directory on the computer we ran 'ftp' from. Note that it overwrote the previous "NOTES" file on the computer running the "Ftp" program from. Finally we "quit" FTP and returned to a command prompt.

Quick Quiz:

To do the right thing, I deleted this file later on...

You can also make directories in the FTP server (under the "files" directory), and their contents will be visible once you enter that directory. For example:

Note that I cleaned up after myself by removing the directory and its contents.

Quick Quiz:

A few subtleties remain:

Finally, you may recall that when you use sftp to put files into the CyberLab, they disappear from your external account and appear (eventually) within the CyberLab. They appear on the FTP server under the "files" directory using the name you gave them. If somneone else uses the same name either inbound through the diode or within the FTP server from inside the CyberLab, the last one in is the one that will be available. So name them carefully, don't forget their names, and don't send too much.

Quick Quiz:

How to get your User ID (UID) and Password

In the CyberLab, we create user IDs (UIDs) and passwords for access. They are typically long and arbitrary strings like CaBAFQBpaq2AE6vpXDgEvbwrPzr0LFqr or whatever we happen to produce that day at that time. We create files with lists of these UIDs and password pairs (yes - they are plaintext password files containing UIDs and passwords). We provide sets of these to professors for use by the students in their classes. We don't particularly remember what professor gets what sets of these, and if they want more of them, we send more of them. We don't know who gets what UIDs and passwords and we don't try to find out.

We send UIDs and passwords out, the professors hand them out, and we provide each one with a finite number of sessions they can reserve using our time slot reservation system. Typically, we provide them 10 at a time. Each UID and password gets 10 time slots (give or take) for use as available. If they run out and the professor wants them to have more, we give the professor more UIDs and passwords. Since nothing is stored in the VMs and the FTP server uses whatever you want for filenames, changing your UID and password has no effect other than making you use a different pair to login, do resevations, etc. when one runs out.

To get your UID and password, you have to contact your professor. We don't intervene, we don't have anything to do with it, and we don't know how your professor chose to allocate the UIDs and passwords we provided. To get more they only have to ask us for more - up to a point. We do have finite resources, and eventually we will run out. In any given semester, we currently support only up to 64,000 or so UIDs.

At the end of the semester, we delete all of the existing UIDs and create a new set of them. We don't spend any time or effort trying to remember or forget old UIDs and passwords, we just delete what's there, create a new set, send them to professors who ask, and move forward from there.

In summary, ask your professor. If you are a professor, ask us.

Quick Quiz:

How to use your UID to reserve a time slot

Time slots in the CyberLab are allocated as they are requested. First come - first served. You go to the Web site provided by your professor and use the UID and/or Password provided to access the reservation system. In the reservation system, you request a time slot from the set made available to you. Those are all of the time slots still available as of the time you make the request, so if you don't see a good one, you should have tried sooner. Since they are finite and all of the ones we have are made avilable, there are no more to provide than the ones you see. It's a competitive world and the early bird gets the worm.

Quick Quiz:

Here's how it works. Use your Web browser and enter into the URL area. You should see something like this:

The CyberLab Web Site

When you select "Reservation" from the left-hand frame (column), you will see something like this:

The Reservations Page

Enter the authenticating information you got from your professor into the form (yours will be different from that shown above), press the "GO!" button, and you should see something like this:

Choose your time slot

Note that the current time in the CyberLab (which might be in a different time zone or offset from yours) is shown at the top of the screen. When you select a time slot for your reservation, use the one appropriate understanding that the CyberLab is offset relative to the time of day and date based on what timeone you are in.

Select a time and date convenient to your usage, and please don't choose one that is already passed (unless you have a time macine and can go back and use it). Once you select a time slot and press "GO!", you should see a screen like this:

Copy and paste this into a text window!

DO NOT DO A SAVE-AS!!! Copy and paste this into a text window! Don't wait till later or refresh the page. The page will not be displayed again by the Web browser. If you try to do a Save-As or something like that, it will likely fail because most browsers reload the page when doing a save-as. That will both fail to work properly and produce a different output that may be a deception.

Quick Quiz:

Note a few things:

How it works

When you reserve a time slot, the reservation system gives you session details. Typically, these will include the details you need to access the CyberLab for your reserved time slot. Here's how it works:

To be clear, your UID and/or Password are used for getting reservations and sending files into the CyberLab through the diode. They persist over the duration of your class or until you use all of the avilable time slots. They are NOT used to access the CyberLab itself. The information from the reservation system is used to access the CyberLab and changes for each time slot.

Quick Quiz:

How to use your UID and Password to access the CyberLab

For the purpose of this tutorial, but it may be different for your actual use, suppose you get instructions like this when you get your information from the professor:

Suppose you want to put a file called TestFile into the CyberLab FTP server for use in your work there. Here is what you would do:

That's it. Some time later, the file 8dc08a4073ba7957b653ef17ac8bc87f.TestFile will show up in the FTP server, and since nobody else will likely be able to guess or use the same name, there it will sit untill you use it from within the CyberLab.

Suppose you want to reserve a time slot for using the CyberLab. Here's what you would do:

Quick Quiz:

Once ssh is operating, you should be able to use VNC to enter the CyberLab. For OSX, we used "Chicken" (the new verison of Chicken of the VNC) as shown here. Note that the port (5) corresponds to 5905 (VNC ports stypically start at 5901) and that localhost reflects the use of ssh as detailed earlier.

Chicken of the VNC configured for this example

Once this runs, you will have to enter the password again for VNC access, or you might decide to save it formultiple entries during the same slot. Here's what it look like once you are in:

The VNC connection in the CyberLab - Up and ready to go

Press here to go to the next section