Campus or Group firewall
Our campus uses filtering on its external router
Clumsy, because sophisticated schemes use CPU and the router runs out of steam
Problems for widely distributed collaborations
False sense of security when you have more-secure and less-secure hosts together behind firewall
May be one useful weapon to block junk mail, though!
Notes:
Every campus has in effect an external firewall, even if it only consists of their external router as ours does. The router can be configured to block certain patterns of traffic (e.g any packets arriving from outside but claiming to originate from a network number that’s inside; or packets addressed to subnet broadcast addresses; etc.). Although in principle the filters can be quite fine-grained, it turns out that anything but the simplest filters have to be executed not in the routers’ line cards but in the CPU, which drastically reduces the amount of traffic that it can carry. Thus, in most cases the filtering has to be rather crude.
This kind of filtering can prove to be a problem for widely distributed collaborations, e.g our users want to NFS mount filesystems at RAL, but the campus would like to block external NFS. The campus have, in fact, blocked external rsh (and probably a good idea too), but this has inconvenienced some users who had a business process (e.g remote job submission) based on rsh.. Compared with techniques that store user passwords in clear text in disk files, r-series commands may be the lesser evil!)
The existence of a firewall should not lead one into a false sense of security; any insecure host behind the firewall could turn into a trojan horse allowing attacks to be mounted on the more-secure systems. Nowadays, someone merely opening a MIME enclosure in a mail could create a trojan horse!!
Well, there is one thing that an external router could be handy for, and that’s to block well-known sources of junk mail. No solution to a mushrooming problem, but every extra weapon is useful. However, I digress.