Site Home Page The UML Wiki UML Community Site The UML roadmap What it's good for Case Studies Kernel Capabilities Downloading it Running it Compiling Installation Skas Mode Incremental Patches Test Suite Host memory use Building filesystems Troubles User Contributions Related Links The ToDo list Projects Diary Thanks Contacts
Tutorials The HOWTO (html) The HOWTO (text) Host file access Device inputs Sharing filesystems Creating filesystems Resizing filesystems Virtual Networking Management Console Kernel Debugging UML Honeypots gprof and gcov Running X Diagnosing problems Configuration Installing Slackware Porting UML IO memory emulation UML on 2G/2G hosts Adding a UML system call Running nested UMLs
How you can help Overview Documentation Utilities Kernel bugs Kernel projects
Screenshots A virtual network An X session
Transcripts A login session A debugging session Slackware installation
Reference Kernel switches Slackware README
Papers ALS 2000 paper (html) ALS 2000 paper (TeX) ALS 2000 slides LCA 2001 slides OLS 2001 paper (html) OLS 2001 paper (TeX) ALS 2001 paper (html) ALS 2001 paper (TeX) UML security (html) LCA 2002 (html) WVU 2002 (html) Security Roundtable (html) OLS 2002 slides LWE 2005 slides
Fun and Games Kernel Hangman Disaster of the Month

### UML in the real world

The purpose of this section is to let UML users describe what they're doing with it and how they're doing it. This eventually (when there's a wider variety of cases here) will let everyone see the breadth of UML applications, and provide people who are interested in a specific use with the information needed to implement it.

If you have a use for UML that you'd like to share, write it up, including the following information

- the problem that you're solving - and saying "I'm doing this wierd thing because I can" is perfectly acceptable. That's more or less how UML came into existence.
- how you're using UML to solve it
- how well it's working, including solutions or workarounds to any problems you encountered

and send it in.

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.

UML as an augmented firewall

> 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

An implementation of a teaching network with UML

> 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...

Automated testing of FreeS/WAN with UML

> For quite a while, the FreeS/WAN project has been using virtual networks of UMLs to test their code. Michael Richardson gave a talk at OLS 2002 on what they're doing and how they're doing it. The slides are available at http://www.sandelman.ca/SSW/freeswan/fsumltesting/ .

Hosted at