|
|
Appendix 9: Packet and Content Filtering
|
ON THIS PAGE Packet Filtering in More Depth |
>> |
This document provides some general guidance for Further Education colleges who wish to provide some form of mechanistic control of Internet usage by students. It is assumed throughout that the reader has an appreciation of fundamental TCP/IP issues. The precise implementation details for any particular product are outside the scope of this document. References to any products, commercial or freeware, do not imply any recommendation on the part of the JISC RSC for London . There are two methods that can block the ingress of undesirable material into a network; low-level packet filtering and various forms of content filtering. The distinction, although not immediately apparent, is important as it underpins much of the material which follows. The former normally operates at the network's border gateway or firewall, with criteria that can be expressed as either an IP address or a port number. This can be regarded as a fairly coarse form of control which is best suited for globally prohibiting access to a remote network, a particular type of application (e.g. Usenet News) or a protocol (e.g. NetBIOS). Excessive reliance on packet filtering can rapidly become very hard to maintain, does not distinguish between categories of user and presents difficulties in logging. In contrast, content filtering attempts to predict or identify the type of material (be it obscene images, an infected executable or whatever) and takes certain predefined actions when such is encountered. As an example, consider how one might cope with two unpleasant situations, both related to e-mail:
The first situation is one that calls for a categorical refusal to accept any further messages from the offending mail server until such time as the site's postmaster has secured it from acting as an open relay. This would be best achieved by identifying the remote server's IP address, and then instructing either your own mail server to refuse any further connections from it or to block any inbound traffic from that address at one's border router. This is a packet filtering solution, because one is refusing any packets, regardless of content, from a specified IP address (or maybe even an entire network!). In the second example, the infected status of the files some of your users have been sent is clearly not the fault of any one remote site's mail server. The solution to the problem is to install and configure some software which will pass any files attached to an inbound mail message through a virus scanner. The file is only reattached to the message if the scanner passes it. This is a content filtering approach, because one is passing the data itself for undesirable content, rather than assuming that anything emanating from a particular mail server is garbage.
Networks that are amenable to effective management in a rapidly evolving world must be implemented with such considerations in mind. The goal is for the inherent design of the network to operate in harmony with accepted security practices. By these means, the network manager spends a much smaller proportion of his time 'fire fighting' or having to plan for eventualities which need never arise. We present here some recommendations which should not readily be discounted. Implement Private IP Addresses Internally The reader will be aware that certain ranges of IP addresses are not routed over the global Internet (a full description is available from the relevant RFC [RFC 1918 Address Allocation for Private Internets]). These are termed private addresses. The original justification for having such numbers is that they are available for use within any enterprise without reference to a higher authority. These days, because of the depletion of global address space, it is most unlikely that an organisation will be assigned sufficient addresses so as to permit each internal node to have its own unique presence on the Internet. Consequently, implementation of private IP addresses is becoming de rigeur. A technique called Network Address Translation allows non-globally routable addresses to be translated into Internet valid numbers for the purpose of sending and receiving packets from outside the local network. Whilst private IP addresses allow for greater discretion with regard to the design and maintenance of the local network, they also prohibit users from running unauthorised servers on client machines. Such activity could easily compromise the college's image, the network's security and the JANET Acceptable Use Policy. Those institutions in which each node is assigned a globally routable address can, of course, create security policies which control outbound traffic, but this requires specific action on the part of the network manager and is often awkward to maintain. We conclude that running private IP addresses internally is highly beneficial in terms of both network management and security. Channel Local Clients Through a Proxy Server Distributed access to the Internet from client machines can be achieved through the use of one or more proxy servers. This machine retrieves packets from servers on the Internet on behalf of clients within the local address space. Whilst this defines the most basic feature of a proxy server, many commercial grade products offer a wide range of additional features, many of which are germane to this discussion. This is a familiar technology to most people; pages that have been retrieved from the Internet once can be saved to disk so that subsequent retrievals are fast and do not consume Internet bandwidth unnecessarily. Whilst client browsers can do this in a simple-minded fashion, a proxy server's web cache can assign objects a predetermined Time to Live (TTL) value so that the cache automatically updates the objects once the cached ones have expired. One should also be able to configure a proxy server so that it too fetches pages and objects from a caching proxy. The remote proxy is frequently termed an upstream proxy. The JANET cache acts in this fashion. Operating a proxy server in this manner can significantly reduce load times and bandwidth consumption. b. Domain and Packet Filtering This topic is discussed in more detail [in the next section]. In summary, the network administrator can instruct the proxy to block access to certain sites (by domain name) or globally to block specific ports. It may be desirable to deny particular users access to the Internet or to certain Winsock applications, whilst allowing them to retain their local computer accounts. Any reasonably specified proxy server should integrate with the local domain's user database to allow this. In order to track individuals' Internet usage, a proxy server can write out each request from client machines to some form of logging database. It is normal practice that the proxy will not include much in the way of analysis tools for these logs. It is expected that the network administrators will apply third-party analysis and reporting tools to these logs. For example, the logs could be written to a database with an ODBC driver. Then, SQL queries could be applied to compress and summarise the data and a reporting tool such as Crystal Reports could present the data in human-readable form. As well as monitoring the activities of individual users, analysis of log files can be useful in gauging the pattern of bandwidth consumption. Monitor Traffic Through the Leased Line By maintaining a real-time record of bandwidth consumption, one can identify suspect activity. An example of how these data may be viewed is given by the ULCC Traffic Monitor. By plotting bandwidth consumption versus time, a pattern should emerge. If a burst of traffic is seen at an unexpected time, then this might indicate either an externally-mounted attack or some form of internal activity requiring further investigation. Correctly deployed and maintained automated blocking and filtering products can alleviate much of the routine work required to ensure proper usage of a network. Nevertheless, it is essential to have in place an agreed policy in which valid and invalid uses of general computing facilities and Internet connectivity are made clear. All those granted an account on the college's network should be required to sign a declaration of acceptance of the 'Terms and Conditions of Use'. This can help avoid later disputes regarding permitted types of usage. For those members of the student body under the age of majority, a parent or guardian should countersign any forms. Any form of logging of user activity, and the uses to which such logs are put, should be spelled out. This can act as a deterrent to anyone minded to misuse the facilities. Packet Filtering in More Depth Packet filtering allows one to control data transfer based on activity at the network and transport (III and IV) layers of the OSI model. Packets entering or leaving an interface are permitted to proceed provided the source or destination IP address or port numbers have not been blocked. Whilst restricting traffic flow on the basis of IP address is fairly self evident, using port numbers is less so, and an example is called for. Imagine that your college wishes to prevent access to any Network News (NNTP) server. Whilst the majority of ISP-owned news servers are restricted to the company's customer base, there are a number of publicly accessible servers on the Internet. By preventing any outbound traffic to destination TCP port 119, users would be unable to connect to any news server. This type of port blocking can be achieved in one of three ways:
To conclude our example, this type of port blocking would only prevent client news reader software from establishing a session with a genuine NNTP server. It would not prevent users from reading Usenet News via a web-based service such as Deja.com. This 'loophole' is actually not such a bad thing because Deja conveniently strips out any MIME-encoded attachments from postings. Therefore, one can safely browse the archives of comp.databases (for instance) without inadvertently downloading pornographic images that were crossposted by a news spammer. In addition to controlling users' activities, packet filtering can assist in protecting a network from malicious vandalism. The subject of network security is a vast and often complex subject. Whilst it cannot adequately be covered in such a brief document, a germane example is discussed. During the early years of the Internet's predecessor networks, traffic on certain of the 'small' ports (less than 20, used for ftp-data) served some moderately useful purposes. These days, such ports are a historical anachronism and are sometimes exploited by crackers. By dispatching specially crafted packets on these ports, a node running a vulnerable operating system can either be crashed, rebooted or a race condition can be initiated. For example, MS Windows® NT was at one time highly vulnerable on the character generator port (19). By denying the ingress of any packets on port numbers less than 20, even if there are vulnerable nodes present on the network, they cannot be exploited from outside. Of course, such an approach does nothing to combat local vandalism, and so vital nodes should always be secured as far as is practicable. For those colleges within the Greater London area, we can offer tailored advice in this area. All colleges are also entitled to seek assistance from the JANET CSIRT (Computer Security and Incident Response Team). A JANET primary site that has been the victim of an attack should report the matter to the CSIRT, as they actively collate such incidents for the benefit of the community as a whole. Having touched upon the uses of packet filtering, this section concludes with a warning of the likely consequences of an over-zealous (or ill-informed!) approach to the topic. The principle danger is that one can inadvertently block users from sites that they might legitimately wish to visit. Consider the following example. A college wishes to prevent its users from accessing the Internet Relay Chat (IRC). Unfortunately, IRC servers do not all operate on a single well-known TCP port and will actually accept connections from a wide range of ephemeral ports (the ports 6660, 6667 and 7000 are commonly used). One might therefore be tempted to create an ACL entry that blocks any outbound traffic where the destination port is greater than 1023. Whilst this would undoubtedly make IRC unusable, it would also have the unpleasant side effect of causing frequent failed connections to FTP servers, particularly if a web browser was being used client-side. The reason for this is evident in the explanation of how FTP works in the appendices below. It should be stated that this is not necessarily the only undesirable side effect! Content Filtering in More Depth Two types of undesirable content may be identified; online material of an obscene or otherwise inappropriate nature and downloaded files which somehow damage the college's investment in ICT. These two issues are dealt with separately. Most educational institutions are becoming increasingly concerned that Internet access, provided to students for study and research, is instead being used to access or promulgate materials of an objectionable or illegal nature. Whilst facilities inherent in any quality proxy server will allow specific domains to be blocked, it is clearly impossible for the IT staff proactively to restrict access to any and all such sites. A variety of commercial tools are now available which address this vexed issue. For those institutions that have deployed Microsoft Proxy Server, third party developers are now offering a selection of 'plug in' modules that seamlessly integrate with the proxy and maintain an updated list of banned domains. This is achieved in a similar fashion to anti-viral products that can be configured to download new virus signatures from the manufacturer's FTP server. Guarding Against Viral Intrusion A related consideration is protecting the college's investment in ICT from malicious content such as viruses, destructive ActiveX controls or Java applets. Potential portals for these include accessing a WWW page, the 'DCC Send' facilities of IRC or by executing a file received by e-mail. An obvious first-line defence is to install quality anti-virus software on each client workstation and server. The choice of product for deployment in a networked environment will be partially guided by the provision of centralised management and alerting facilities. The author has found that Sophos provides software which matches or exceeds most requirements. Binary files attached to e-mail messages are an increasing source of viral infection. Whilst this can be yet another method of disseminating traditional types of virus, it has stimulated a rash of 'viruses' that exploit the programmability of office suite software and e-mail clients. For example, the notorious 'Melissa' virus propagated itself rapidly by interrogating the infected machine's Outlook address book and mailing itself onwards. The simple programming interface of, for example, Microsoft Office programs has encouraged a large base of amateur virus writers who lack the programming ability to create more traditional types of virus. Consequently, a large proportion of infections now emanate from documents or small Visual Basic Scriptlets (VBS files), rather than the more easily avoided executable binary. The best method to reduce the risk of such documents and files entering the network via e-mail is to interface the mail server with anti-virus software. By these means, any files attached to an inbound mail message will be temporarily detached and relayed to the virus scanner. Provided no infection is detected, the file(s) will then be re-attached to the mail message which will be delivered to the user's POP mailbox in the usual manner. Certain mail servers (mainly for the Windows® NT platform) have the ability to interface with a virus scanner natively (i.e., no expensive middleware being required). The author has successfully achieved this with NTMail; doubtless other mail servers offer similar functionality and the reader is encouraged to consult the documentation for his chosen mail server and virus scanner. For those mail servers lacking any such ability, one possible solution is to use some middleware which acts as a broker between the mail server and the virus scanner. Often, these packages are themselves cut-down mail servers which understand Simple Mail Transfer Protocol (SMTP) but which have many additional features concerned with content filtering built into them. One such product is Content Technologies' MailSweeper software. Many institutions will wish to prevent specified classes of user from downloading any files from Internet servers onto client workstations. This is usually perceived as necessary so that the hard drives of client machines remain uncluttered and in a consistent state. A packet filtering approach (e.g. using an application proxy) can be of some use by denying access to FTP, but this would not necessarily block files downloadable by HTTP. If all the client machines are running an operating system (e.g. Windows® NT Workstation or some flavour of UNIX®) which allows for setting file permissions, then directories on the local hard drive should not be world writable. The user is thus obliged to save downloaded files to his networked home directory. This has several advantages:
The above approach would still permit files to be downloaded (albeit to a specified location). An alternative is to roll out a customised version of the college's preferred browser. The Internet Explorer Administration Kit (IEAK) and Netscape Browser Distribution Program (BDP) allow many options to be set to predetermined values, which users cannot change. For example, the Internet Explorer 'Security Zone' settings can be customised so that the browser denies students the ability to download files whilst allowing staff this privilege. Through categorising the methods by which undesirable material can enter a network, we have described a variety of mechanistic techniques which can assist in their rejection. Many colleges are likely to consider such approaches to be most useful for coping with externally initiated connections (e.g. from remote mail servers) which cannot constantly be monitored. By combining the above techniques with ensuring that student access is limited to machines in supervised areas, potential internal abuse of the facilities can readily be deterred. The following sections provide greater detail on topics which, although incidental to the main thrust of this document, provide useful additional information. Network Address Translation (NAT) This is the process by which private internal addresses are translated to globally-routable numbers so as to allow privately-addressed nodes on the network to have a presence on the Internet. There are two forms of NAT. Static A specified internal address is mapped to a specified external address in a one-to-one fashion. This ensures that the node retains the same 'identity' on the Internet at all times. It is best suited for servers whose function requires that they be able to accept externally initiated connections. Dynamic A small pool (often just one suffices) of globally unique addresses is created. The router exploits port numbers to overload multiple inside IP addresses onto this single external address without loss of performance. A maximum of about 4000 inside addresses can be mapped to one outside address in this manner. The node which performs this translation requires a presence on the internal and globally routable networks. The FE colleges connecting to JANET are entitled to be supplied with a Cisco® router which has this capability. There are two modes in which FTP can operate; regular and passive. Regular mode FTP operates as follows:
Where the conversation between server and client can be impeded only by packet filters, this works well. However, when FTPing through an application proxy, it is usually required that the client initiate the connection to the FTP server, not the other way around. This is also arguably more secure. Aside from firewalls, some FTP applications (like web browsers) are designed to only use passive mode FTP because they may use application proxies. This alternative mode works as follows:
In summary, the only real difference between regular and passive FTP is who opens the data connection. |
<< |
MANUAL CONTENTS
|
|
|
© The JNT Association - Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0SG. Tel: 01235 822200 Fax: 01235 822399
