Typical firewalls offer to block inbound TCP/IP ports. But although doing so stops some programs, there's another class of programs that don't seem to be affected at all. Even blocking a few specific outbound TCP/IP ports hardly affects programs that don't respect the conventions of TCP/IP.
Much of what's necessary is to configure your firewall to handle outbound TCP/IP ports the same as inbound TCP/IP ports -- block all outbound TCP/IP ports by default, then un-block only the few specific ones you really need.
You might think of illicit programs as "trojans" on your internal network. It's impossible to keep them out. They can come in repeatedly disguised as a .TXT file, wrapped in a .ZIP file, on a student's USB FLASH/Thumb drive from home, and many many other ways. Rather than trying (and failing) to keep them out, arrange that they don't work because they can't call out.
Although this procedure will definitely work if you get everything perfect, one small goof and you could face frustrated angry users. This requires you to identify and list every legitimate use of the Internet. This may not be easy to do, and you may decide it's not worth it.
Given the risks, we did not actually implement this. It seemed too draconian, and the threat from file sharing programs seemed to be diminishing. File sharing programs with their potential very large bandwidth usage and their long shadow of making network administrators "accessories" to copyright infringement crimes are the biggest threat addressed by closing outbound ports. But more and more file sharing services are folding as they hit rough legal waters [January 2006]. And the client programs are useless without at least a few index/manager servers run by the file sharing company.
What we ended up doing instead was using traffic shaping to "strongly suggest" preferred uses. So if there is a mistake or an exception, it will run slowly but it will still run. It's annoying but not fatal, and the issue can be deferred rather than having to be handled immediately. (This strategy of demoting traffic shaping priority rather than entirely blocking the traffic is suggested by other tools too, for example the Linux application layer packet classifier "L7".) We know that this strategy allows abuses -perhaps significant- to continue. If you're very concerned about abuses and not ready to just implement traffic shaping and let the matter lie, read on.
We were ready to do this with the "ShoreWall" configuration of our Linux firewall as described below. Doing this will completely stop some illicit programs. Other illicit programs when they find all outbound ports blocked will resort to "tunnelling" over HTTP, in other words masquerading their communication as legitimate web traffic on port 80. You can take steps to slow or even stop HTTP tunnelling after you block all outbound ports.
The "default" configuration of ShoreWall isn't tight enough to reasonably restrict "bad" traffic.
What we did was change the default for outbound TCP/IP ports to block the communication.
Specifically, we changed /etc/shorewall/policies to
loc net DROP
Then we were ready to open specific outbound TCP/IP ports.
For ShoreWall un-blocked ports are specified in /etc/shorewall/rules,
which should include some of the following:
ACCEPT loc net 13 # system time sync
ACCEPT loc net ICMP 8 # ping & traceroute
ACCEPT loc net 21 # FTP control
ACCEPT loc net 22 # SSH
ACCEPT loc net 23 # Telnet
ACCEPT loc net 25 # outgoing email
ACCEPT loc net 43 # old whois
ACCEPT loc net 53 # DNS (if no name servers either in DMZ or local)
ACCEPT loc net 63 # new whois
ACCEPT loc net 70 # gopher
ACCEPT loc net 79 # finger
ACCEPT loc net 80 # HTTP world wide web
ACCEPT loc net 109 # POP2 (should never be used, but...)
ACCEPT loc net 110 # POP3 get email
ACCEPT loc net 113 # identification/authorization
ACCEPT loc net 119 # usenet (network news)
ACCEPT loc net 123 # atomic time sync (network time protocol)
ACCEPT loc net 143 # imap (an email alternative to POP3)
ACCEPT loc net 443 # https:
# probably something else
Note that doing this might stop all FTP (File Transfer Program) traffic initiated on the local network. FTP uses TCP Port 20 for its data. The initial FTP ("active mode") required that TCP/IP Port 20 inbound be open so the remote system could circle back to the controlling local system with the requested data. However typical management of firewalls balks at opening any inbound port, so the original way of doing file transfer wouldn't work. FTP "passive" (PASV) mode was created to solve this problem, so that the controlling local system originates both control and data connections and only outbound ports are used. But although the originating port is still TCP/IP Port 20, the data destination outbound port is rather random. So closing outbound ports as suggested here will stop all FTP traffic, even that using "passive" (PASV) mode, and unblocking specific TCP/IP ports won't change that.
If you really need to use FTP, get an application that will do "secure" file transfer (SFTP) over either the SSH port or the HTTPS port or file transfer over HTTP. These applications do not have the problem of trying to use random outbound TCP/IP ports, and so can still be made to work even though almost all outbound TCP/IP ports are blocked. However the FTP programs that come with many OSs are only capable of "traditional" file transfers and won't substitute for newer capabilities like SFTP, and I don't at this time know of any "freeware" sources of SFTP.
Some applications when they find that all outbound ports are blocked will next resort to "HTTP Tunnelling". Their traffic will masquerade as web traffic and use port 80. (Aplications generally use HTTP Tunnelling only as a last resort since it involves significant overhead and requires a confederate server.)
Masquerading inbound data is no problem -
all that's necessary is to construct something that looks like a web page
but in fact can be parsed to get to the embedded data.
Masquerading outbound data is a little more difficult -
the only standard HTTP request that can include significantly more bytes than just what's in a URL
is the POST request.
Simply blocking all POST requests is not a reasonable solution,
since it would not only shut down HTTP Tunnelling
but also break lots of legitimate websites.
There are two important things to know about HTTP Tunnelling:
If you want to completely shut down illegitimate network traffic and so block most outbound TCP/IP ports, the next thing you'll need to do is block most HTTP Tunnelling. (Blocking HTTP Tunnelling before blocking outbound TCP/IP ports is just an exercise in futility, as so long as outbound ports are open, almost no applications will even try to use HTTP Tunnelling.) Identifying masqueraded traffic by examining network packets using port 80 is almost impossible. Instead, the recommended approach is to block the confederate servers.
Using the logs from your HTTP Filter (I assume you have one:-),
see which servers are being visited and pick out the ones you suspect
might really be HTTP Tunnelling confederates.
Start a normal web browser and type in both the full URLs and the base URLs you selected from your HTTP Filter logs
(if for example the URL http://some.server/path/file.html is logged,
the full URL is the same http://some.server/path/file.html,
and the base URL is just http://some.server/).
If you get back a legitimate web page from the full URL, the server is not a confederate.
Next enter the base URL --
if nothing (or garbage) comes back, add that server to your suspect list and try it again tomorrow.
If the server fails to return a legitimate base web page again tomorrow,
you're justified in concluding it's an HTTP Tunnelling confederate rather than a real web server.
You can add it to your HTTP Filter's list of blocked web servers.
This procedure unfortunately takes some time; it won't work in real time,
but will probably shut down the majority of HTTP Tunnelling within a week or so.
Even if the base URL returns a real web page, the server is not absolved - it might nevertheless be a disguised confederate. When this happens, examine the returned webpage closely, incorporate other information, and use your judgment. It may be fruitful for example to search the web to check if anyone else has blocked that server. Although these techniques currently (January 2006) work reasonably well, it's possible that future enhancements to the behavior of confederate servers will render these techniques obsolete.
You may be able to shut down most HTTP Tunnelling simply by configuring your HTTP Filter to reject all numeric IP addresses. The vast majority of legitimate web servers have and use a domain "name". HTTP Tunnelling confederates on the other hand quite often do not have a domain name and instead use a numeric IP address. Simply blocking all access to all servers via any numeric IP address may block enough HTTP Tunnelling to discourage its use. (It may also block access to some legitimate websites.)
Another approach is to identify each portion of the HTTP Tunnelling traffic
by a pattern in its URL.
Generally there's a pattern that shows up in all the HTTP Tunnelling URLs
from a particular application.
(For example the string gateway.dll? may appear in some application's HTTP Tunnelling.)
This approach usually blocks only one direction or the other (not both),
but that's enough to halt the communication.
If your HTTP Filter can block URLs by pattern, you could block each piece of communication you identify.
Keep in mind though:
? may be a "special character" which needs to be "escaped".)%20.
You may also see a slash encoded as %2F and a period as %2E.
Although you'll hopefully not see it,
in theory any character in a URL can be encoded at any time,
appearing as a percent sign followed by a two digit hexadecimal number.
Analyzing patterns of network use and abuse will probably be a non-trivial task.
You may be able to do what you need just by looking at the entries in your HTTP Filter logs,
or by running some kind of summary tool on that log information.
In some situations you may need to capture and display network packets using a
network packet sniffing tool like Ethereal
in combination with a
network usage graphical display tool like etherape.
Note that such tools might require some special network wiring to the computer they run on;
by default most networks send to each computer only the packets addressed to it.
(One method uses a "hub" rather than a "switch" device
to connect the net port of the firewall, the Internet link, and the monitoring computer.
Unfortunately most rack-mounted or large network devices labelled "hub"
are really "switch"es in disguise.)
It may turn out to be exceedingly difficult to block all HTTP Tunnelling. But your goal is just to interfere with a lot of it. All you have to do is block enough to discourage users/students from using illicit applications. Once they stop, it doesn't matter that some packets from some applications would get past your blocks if they were attempted. Your goal is not technical perfection, rather it's to shape the behavior of your user/student community.
|
Location: N42 40.86' W070 50.35'
(North America> USA> Massachusetts> Boston> North Shore> Ipswich) Time: UTC-5 (USA Eastern Time Zone) (UTC-4 summertime --"daylight savings time") Email comments to Chuck Kollars |
|
All content on this Personal Website
(including text, photographs, audio files, and any other original works),
unless otherwise noted,
are available to anyone for re-use
(reproduction, modification, derivation, distribution, etc.)
for any non-commercial
purpose under a
Creative Commons License.
|