If you have a use for UML that you'd like to share, write it up,
including the following information
This is intended to be a collection of HOWTO material at least as much
as it's intended to be an advertisement for UML, so it would
definitely be a bonus to include HOWTO-like step-by-step instructions.
It could either be hosted on this site or linked from here back to
your site.
From : Jon Wright (jon at gate dot sinica dot edu dot tw)
Date : 7 Sep 2001
I work for Prof Carmay Lim in the Institute of Biomedical Sciences,
Academia Sinica, Taipei, Taiwan
http://www.sinica.edu.tw
http://www.ibms.sinica.edu.tw/~jon
We're a structural and bioinfomatics group.
Basically on site we have about 10 Linux workstations, a 30 cpu beowulf,
and a couple of nfs fileservers all ip-masqed behind a single firewall.
We also have a group at National ChingHwa university at another city. We
need to provide access to our beowulf and other services to the students
but we don't want to allow direct connections to our firewall. Instead of
having direct connections to the firewall which if cracked gives access to
the internal network device and hence allows network sniffers, we boot a
UML kernel on the firewall itself and, using the slip networking (this was
set up 6 months ago - now we are looking at the tap interface), network the
UML kernel.
The host firewall accepts no syn packets at all on its external
IP address. All syn packets must be directed to the UML kernel IP address
to be accepted.
The UML system offers sshd, hhtpd, anon-ftp (oftpd) to everywhere, the
firewall only offers sshd and squid to the internal network and nothing to
the external network.
Students use ssh to logon on to the UML kernel using a generic name such
as user001, From there they can issue a second ssh command to the
internal network machines (ssh -l fred 192.168.0.140). We don't use the
same usernames or passwords on the UML system as the internal systems so
if someone does get UML account details, it won't help too much for
guessing usernames/passwords for the internal machines. We don't even list
the internal machines in the hosts file.
The firewall itself only allows connections from the UML machine to
internal machines on port 22 (set with ipchains) so if someone cracks the
UML machine they can not portscan the internal machines. The UML machine
does not contain a compiler, and many files/executables such as who, w,
ping, traceroute are read/write/execute for root only. We run tripwire
every night and email the report out, but we don't allow incoming email. If
fact, the host firewall only allows connections to the UML machine on
needed ports such as 22,80,21
The main purpose of the UML system is to provide a secure restricted
machine that offers limited external services and onward ssh connections
to our internal machines but does not allow any access to the network
devices themselves. (We don't allow loadable modules and we don't compile
hostfs)
Also being a 700mb file we can keep a compressed root file on cdrom and
use it to compare to the live one now and again and if need be restore
things using the host kernel.
All in all this is working very well for us at the moment. In fact, the
hardest part is organising all the ipchains rules on the host system so
that we limit what type of connections go where. For that we found
excellent help in the ipchains-howto, they used about 4 different
machines to provide firewall and external services while we saved on
hardware using one machine that worked as two. While other people can
probably pick some holes in this setup (I am not a pro ssyadmin) I haven't
seen any glaringly big holes - we have to allow the students access
somehow and having the external services on a system that does not have
direct access to hardware is a big bonus.
Many thanks for such a great tool
Virtual Network Laboratory - Christchurch Polytechnic Institute of
Technology (CPIT), New Zealand: A detailed Case Study HowTo.
William McEwan (Scottish exile), School of Computing, CPIT, New
Zealand.
mcewanw at hermes dot chchpoly dot ac dot nz
8 September 2001
"A problem with teaching data communications in an educational
institution is that there is always an inherent danger of data comms
experiments interfering with the normal operation of the campus
network. Many institutions have traditionally simply avoided much in
the way of practical data comms laboratory work. With the growing
importance of internetworking in general this is obviously an
unsatisfactory situation. With campus network infrastractures already
in place and centralised administration of IT established, it often
proves difficult (and expensive) to implement new network laboratories
that are sufficiently flexible and sufficiently isolated from the
normal campus".
[The above is extracted from a paper presented by this author: McEwan,
W. (2001) "Using Academic Research Methodologies to Improve the
Quality of Teaching: A Case Study". In Proc. Fourteenth Annual
Conference of the NACCQ, Napier, New Zealand: 83-93]
Introduction
With the above problems in mind, I am in the process of creating a
virtual network laboratory, using uml virtual machines. This work, at
the School of Computing, CPIT, NZ, is one of the key components in our
implementation of a "data comms and operating systems" teaching and
research laboratory. The uml configuration currently in active use in
our data comms teaching is illustrated below
(text version):
The virtual network laboratory is implemented on a 1 GHz Pentium III
system having 384 MBytes of RAM and a 20 GByte hard disk. The host
operating system is Redhat Linux 7.1 with a 512 MB swap partition. In
all, the virtual net consists of 20 virtual hosts sitting on 10
(sub)subnets connecting via one virtual router to our campus network
(and thence out to the Internet) as shown. The CPIT campus has been
assigned a class B address space which is subnetted into class C
address ranges (i.e. subnet mask=255.255.255.0). One of these /24
subnets has been allocated for this virtual lan server. On the
virtual network side of this lan the range is further /28 subnetted as
shown (i.e. netmask=255.255.255.240).
The current implementation uses the small debian uml root_fs. Using
debian package manager (dpkg) I have additionally installed telnetd so
that students can log in remotely. On the real host we have the
mindterm ssh client applet served by a running apache web server to
allow ssh login to that machine. We also have the free weirdx X
server applet served from the same machine. It is a great combination!
I shortly intend experimenting with X and ssh using the uml Linux
RH7.1 pristine root_fs in place of the small debian one.
One advantage of the above configuration, where one of the virtual
machines is used as a router, is that that machine can be configured
as a firewall effectively sandboxing the virtual network users into
the virtual lab (whilst allowing inward telnet or ssh traffic and
anything out as desired).
Details of building the
network...