	Department of Engineering

University of Cambridge > Engineering Department > computing help > jpmg help

"Probes" from *.eng.cam.ac.uk machines

Introduction
"Probe" to port 113
"Probe" to random port following ftp attempt
"Probe" from a different machine than the one I accessed
"Probe" from your site, but I've never visited it

We sometimes receive complaints from individuals or organisations who believe that their machine has been "probed" (is being "portscanned", or is "under attack") by a machine within our site (machines whose hostnames are in the domain eng.cam.ac.uk - most commonly with IP numbers in the class B network 129.169.*.*).

We take all such complaints seriously, and will seek to establish precisely what has happened.

However, in a very large proportion of cases, the perceived "probe" from our machine is in fact a perfectly correct behaviour and is a normal response to a connection from your site. This document attempts to explain the mechanisms involved, and why our machines respond to your connection attempts in these ways.

We are seeing an increasing number of complaints from people as a result of reports from "personal firewall" software running on their machine. While such software can be a very useful tool in protecting systems and data on the Internet, it can also produce false alarms. In particular, some "personal firewall" packages may report as attacks connections from our systems that are in fact normal behaviour in line with Internet standards - these are, as detailed below, a response to a connection to our systems from your own system.

If you believe that you have been probed or attacked by a machine in eng.cam.ac.uk in a way which isn't covered by the explanations given below, please report the problem to eng-cert@eng.cam.ac.uk. In order to help us investigate the problem, please give as much relevant information as possible, including:

the identity (preferably the IP number) of the machine(s) in eng.cam.ac.uk that are making contact with you.
the identity of the machine(s) being contacted.
the protocols/ports concerned
the date(s) and time(s) of the contact(s): please indicate your timezone offset from GMT where applicable. Please check that your system clock maintains accurate time (to within a few seconds), to ensure that the timestamps you give are meaningful.
any system logs you are prepared to let us see relating to the incident.

"Probe" to port 113

Technical background

The ident service (also known as tap or auth) is a standard service that many internet connected hosts provide, which listens on port 113. It is specified in Internet RFC1413 .

If I run an ident service on my machine, then when someone on my machine connects to a remote service, that remote machine can query my ident server to find out who (on my machine) was responsible. The information doesn't have to be a username - it merely has to be sufficient for the local administrator to be able to work out who was responsible. Thus, when the manager of the remote machine thinks that something inappropriate has happened, they can contact the local administrator, who then has useful information with which to pursue the matter. This is particularly of use when a given computer has several or many users active on it.

What happens in cases that worry people

In the situations which sometimes give rise to complaints, a machine in eng.cam.ac.uk will be behaving as the "remote machine" in the above description. When your machine (the "local machine" in the above description) connects to our server, this will try to connect to port 113 on your machine to see if it will provide it with the ident information, so that it can be included in the logs in case we need to investigate some problem or inappropriate action.

What you may see:

When you connect to an ftp server, http (web) server, or smtp (email) server that has been configured to try to log ident information in its general access logs, you will see an attempt to connect to port 113, typically for each thing you try to fetch from the server (note that a single web page may contain quite a large number of separate things to fetch, if it includes (for instance) inline images).

Note that the connection attempt may appear not to be from the machine you think you were accessing - see the section below

"Probe" to random port following ftp attempt

Technical background

The ftp protocol (as specified in Internet Standard 0009) is a mechanism for transferring files between machines. A key feature of the protocol is that two connections are set up, a control connection over which commands and status information are transferred, and a data connection over which the actual file contents are transferred.

There are, however, two ways in which the protocol allows for the data connection to be set up. The default is for the server to set up the connection back to a port on the client that the client has told the server to use. The alternative, known as passive mode allows the client to set up the data connection to a port on the server that the server tells it about.

What happens in cases that worry people

In the cases that sometimes cause concern to people, the default ftp behaviour is being used. The concerned individual will typically attempt to ftp a file from a server, and be worried to see from their logs that the server attempted to make connections to a variety of ports on their (client) machine. As explained in the previous section, this is to be expected - the ftp client has requested the server to set up a connection to a port that it has chosen on its local machine for the data transfer, and the server is doing what it has been asked to.

What you may see:

Immediately after attempting to ftp a file from a server in eng.cam.ac.uk, you will see that machine (but notice that it may not look like the same machine - see the section below) make connections to tcp ports with apparently random numbers on your machine (different client machine operating systems tend to have distinctive port ranges in which such connections will occur).

This (as has been explained above) is the ftp server responding to your request to set up a data connection to transfer the file (or directory listing) that you are attempting to download.

"Probe" from a different machine than the one I accessed

Technical background

Machines can have more than one name, and more than one IP address. Probably the most relevant technical document describing this is Internet RFC1034 which describes the concepts of the Domain Name System (DNS).

For what we are discussing here, the most important feature of the DNS is the "CNAME" record. This allows an administrator to add an entry in the DNS that maps an arbitrary name to another "canonical" name. The "canonical" name is the official name of a machine, while various other names are set up as aliases with CNAME records pointing at the official name.

What happens in cases that worry people

In practice, this means that an administrator can create a DNS name that relate to particular services provided (eg www.site.com) and make it an alias of the real machine that (currently) provides that service (eg server1.site.com). Suppose that they now decide that it would be far better to run their web site on a different machine, they can trivially update the DNS entry so that www.site.com is now an alias of another machine (so, it would have a CNAME entry for, say, bigserver2.site.com).

What you may see:

Thus, when you try to access a web server or ftp server within eng.cam.ac.uk, you will often (for the reasons outlined above) see our machines making connections to yours. The reports you see from whatever utility is monitoring such connections will either report an IP number or a hostname. In the former case, if you use a standard utility to discover the hostname corresponding to the number, you will be told the real canonical name, rather than the alias (eg www.eng.cam.ac.uk) that you may have been accessing.

The information that can reassure you that this is what is happening is all available within the DNS - a suitable query will reveal that www.eng.cam.ac.uk has a single entry - a CNAME entry containing the name of the real machine providing the service. The mechanism for making such a query will vary according to the tool you are using to get information from the DNS

"Probe" from your site, but I've never visited it

Technical background

A web page may contain links that are not obviously apparent to you when you visit that web page. Some browsers may access those links automatically without either asking you if they should, or giving any obvious indication that they have done so.

The most common HTML tag that will cause many web browsers to do this is <IMG> . However, as documented in the relevant section of the HTML4.01 specification, there are several means for incorporating "inline" references to external documents, of which that is merely one example.

Additionally, the use of "frames" within a web page may also cause your browser to access content from web servers that do not correspond with the URL that you appear to be accessing. The use of "frames" within a web page is documented in the relevant section of the HTML4.01 specification

What happens in cases that worry people

Sometimes, people observe a "probe" coming from one of our machines, but are fairly certain that they've done nothing to trigger it because they don't believe that they've accessed any resources at our site.

All of the examples given so far in this document show ways in which a connection from one of our machines may be triggered by someone accessing one of our machines.

In this case, however, we have shown how accessing a web page on a site completely unrelated to ours may cause your browser to access one of our web servers, without you necessarily being made directly aware of this, and thus cause our server to communicate with your machine.

What you may see

For instance, the HTML snippet

<img src="http://www.eng.cam.ac.uk/images/sculptu2.gif">

could occur in a web page on a completely different site with no connection at all to our organisation. If someone visited that page with a browser that automatically downloaded images within web pages (as most do), their browser would access one of our web servers, without giving them (the user of the browser) any indication that it had done so from that particular URL. Thus the user would be unaware that they had accessed a resource from the machine www.eng.cam.ac.uk.