[unisog] Access lists for dorms

John Kristoff jtk at northwestern.edu
Sat Dec 10 04:41:05 GMT 2005

On Fri, 9 Dec 2005 15:44:05 -0600
"Rob Becker" <rbecker at kcai.edu> wrote:

> tcp port 80 to a few webservers that students will need to access.  I
> would like to also add some access lists that will keep our student
> traffic out to the internet as clean as possible from a worms/viruses
> standpoint.  Does anyone have suggestions as to ports that should be
> blocked outgoing to minimize botnet and other malicious traffic?  I

These kinds of threads tend to bring out the worst in security in my
opinion.  Allow me to throw some caution to the wind on advice you're
receiving and some additional food for thought.  You're free to do what
you want of course, just trying to help you be precise and cognizant
in what you are really doing.

Know that if you simply packet filter certain protocols or UDP/TCP
ports, users may start having random, transient, undiagnosed problems.

To illustrate with an example, say you decide to packet filter all TCP
packets with a source or destination port 1434.  Eventually source port
1434 is going to be used by a web client.  Microsoft Windows clients
typically use source ports between 1024 and 5000 inclusive for web
browsing.  When a machine first comes up, it starts using the lowest
available source port, incrementing by one for each new connection and
wrapping at the top when reaching 5000.  Depending on the host's TCP
session creation rate over time (and depending on how frequently a
lightly used host is rebooted), port 1434 will be probably be used and
probably used and quite possibly a few times during the day for heavily
used systems.

If a user is browsing around the net and the time comes so that the OS
will select source port 1434, we can agree that in this case, port 1434
represents no ill intent.  Since this port is packet filtered however,
accessing a site on the first click won't work.  After about 10 seconds,
the 'operation timeout' alert dialog box will come up.  If the user
clicks again the OS will then use 1435 and if not filtered anywhere,
the page should be rendered.

How much of a big deal is this?  It is common for us (NU) to see a few
thousand flows in a 24 hour period between TCP port 80 and any single
port between 1024 and 5000.  That's a lot of 10 second delays (not to
mention wear on the mouse button :-).  You also have to account for any
other app that might happen to use port 1434.  There are a lot of hosts
on our network and I don't know what your's looks like, but I did a quick
check on the number of flows between port 4900 and port 80 on a lightly
populated /24 client network and I can verify that there were 3 flows
between those ports alone involving legitimate web servers in 24 hours.

To be fair, my calculation while accurate may actually exaggerate the
problem.  Many of these failed connections are often banner ads for
example.  Most people don't care about those.  So it may not be the type
of problem that generates complaints and that certainly seems to bear
out in practice.  Many people do this kind of filtering all the time.

You can possibly reduce these sorts of problems, while potentially
increasing the risk by doing things like filtering all port 1434
except with the other port is 80, 443 or XYZ.  Even better might be
to just use a stateful firewall that can also filter on common worm
payloads.  Here you can better filter based on actual service rather
than some random port number since a real firewall should be able to
understand direction and connection state as well as be able to block
common worm looking payloads.  In this latter case, you can reserve
port blocking for the extreme "break-out" cases where you temporarily
block a port until the firewall software is updated to be more
intelligent about the problem.

Something I would highly recommend you try to do regardless is setup
some kind of monitoring infrastructure.  Even if it is filter logging.
You want to know what is normal behavior so you can tell when things
are abnormal.


More information about the unisog mailing list