Comp 527: Assignment 2: Networking
up to main page
Due date: Wednesday, February 17, 1pm
Sample solution: now available
In class, we've discussed attacks and countermeasures against
everything from low-level IP protocol stacks to higher level services.
This written assignment asks you to consider some of the issues in
building a good defense.
You must work on this by yourself. Consult any written or online
sources you want and please include citations or URLs. Each question
will probably take you a page to answer plus diagrams. You may bring
your work to class, on paper, or submit it via e-mail in whatever format
you think the TA's can deal with. E-mail submissions to <comp527@cs.rice.edu>.
Question 1: Reverse Firewalls
When a malicious user buys a $19.95 account from an ISP and unleashes
havoc on the world, somebody from the ISP always ends up burning days
of time cleaning up after the damage. Design a reverse
firewall that protects the Internet from attacks
originating from inside the ISPs network. Don't forget to
protect the ISP users from each other and to protect the ISP from its
users. You should probably include a block diagram showing the
network topology and labelling all the parts. Go into detail on
the configurations of your firewalls. What ports will you let through
and what ports will you block or proxy?
Question 2: Application vs. Packet-Filtering Firewalls
Firewall vendors will argue back and forth about the right way to build
a firewall. Copy the table below and write pros and cons in every box (a
sentence or two for each box).
| Application-Level | Packet-Filtering |
| Speed (Throughput) | . . . | . . . |
| Protection Against Low-Level Protocol Attacks | . . . | . . . |
| Protection Against Application-Level Attacks | . . . | . . . |
| Resistance to Low-Level Protocol Attacks (aimed at the firewall) | . . . | . . . |
| Resistance to Application-Level Attacks (aimed at the firewall) | . . . | . . . |
| Ease of Supporting New Applications | . . . | . . . |
| Traditional Applications that Won't Work out of the Box | . . . | . . . |
Question 3: One Man's Spam is Another Man's Marketing
This is a revised version of question 3. If you answered the
original, you don't need to change your answer. The technical
problem is essentially the same.
You support the computer systems for a large, transnational
corporation. You have offices in just about every major city on the
planet, and most of those offices buy their Internet connectivity from
local providers. The human resources director has approached you
about solving a problem that has been dragging down productivity
worldwide. It seems other companies have been e-mailing employees of
your company with all manner of inappropriate material, ranging from
chain letters and junk mail through targeted messages from your
competitors trying to recruit your brightest employees. Sometimes
employees will even forward these messages around and the president
wants the problem stopped.
Design a system that can efficiently eliminate the exchange of
unwanted e-mail in your company. You can make global rules about how
individual offices operate their Internet gateways. You can also hire
a staff of censors, if you feel it's necessary. Still, you need to
automate the process as much as possible. As in question 1, include
block diagrams for how you intend to structure your corporate
network. Oh, and make sure the system can scale comfortably as your
company grows.
Question 4: Secure Login
Some of you have probably read the debate on
rice.owlnews.general about
logging into Owlnet machines, SSH, S/Key, and all that. The Owlnet
administrators have two problems they want to solve: unauthorized
account access (i.e., break-ins) and account sharing (i.e., giving
a long-distance romantic partner your account password). Here are
some of the technologies they have to consider:
- S/Key
- Based on a technique called hash chaining, S/Key generates a
list of numbers that appear to be completely random and encodes them as
words from the dictionary. No number is ever transmitted twice.
- SecurID
- Using similar techniques to S/Key, SecurID tokens do it all in
a credit card sized box. The number on the screen changes every minute.
See also challenge-response cards like ActivCard and CryptoCard (available from lots of different companies).
- iButton
- Generic smartcards and iButtons do more-or-less the same thing.
By speaking a crypto protocol, they can be strongly authenticated.
The iButton can be thought of as being just like one of the challenge-response
cards, except they will happily respond to any challenge (if they're
plugged in at the time).
Of course, not every computer has an iButton or smartcard interface
and somebody would need to hack the login programs to support them.
- SSH
- SSH sets up an encrypted connection, and can then authenticate
a user either with a traditional password (sent over the encrypted
connection) or by using public-key
cryptography (which requires the remote user to have a copy of
a string of bits called the private key). SSH sessions
are resistant to IP-level hijacking attacks.
How do each of these technologies address the problems faced by Owlnet?
How might you mix and match these technologies to solve Owlnet's problems?
What technologies are easier to deploy on campus? What about students
who go home over spring break and want to read their mail?
Assume a user sits down at a computer to log in, but that computer has
been taken over by a hostile adversary. The computer looks and feels
perfectly normal but may do arbitrarily unpleasant things in the background.
How do the various authentication technologies above help limit the damage
done after the hostile machine has been discovered and repaired?
Dan Wallach,
CS Department,
Rice University
Last modified: Thu Feb 18 00:25:20 CST 1999