Computer Networks - Assignment 2 (2008)

A Filtering Database Application Proxy

An application proxy is a program that runs on a machine usually attached to two networks - an internal network and an external network - that allows connectivity for a particular application between clients on one network and a real server on the other. An example is the wwwcache.anu.edu.au Web cache that acts as an HTML proxy between HTML browsers within the ANU's networks and HTML servers outside.

Another, more relevant, situation is where a legacy IPv4 application server needs to provide services to IPv6 connected clients.

For this assignment, the application we want to proxy for is the PostgreSQL database server. In our case, the server is only accepting IPv6 connections, but the clients need to connect with IPv4. The proxy application in this case accepts IPv4 connections from PostgreSQL clients on behalf of the real PostgreSQL server and then connects to the real server over IPv6 to pass the queries etc. across.

The important thing to note is that this is all taking place at the application layer. No packets are passing through the proxy machine at the network or transport layers - as would be the case if the proxying machine were a router.

This assignment is in two parts - the first part requires you to write an IPv4 to IPv6 application proxy for PostgreSQL and the second part is to augment it with some filtering to restrict access to the PostgreSQL database based on client IP address and database username.

For testing and development of this assignment, an IPv6 PostgreSQL database server has been set up on "gnosia.anu.edu.au". This database server allows connection to a database named "networks" from anywhere on the IPv6 Internet including from machines in N112 or N115 when they have an IPv6 address configured correctly as per Lab 3. Access from home etc. may require use of an IPv6-over-IPv4 tunnel (as no Australian ISP currently offers an IPv6 service that I am aware of).

Three database user accounts have been set up:

• networks - password "networks"
• tutors - password "MarkWell"
• bob - password "ethernet"

A commandline tool, psql can be used to connect to this database as any of these users and perform queries etc.

For example: psql -h gnosia.anu.edu.au -U bob networks should request a password (above) after which you can perform simple queries such as select * from marks;. Use backslash "q" to quit from psql. Some online help is available from within psql, as well as command completion.

Full online documentation for PostgreSQL is available at http://cs.anu.edu.au/doc/postgresql-doc-8.2/html/index.html.

This assignment is to be completed in groups of 2 (as for the first assignment).

Part One

The first part of the assignment, worth 50% of the assignment mark, is to implement an IPv4 to IPv6 proxy server for PostgreSQL. It needs to listen for incoming IPv4 connections, accept them, then, for each incoming connection, create an outgoing IPv6 connection to the database server, then pass data back and forth (bi-directionally) between the client and server. When one end closes, close the other!

The port to listen on and the hostname and port number of the server need to be specified as command-line arguments:

• -l listen-port (can default to the PostgreSQL standard: 5432)
• -h server hostname
• -p server port (can default to the PostgreSQL standard: 5432)

Use the getopt (3) (man 3 getopt) function to process the command line arguments.

fork ()ing is the preferred way to deal with multiple clients (your implementation should be able to handle an arbitrary number of clients simultaneously). A less desirable, but possibly faster, option is to use a single threaded process and to use a large select () set.

You will need to determine how to handle bi-directional communications between the client and the server.

Your executable for this part of the assignment should be called pg_proxy

Testing

Your proxy can be tested in a number of ways. Generally, use the psql command line tool to connect to the database via the proxy either from the same machine as the proxy is running on, or on another machine in the lab. Use the wireshark tool to make sure the packets are flowing properly.

Part Two

What we are interested in is to allow only some database users to connect to the database from certain IP addresses. PostgreSQL can now do this natively, but we'll implement our own mechanism via the proxy. An example might be where a less trusted host needs to access some data from the database, so we create a special user account for these accesses and give this user the least amount of privileges necessary for this host to access. The second part of the assignment is worth the other 50% of the assignment mark.

The format of the messages between the PostgreSQL server (backend) and clients (frontends) such as psql is reasonably well documented at: http://cs.anu.edu.au/doc/postgresql-doc-8.2/html/protocol.html.

Also, I strongly recommend using wireshark or tcpdump which can reveal much about what goes on between the frontend (client) and backend (server).

What we need is for our proxy to examine each message from the frontend to the backend looking for a message specifying a database username. When we see this message, we want to look up the username in a table and check what IPv4 address(es) this username can connect from. If it is allowed to connect, then continue on as before, otherwise, send the backend a quit message, and send the frontend an appropriate access denied message type.

Clearly, this requires being able to determine the IPv4 address of the connecting client.

For each such attempt, a file of usernames to IPv4 address mappings should be opened, read in and then closed. Opening the file on each access attempt allows dynamic updating of the rules as to who can connect in from where without having to stop and restart the proxy, or sending it a SIGHUP signal. The name of the file to open and read is passed as a new command line argument (in addition to the arguments for part 1):

• -c config file

The format of the file containing username/IP number pairs is as follows:

username1:a.b.c.d/x # comment
username2:e.f.g.h/y
...

Lines not meeting this format can be ignored. Users can be listed more than once with different IP addresses, although it is not an error to list the same IP address for the same user more than once. The part of the IP address after the forward slash is the number of bits of the IP address to match (similar to the netmask). If there is no matching entry for a specific user for the clients IP address, then that user is implicitly denied access.

A valid access file is:

tutors:192.168.112.0/29 # matches first 7 machines in N112
bob:192.168.112.10 # only matches n112lt10 and no others
bob:192.168.112.13 # only matches n113lt13 and no others
networks:0.0.0.0/0 # matches everything

If an intrusion attempt is made (a user is denied), your proxy should close the connection to the backend and emulate the message that the backend would send for an invalid access attempt then close the connection to the frontend (client).

Your executable for part 2 should be called pg_proxy2

Graduate and Optional Extras

Graduate level students (COMP6331 and ENGN6535) need to complete "Option A" to receive full marks for the assignment. Graduate level students can attempt the other options if they want to go for extra marks.

Other students can attempt one or more of the options for additional marks if, and only if, you have completed the first two parts of the assignment.

Each option is worth 2 additional marks (2% of final). These additional marks add to the non-final-exam part of your final mark. The non-final-exam part of your final mark cannot exceed 40%.

Note: it is going to be easier to get a better mark by doing well in the first two parts of this assignment, than by cutting corners in the first two parts and then attempting these optional extras.

Option A - Access control from the database

Use the database to specify which users can access it through the proxy from which IP addresses.

The "networks" database contains a table "useraccess" which contains records with usernames and IP addresses with embedded masks. When an incoming connection is being processed to determine if the username is valid from the client's IP address, access the database directly and query this table.

To do this part, you will need to use the libpq library, documented at: http://cs.anu.edu.au/doc/postgresql-doc-8.2/html/libpq.html.

Your executable for part 2 should be called pg_proxy2a

Option B - Secure Socket Layer security

Use the Secure Socket Layer (SSL) library to encrypt incoming connections to the proxy, then pass them on, via the filter, to the database server unencrypted. A use for this would be to relieve the burden from the database server CPU of doing the encryption itself - allowing database work to proceed more quickly.

Note that PostgreSQL already implements a standard for enabling SSL-encrypted connections. Your proxy should implement this standard, so that, eg. psql can connect to the proxy using encryption and the proxy will connect to the backend database unencrypted.

Your executable for part 2 should be called pg_proxy2b

Option C - Multi-threaded proxy

Implement your proxy using pthreads so that it all runs in the context of a single process.

Your executable for part 2 should be called pg_proxy2c

Assignment Goals

This assignment is worth 20% of the final assessment.

This assignment is designed to assess:

• your ability to write and debug a medium-level network application in C

Submission

This assignment is due by 5:00pm on Friday 30th May, 2008 (end of week 12).

Submit a C file for each part of the assignment: pg_proxy.c for part 1, pg_proxy2.c for part 2, pg_proxy2a.c for option A etc. as well as any header files, common C files, a Makefile and a "readme.txt" file using the "submit" command, as for the first assignment.

The easiest way to do this is to cd into the directory with all the files that are to be submitted, remove anything else (old versions etc.) and then use:

submit comp3310 Assign2 *

(substitute the actual course code you are enrolled in for "comp3310"!)

Make sure that the "readme.txt" file includes the names, student numbers, date etc. of all the people responsible for writing the assignment submission as well as:

• a brief description of how to compile your code (should just be "make pg_proxy" etc.),
• a brief description of what your code does, and
• any special instructions on how to use your code (should only be necessary for the options!)
• any other information about your assignment submission that the markers should take into account