This wide- and large- screen layout may not work quite right without Javascript.

Maybe enable Javascript, then try again.

Chuck Kollars` Personal Home School PC Administration

< Upvote >

Blocking All(??)
Out bound TCP/IP Ports

One way to completely block communication with a particular website (actually all communications with that server), is to simply find out its IP address, and add that address to your list of forbidden computers wherever you keep it: your Firewall, any version of Windows, or Linux. (Note the exact procedure and names for accessing and using Linux packet filtering differ hugely between distributions [and sometimes even between versions]. Instructions for a different distribution than you have will almost certainly not work and will very likely create a big mess. Also note the procedures for making temporary immediate iptables changes are almost always significantly different from the procedures for making persistent changes.) Sometimes one web server name rotates among several IP addresses, in which case you need to add all those IP addresses to your list of forbidden computers.

Another way to completely block all communication with a particular site is to locally set up a bogus IP Address for it, as detailed in the simple site blocking section below. This works well, but is fairly easy to bypass, so it's probably not suitable if some of your users actively attempt to get around your restrictions.

(Blocking TCP connections does not require blocking outgoing packets — as TCP always sends control information both ways [even when data is only flowing in one direction], blocking just incoming packets is sufficient to prevent a connection from ever being established, thus stopping all communication before any data at all can be sent either way. In other words, for blocking the TCP (not UDP) protocol by blocking packets [something many but certainly not all firewalls do], it doesn't really matter who tried to initiate the connection.)

Blocking file sharing software by technical means is quite difficult. And even if it works, it will have to be done all over every few months (because the software changes its method of operation so frequently). It may work better to enforce the non-use of file sharing software by non-technical means (such as confiscating any computer —no excuses— on which file sharing software is found).

This document is mainly about the very unusual strategy of blocking almost all outgoing ports in order to completely stop a whole class of activity such as IM or P2P. (Although it may appear to you on the surface that the only legitimate use of your computer is web browsing, actually many different TCP/IP ports [not just port 80] are involved under the covers.) This draconian action of blocking almost all outbound ports is highly fraught and is not recommended in most cases.

If you came here instead because you want to block a specific site or specific ports, see the section on simple site blocking below, or refer to your own firewall's documentation (which may be the best reference available to you).

Incoming ports are far far more of a security risk than outgoing ports, and should get almost all of the attention. Blocking all unused ports, both incoming and outgoing, may indeed be theoretically correct. But from a practical standpoint, it risks serious loss of computer functionality, is probably not cost-effective, and invites anal-compulsive whispers.

(This discussion applies to most generic firewalls. However, the software firewall built in to Windows XP and earlier could not block inbound and outbound ports separately. So it used to be that really fancy firewall configurations required an additional separate firewall, such as the one built into almost all "router" boxes. Such extensive firewall functionality is built in to Linux, and also to some extent into more recent versions of Windows.)

(If you are using the Shorewall/IPtables firewall on Linux, you may wish to reference the Shorewall documentation itself. For your convenience though, here is a brief example of how to close individual ports with Shorewall: simply add one or more lines like this to /etc/shorewall/rules and restart the firewall.

      DROP loc net tcp 7201	# TCP port 7201 may be used by NetMonitor, which we consider illegitimate

This example assumes your Shorewall "zones" are named loc [your local network], net [the global network, i.e. the Internet via your ISP drop], and fw [the firewall machine].)

Simple Site Blocking

A common need (not really related to the main thrust of this page, but...) is to block both all authorized and all unauthorized communication —both attended and unattended— with a particular site: no cookies, no tracking, no clickstream, no database access, no advertisements, no script inclusion, no web content, no referrals from other websites, no receiving shared files, no sending copies of local files... Furthermore, it's common to want to do this by name rather than IP Address.

This is done easily by some widely distributed privacy tools. The technique does not rely in any way on any firewall, nor does it attempt to block either packets or connections, either inbound or outbound; rather it simply locally supplies a bogus IP Address for the suspect site. (This is approximately the same technique that the proposed SOPA and PIPA would have used. Although the technique could easily have terrible unintended consequences if done at a high level affecting the entire Internet system all at once [as SOPA and PIPA would have done], it's reasonable and works quite well at the much lower level of individual computers.)

This technique works pretty well for stopping malware (except for the possible limitation described at the end of this section). However it's easy for human users to circumvent when they want to. Thus it's not appropriate if some of your users actively try to circumvent your restrictions.

All that's involved is adding lines to your existing hosts file (on Windows systems, the typical location of that important configuration file is C:\WINDOWS\system32\drivers\etc\hosts). Add a line with the bogus IP Address and the name of the site:

# existing "hosts" file
# ...


The IP Address does not need to be adjusted on different computers; it works equally well everywhere; the IP networking protocol defines it as the loopback address, and it's often referred to by its standardized name localhost. Using the name of the site (provided the site has one, a few really bad sites don't:-) is a little easier than finding out the site's IP Address(es) (and it automatically handles the special case of one name being load shared by several different IP Addresses).

Often a site will be reachable by more than one name. If so, you will need to add each of the other possible names after the first one (all separated by spaces). For example, typically an added line will look like:

This technique is sufficiently common that some malware expects it, looks for it, and even tries to undo it. So it may be prudent to make a backup of your modified hosts file, and to set the attributes of the file to read-only.

This technique works for all attempts by all applications to reach a site by name, but not if a site is reached by IP Address instead - something that occasionally some software will try to do.

Blocking All Outbound TCP/IP Ports

Typical firewalls offer to block inbound TCP/IP ports. But although doing so is usually the correct thing to do, and stops most programs, there's a class of programs that don't seem to be affected much at all. Even blocking a few specific outbound TCP/IP ports hardly affects programs that don't respect the conventions of TCP/IP. This page is about various ways —beginning with blocking almost all outbound ports— to stop such illegitimate programs.

(In order to maintain its networking infrastructure, TCP/IP routinely performs a whole lot of activity that isn't "visible". So even though it may appear to you the only legitimate use of your computer is in browsing the world wide web, there's actually a whole lot of "under the covers" networking activity going on on ports other than the world wide web ports [80 & 443]. Blocking communications by TCP/IP port stops both "visible" and "under the covers" activity, and so will frequently interfere with legitimate computer use in unforeseen ways that don't seem to make much sense.)

Much of what's necessary is to configure your firewall to handle outbound TCP/IP ports the same as inbound TCP/IP ports -- use your firewall tools (IPtables? Shorewall? Firehol?) to block all outbound TCP/IP ports regardles of protocol by default, then un-block only the few specific ones you really need. Which ports are actually needed differ from one network to the next. You may need to log and analyse previous activity to find out which ports you need, or you may prefer to start with this list, then make additional tweaks as your experience requires.

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. You may choose rather than trying (and failing) to keep them out, to arrange that they don't work because they can't call out.

What's An Out bound Port?

Every TCP/IP connection has two "port" numbers, one at each end. There needn't ever be any confusion about which port number is being filtered, since one of these port numbers is always far more significant than the other. If your firewall just talks about a "port" without specifying which one, it's implicitly referring to the significant port number. Access to the "other" port number may be obscure, difficult, or even impossible - and it doesn't matter.

The terms inbound and outbound refer to which computer initiated the connection, not to anything intrinsic in the TCP/IP packets. If some outside computer initiates a connection to one of your computers, the inbound port generally identifies the type of traffic. If on the other hand one of your computers initiates a connection to some outside computer, the outbound port generally identifies the type of traffic. In both cases, the significant port number is the one of the computer that was the target (not the initiator) of the connection. If you "sniff" network packets, the significant port number will be called the "destination" port in packets travelling from the initiator to the target, and the "source" port in packets travelling from the target back to the initiator.

The port number on the target system is usually the only one that matters, and is often the only one that firewalls can filter on. The "other" port number (the "source" or "local" port number for outgoing connections) changes with every connection. Other than being a large number (usually five digits), it is generally random. It is of almost no use for filtering.

(An alternative way to identify which of the two port numbers on a TCP/IP connection is the "significant" one is simply to choose the smaller of the two numbers. This works most of the time, and may be easier than more formal methods of identifying which number is the destination port.)

Outbound? ...Confusing Terminology

Some sources say for TCP connections blocking packets in either direction will block all communication. Yet —depending on the firewall— specifying inbound ports may have no effect at all on connections the computer originated. What's really going on here?

For TCP, although the words packet and connection may seem to be the same thing, the difference is actually quite significant. Firewalls that function in terms of packets can stop TCP communication by blocking either inbound or outbound packets. Other firewalls that function in terms of connections work according to the idea that an outbound connection is any one that was orginated by the computer.

Linux firewall tools tend to completely hide the complexity of TCP packets and theoretically-connectionless protocols like UDP, and do everything simply in terms of connections. In Shorewall, for example, outbound connections are selected simply by specifying a different network order (for example loc→net rather than net→loc).

Our Experience

Although this procedure will definitely work if you get everything perfect, one small goof and you could face frustrated angry users. It's quite easy to break some kinds of communication (particularly those that are only used occasionally) and not even realize it. Doing 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, after prototyping and testing this strategy, we did not actually implement it in production. 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 loses its urgency so it doesn't have 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 -hopefully not significant but possibly so- to continue. If you're very concerned about abuses and not ready to just implement traffic shaping and let the matter lie, read on.

How To Block Almost All Out bound Ports

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 almost all ports blocked will resort to "tunnelling" over HTTP, in other words masquerading their communication as legitimate web traffic on ports 80/443. (Usually you cannot simply block destination web ports 80/443 [nor Domain Name System port 53], because doing so would shut down legitimate as well as illegitimate traffic and you would lose access to the world wide web.) You can take steps to slow or even stop HTTP tunnelling after you block almost all outbound ports.

The first and most important step is to change the default for all outbound TCP/IP ports to block the communication. (The "default" configuration of ShoreWall isn't tight enough to reasonably restrict "bad" traffic.) Specifically, change /etc/shorewall/policies to

      loc net DROP

Then the second step is to open only the specific outbound TCP/IP ports that you intend to use. (Identifying all legitimate outbound ports can be quite difficult, as even what seem nothing more than simple actions usually involve many different ports. For example, just web surfing typically involves not only plain HTTP, but also other ports for Secure HTTP, name service, video streaming, audio streaming, time sync, identification, etc.) Each computer has its own list of legitimate outbound ports, depending on exactly which programs that computer occasionally runs. For ShoreWall, un-blocked ports are specified in /etc/shorewall/rules, which should typically include at least some of the following traditionally used port numbers:

      # (following lines are descriptive, but not exactly syntactically correct -
      #  see note at end of this listing about full/exact syntax)
      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 # SMTP email, possibly sending as well as receiving 
      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: (www - 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 (occasionally INbound port needs to be open) 
      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: (www - secure/ssl world wide web)
      ACCEPT loc net 587 # SMTP email sending-only
      # probably something else
      # Actual syntax required by Shorewall often needs _two_ lines per port,
      #  one line for UDP and a second line for TCP, for example:
      ACCEPT loc net udp 53
      ACCEPT loc net tcp 53

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 outgoing 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.

The Next Step: HTTP Tunnelling

Some applications when they find that almost all ports are blocked will next resort to "HTTP Tunnelling". Their traffic will masquerade as web traffic and use ports 80/443. (Applications 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 outgoing 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:

  1. It requires a confederate somewhere on the Internet. The confederate appears at first glance to be a normal web server, but in fact provides the "other end" of the HTTP Tunnel.
  2. Most HTTP Tunnelling confederate servers don't have a domain "name" and instead rely on direct numeric IP addresses.

If you want to completely shut down illegitimate network traffic and start by blocking 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 useless, as so long as some ports are open, almost no applications will even try to use HTTP Tunnelling.) Identifying masqueraded traffic by examining network packets using ports 80/443 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:

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 Wireshark (formerly 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.

DNS Considerations

The information above was originally created when name service (DNS = Domain Name System) traffic had both "from" and "to" ports of 53. More recent versions of DNS will default to using only "to" port 53 and randomize (or at least pseudo-randomize) the "from" port. This is done to increase security if the DNS server is authoritative for any publicly accessible domain. Since the filtering suggested above looks only at the "to" port, the idea of closing almost all outbound ports remains valid and unchanged even with the newer default behavior of DNS.


Location: N42 40.86' W070 50.35'
 (North America> USA> Massachusetts> Boston> Metro North> 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 on individual webpages, are available to anyone for re-use (reproduction, modification, derivation, distribution, etc.) for any non-commercial purpose under a Creative Commons License.