Internet of things proposal and report

HETxxx Lab 1 Report Alpha 3/9/06 page 1 of 3

Lab 1 Report: Introduction to Unix and thttpd under FreeBSD

Student Alpha HETxxx Report

Swinburne University of Technology Melbourne, Australia [email protected]

Abstract-This technical report describes the process and results of completing HETxxx lab 1. It particularly focuses on the setup of the http server software package, thttpd, under FreeBSD.

I.INTRODUCTION

The HETxxx lab 1 component comprised of an introduction to Unix using the FreeBSD operating system. This included understanding the usage of several basic Unix commands as well as the setup of the thttpd software package. This lab was carried out using the Remote Unix Lab Environment (RULE), allowing remote access to virtual Unix hosts while using lab computers running the Windows operating system. This report describes the results obtained from lab 1, how they were obtained, and addresses the questions posed throughout the lab 1 methodology.

II.BACKGROUND

A.thttpd

thttpd is a http server software package used in the lab by the FreeBSD operating system. Basically, thttpd is a “simple, small, portable, fast, and secure HTTP server” that although has limited features, is sufficient for most uses of the web, and performs about as fast as the best full-featured servers such as Apache or NCSA Netscape [1]. Thttpd is also a pioneer containing the useful feature of throttling [1], which will be explained later in the report.

III.EXPERIMENT METHODOLOGY AND FINDINGS

A. Initial Steps

With the thttpd package already installed on the RULE host, the pkg_info command was issued. The result of this command produced a list of the packages currently installed on the host. As thttpd was already installed on the host, the pkg_info output list included the thttpd package. By using the commands:

man pkg_info

man pkg_add

the corresponding manual pages can be viewed, giving helpful information such as what the command does, and how to use it (by listing required and optional parameter

switches). The manual pages of these commands indicate that the pkg_info command is a utility to display information on software packages, while pkg_add is a utility used to install software packages.

Next, the following command was issued:

sockstat –4

The output from this command is a list of all open sockets. By using the –4 switch at the end of the command limits the output to display the IPv4 sockets. By examining the output, it can be seen that, in our case, the rule host is listening to ports 22 (SSH Remote Login Protocol), 25 (Simple Mail Transfer) and 514 (syslogd). The asterisk under the “Foreign address” column indicate that these ports are listening. Both ports 22 and 25 display to be using the protocol type “ tcp4” , indicating the use of the TCP transport protocol. Similarly, port 514 displays to be using the protocol type “udp4”, indicating the port is using the UDP transport protocol. The rule host has already established connections with port 22 as indicated by the inclusion of a foreign address in the output.

With the initial steps completed, the next steps require the use of root user privileges. This is done by using the command “su”. The super user has “administrator” powers, basically allowing unrestricted access and freedom. The user “user” is not allowed to perform the desired task of setting up a simple web server for several reasons, namely security and data preservation. For example, functions such as changing important configuration files can only be done by the super user, and since “normal users” are not part of the “wheel” group, the specially configured file is preserved. Restricting the “user” means regular users don’t have unneccessary access or power, such as the ability setting up a web server whenever they please.

B.thttpd.conf.sample

Examining the /usr/local/etc/thttpd.conf.sample file enabled the discovery of which directory on the rule host is served via http when the server is started and where the log file is written to. In our case, these directories already existed. The command,

ee /usr/local/etc/thttpd.conf.sample

allowed us to examine the configuration file, which

HETxxx Lab 1 Report Alpha 3/9/06 page 2 of 3

indicated the directory serviced is /usr/local/www/data, and the log is written to /var/log/thttpd.log.

Once the preceding information was discovered, the thttpd.conf.sample was renamed to thttpd.conf by issuing the command,

mv thttpd.conf.sample thttpd.conf

C.Adding content

Content was added to the thttpd web server by creating and editing an “ index.html” file in the /usr/local/www/data directory. The command used to create the file was as follows:

ee index.html

D.Using thttpd

The manual page of thttpd was examined by issuing the following command

man thttpd

By viewing the corresponding manual page, the various switches and their functions could be understood. In particular, the –C switch is used to indicate the configuration file to read, while the –p switch is used to specify an alternate port to the default port 80 to be listened on.

As mentioned previously, thttpd supports throttling. Throttling enables the configuration of certain amounts of bandwidth to be used for certain service types. Both a maximum and a minimum byte rate can be set [2]. An example of throttling could be capping the available bandwidth at 25% when downloading movie files. This is advantageous in respects to providing a rough form of QoS, as bandwidth can be custom distributed, allowing throughput levels to be guaranteed. For example, by capping the downloading of movie files at 25% of the bandwidth, this prevents it soaking up the bandwidth, ensuring movie files are not given priority, thereby guaranteeing that web-browsing traffic is given a fair throughput level, despite several movie downloads. Throttling could also help ensure that the quality of service of no user is lower based on the tasks they are doing or the service they are currently using.

thttpd was run using the command

thttpd -C /usr/local/etc/thttpd.conf

which was then followed by the command

sockstat -4

The following line is now included in our open sockets list: www thttpd 19730 1 tcp4 136.186.230.161:80 *:*

This indicates that thttpd is running and that the web server is listening.

This was confirmed when we were able to view our simple webpage by typing the following URL into the Mozilla Firefox address bar:

http://rule61.caia.swin.edu.au

After reloading the same URL that contained changes in the webpage content, we discovered that it was not necessary to restart thttpd to be able to view the changes made to the webpage.

E.Changing the port number

By adding the line port=8000 to the thttpd.conf file and restarting the server, the server will run on port 8000 rather than 80. Restarting the server required obtaining what process ID thttpd was running under. By issuing the command ps –ax we could see the processes that were running, and their IDs. In our case, thttpd was working under the process ID 19730. We then issued the following commands:

kill –s USR1 19730

ps –ax

The output of the latter command revealed an absence in the thttpd process, confirming we successfully killed the thttpd process. Also, when viewing our list of open sockets (using sockstat –4), the output indicated that the web server we created was now absent and no longer listening. Trying to hit the web server with the same URL used previously in Firefox gave us an error message titled “Unable to connect”. Reading the error message further indicated that the particular browser could not establish a connection to the server at rule61.caia.swin.edu.au.

The server was restarted by using the command:

thttpd -C /usr/local/etc/thttpd.conf

sockstat -4

The output of the latter command gave the following output: www thttpd 20563 1 tcp4 136.186.230.161:8000 *:*

This indicated that the thttpd server was now up and running again, although running under a new process ID and port number 8000. The webpage could successfully be accessed by running the following URL:

http://rule61.caia.swin.edu.au:8000/

F.thttpd log file

The thttpd log file is written to /var/log/thttpd.log. Upon inspection of the log file, format of the first few lines were as follows:

136.186.1.119 - - [14/Mar/2006:02:04:16 +0000] "GET / HTTP/1.0" 200 25000 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5"

136.186.1.119 - - [14/Mar/2006:02:04:16 +0000] "GET /favicon.ico HTTP/1.0" 404 0 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5"

136.186.79.206 - - [14/Mar/2006:02:12:47 +0000] "GET / HTTP/1.1" 200 25000 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5 .1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

The above information displays that the log file logs information such as the clients IP address, the username of the client (if requested by the browser), the timestamp, request information and status code, as well

HETxxx Lab 1 Report Alpha 3/9/06 page 3 of 3

as information on the clients web browser and operating system.

When another group hit our site, evidence was logged into our log file, giving details about their client.

By hitting a page that did not exist, a “404 Not found”error is returned. The log file creates an entry containing the address of the requested page and a noticable change from the OK status code 200 to the Not found code of 404. One of the log file entries is shown below:

136.186.79.206 - - [14/Mar/2006:02:37:43 +0000] "GET /hygfghfg HTTP/1.1" 404 0 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1"

G.Custom error page

A custom error page for the “404 Not found” error was generated by creating a err404.html file and adding it to the /usr/local/www/data/errors directory using the following commands:

mkdir errors

cd errors

ee err404.html

When a non-existent web page was now hit, our custom error page was returned.

H.Private directory

A n e w p a g e a t t h e U R L http://rule61.caia.swin.edu.au:8000/private/ was created using the following commands:

mkdir /usr/local/www/data/private

cd /usr/local/www/data/private

ee index.html

This page was then password protected by using the program htpasswd, using the command:

htpasswd -c /usr/local/www/data/private/.htpasswd

ruleuser

Accessing the webpage now prompts the user for a username and password. Entering either of these incorrectly denies access to the webpage and generates a “401 Unauthorized” error. By entering both the correct username and password allows access to the page.

Upon viewing of the .htpasswd file, it has one line, containing the username and password required to gain access to the file. However the password is encrypted. Attempting to retrieve this .htpasswd file through the web browser is not allowed – it generates a “403 Forbidden” error, as the file is an authorization file, and retrieving it is not permitted

As the final step of the lab, the /etc/rc.conf file was edited to contain the following line:

thttpd_enable=”YES”

This automatically starts thttpd at startup.

IV.CONCLUSION

This lab provided a good introduction to FreeBSD, a Unix operating system. Through exploring FreeBSD, we discovered how to set up a simple web server, which also introduced us to the two types of users available and the differences in their permissions. We found it interesting to see the various error pages and how to assign a particular error page to appear for a particular error.

REFERENCES [1] thttpd man page from thttpd website,

http://www.acme.com/software/thttpd/thttpd_man.html (accessed March 2006)

[2] throttling explanation from thttpd website,

http://www.acme.com/software/thttpd/thttpd_man.html#THROTTLING (accessed March 2006)