Response from unexpected source

A DNS server might report this when it receives an incoming response with a different IP address than the corresponding request. There are several causes of this.

Remember that DNS servers will "recursively" send out queries when resolving names on behalf of clients. Each outgoing request is given a unique transaction identifier; incoming responses contain the same transaction identifier.

Therefore, if a server sends request #45689 to server 192.0.2.131, but gets response #45689 back from server 192.0.2.3, then it triggers this alert.

The most common cause of this is due to proxying, caching, and dual-homed hosts. For example, the DNS server might have two IP addresses: [192.0.2.131] and [192.0.2.3]. The typical way of writing a DNS server is to not bind the sockets to individual IP addresses. What this means is that the DNS server does not know which IP address the request was received on, nor does it tell the underlying TCP/IP stack which IP address to use when sending the response. Therefore, when the DNS server sends the response, the underlying stack uses one of the IP addresses at random (which can be the wrong one).

Various errors with 127.0.0.1

Some servers are misconfigured to map this address. On the other hand, it is also a hacker technique to cause names within the hacker domain to resolve to addresses within a company (including localhost/127.0.0.1).

Zone transfers (AXFR)

A hacker is attempting to list all the DNS names within a domain. This is an attempt to "map" your network. Managers should consider using split DNS aka shadow domains, whereby the public DNS contains only those records that must be accessed publicly, but use a separate (and distinct) DNS server for internal machines. Note that some people are fairly benign. If the transfers are coming from the IP addresses 128.9.160.57 and 198.32.4.13, you might want to let them through. http://www.isi.edu/~bmanning/in-addr-audit.html.

favicon.ico

In MSIE5 (Microsoft Internet Explorer v.50), when a user adds a link to his/her "Favorites" (Bookmarks) or drags the link to the desktop, the browser attempts to retrieve an icon for it. It first searches in the same directory as the file being linked to, then walks up the directory structure until it hits the root. A lot of sites (example: Yahoo!) now supply icons for their sites.

robots.txt

Whenever a search engine (like AltaVista, Infoseek, Excite, etc.) attempts to index your site, it will first get the file "/robots.txt". If you don't want parts of your website indexed, you can put rules here. On the other hand, hackers will sometimes grab this file as well on the assumption that if you tell a search engine not to index some directories, they might be something interesting to look at. Indeed, network managers do believe that putting directories in "robots.txt" hides them, when in reality it exposes them more.

URL's beginning with http://

People occasionally see the following type of line in their webserver log:

14:03:00 192.0.2.243 GET /index.html - 200 Mozilla/4.0 - -
14:03:03 192.0.2.243 GET http://www.example.com/  - 200 - - -
	

The first is a normal line, but what is that complete URL starting with "HTTP"? This is an attempt to see if the machine supports proxying. This is how pretty much all HTTP proxies work -- they receive a complete URL, then fetch that URL for the user.

See section 5.3 for more info.

As always, these attempts are usually from scans against thousands/millions of machines rather than against you in particular. Every few months, a new exploit script is published for Linux or Solaris services, and script kiddies start scanning the Internet for that service. Most of the vulnerabilities in the services listed are buffer overflows.

Note that on Sun Solaris machines, these services usually have port numbers in the range starting at port 32770. Many other times, RPC services will have ports below 1024, on the assumption that it provides a little better security because

More info on RPC can be found in RFC1833.txt.

I've put an astrisk * next to the ones that have been seen to use the callit feature.

The problem is that many administrators simply install servers without taking these simple precautions. Spammers take advantage of this fact. They give a single e-mail to the mail server and a recipient list containing hundreds of unrelated recipients. This allows them to send huge quantities of e-mail using a slow dialup connection. This is important because once the ISPs get enough complaints, they will terminate the user's account, so they must continual get new dialup connections. It also has the effect of partially hiding the true source of the spam.

If you get error messages about relaying, that is a good thing: you've configured your server correctly. If you don't get such messages, this is a bad thing. This means that you are probably not rejecting relayed messages. Has your server seemed slow lately?

Not only do spammers hunt for open relays, anti-spam organizations do the same in an attempt to "blacklist" open relays. Some of the good guys are:

IMC

The Internet Mail Consortium reports that in 1999, roughly 17% of e-mail systems had open relays.

MAPS RBL

The MAPS RBL (Realtime Blackhole List) allows you to configure your e-mail server to blackball known open relays that send out bulk spam. It is used by a huge percentage of e-mail servers on the Internet.

ORBS

Scans the Internet looking for open relays. ORBS uses relay tests from New Zealand (e.g. manawatu.co.nz).

Not only do you receive relay attempts from spammers, you also get attempts from anti-spam organizations. There are several organizations that regularly scan the Internet looking for open relays. The most common is from "manawatu.co.nz"; don't get too upset -- they

If you do the command "VRFY root", you might be able to find out the postmaster's e-mail address. This is good reconnaissance technique.

By doing a "VRFY decode" or "VRFY uudecode", you might be able to find out some security holes in the system related to these subsystems. Other commonly scanned user names are "bbs", "lp", "demo", "guest", and "debug".

Some systems have buffer overflows in this command, either in the command itself or in the logging system behind the command. You might see entries for very long strings like "xxxxxxxxxxxxxxxxxxxxxxxx".

If you see a bunch of these in a row, you are probably being scanned by a vulnerability scanner (ISS/CyberCop/Nessus). They will generate a bunch of other junk in your logs as well.