Network Defense
by Rik Farrow

Tracking intruders back to their lairs makes snark hunting look easy...

During a recent security conference, a co-panelist mentioned techniques
for backtracking intruders and those who sent probes.  I was immediately
intrigued by this because I knew that what he was talking about was
nearly impossible.  A couple of quick questions as we were leaving the
hall indicated that he agreed with me.

In the old American West, train robbers would ambush trains by dragging
trees across the tracks, then swooping down on the stopped train on
horseback.  After robbing the train and passengers, they would mount
up and disappear in the wilderness.  Catching these train robbers was
next to impossible.  A favored technique was to load a couple of train cars 
up with Pinkerton men on horseback (we would call them mercenaries today),
and hope the train was robbed.  If the robbers did stop this train,
they had a big and deadly surprise waiting for them.

The Internet is a lot like the Wild West today, but with a few
exceptions.  First, there is vastly more traffic today then the
few trains and travelers in the 1800's.  Second, it is much easier for
Internet attackers to cover their tracks.  Third, hiring mercenaries
with guns to storm the attacking sites would be a very bad idea.

You can do some things that will help you, and others, backtrack
miscreants who probe or attack your systems from the Internet.  It
may still be the Wild West on the Internet, but successful posses
are not that far off.

Who Do You Call?

When it comes to tracking down intruders, the first thing you do
isn't get out the bloodhounds--it is deciding how much effort to
expend.  You do this based on the impact of the attack, whether it
will involve possible prosecution, and also based on the likelihood
of success.  And, in most cases, success is not likely.

Let's look at an example.  Imagine you are the security officer of
an organization, and you get a telephone call.  The caller identifies
himself as the network security person at a different site, and
provides you with a telephone number so that you can call him back,
as well as mentioning that he can also be reached via the contact person
in the whois database.  He has found you after being bounced from
person to person, starting with the technical contact person for
your domain.

You ask him why he has called, and he tells you that a system at
his site has been attacked from a system at your site.  He offers
to send you the log messages that lead him to this assertion, to 
which you agree.  At this point, you call the help desk, open a
trouble ticket, and share the ticket number with your remote contact.
Then you go about investigating the system at your site that is
causing the trouble.

Note what has happened so far.  Someone at a remote site needed to
find you, the security contact, so that he could deal with a problem
coming from your site.  John Ladwig, Security Architect, Networking
and Telecommunications Services, University of Minnesota, suggests
that organizations include the phone number and email address of
the security contact in the splash (opening) page of their Web
servers.  If you don't get lucky with the Web, Ladwig said, "Start
with the FIRST team-contacts list.  Failing that, try the published
NIC contacts."  The FIRST (Forum of Incident Response Teams)
Web site is www.first.org.  Other places to check including the
regional or national CERT (Computer Emergency Response Team)
organizations.

You get the NIC contact information by either using the whois
command on UNIX systems, or by using telnet to connect to
whois.internic.net.  If you are using whois, include the
domain name on the command line, as in "whois aol.com" to
discover the contact information for AOL.  If you don't
have whois, a UNIX command, then you can still access the
whois database by telnetting to whois.internic.net, and
entering "whois gte.net" at the prompt, if you needed to
find the technical contact for GTE.

Steve Romig, Campus Network Security Manager at Ohio State University,
includes law enforcement in the list of people who can help you 
find contacts.  Romig said, "The police and FBI can also help 
somewhat in finding law enforcement contacts in other countries."
Romig also advised that you "be polite, be clear about what you want,
recognize that there might be legal restrictions on what they can give
you and that they might need substantial proof before they can start
their own investigation."

You might be faced with contacting a site in another country.  Romig
pointed out that English is used widely in technical fields
around the world.  You can also try using Web sites (such as 
www.altavista.com) that provide translation services.  

As an experiment, I used the AltaVista service to translate a 
request to help backtrack an attacker, in particular, by asking
if the remote site would share logging information with me.  I first
translated this request into Spanish, which didn't look too bad to
me (although my Spanish is quite rusty).  For the acid test, I
had AltaVista translate the Spanish back into English (see Sidebar).

Bouncing Attacks

Although it is possible that someone in your organization initiated the
attack, it is actually much more likely that the real attacker is
somewhere else, and your site was simply used as a relay.  Only
very inexperienced hackers launch attacks from their home base,
although it does happen sometimes.  "We frequently see that here 
at the University, especially from incoming freshmen," said Romig.
"They typically don't repeat that mistake after the first time, 
though, since they're easy to track down."

Many sites on the Internet do not have firewalls, and do not believe
that they are at risk becaue they are public sites, such as libraries,
schools, and many research organizaitons. The truth is that poorly 
protected and secured sites make great targets for attackers seeking 
to launder their connections.  Automatic scanning software exists that
has no other purpose than looking for poorly secured sites that will
make good relays.  And one firewall product (Wingate) became a
target of scanners in 1998 because in its default configuration
it made an excellent relay for attacking other sites (see 
http://www.wingate.net/secure-wingate.htm for information on
correct configuration of Wingate).

Packets are traced back to their origin by looking at their
source address.  In attacks other than denial of service, where
no response is necessary, the attacker must either use the
real source address or use source routing so responses will
be directed back.  You can discover source addresses by examining
firewall logs, connection logs (for logins, email, and other
services), and via traffic logging systems, such as NFR (Network
Flight Recorder), tcpdump, or Argus.  Intrusion detection
systems might also help here, depending on the nature of the 
attack.

When an attacker relays his or her attack, the source address
points back to the relay system, not to the real attacker.  Remember
when I said it was a bad idea to send in the Pinkertons?  In most
cases, you would be counter-attacking an "innocent" site.  Much
better to contact them and request help.  And this takes time.

"The more organizations you [the attacker] can transit through, the more 
organizational startup friction in getting and end-to-end 
analysis of your attack," said Ladwig.  "Most likely you'll 
transit through someone with no clue (security-wise), who 
doesn't know you're there yet, and can't track you even 
once he learns of you."

"If you are calling an organization of any size whatever, realize that the
first (or first two, or maybe three) persons you'll get on the phone will
not be someone who can investigate a security incident.  This is especially
true during off-hours," said Ladwig.  And time is of the essence.

To track, or not to track

Returning to our scenario, where your site is a relay in an attack,
it makes sense to cooperate as much as possible.  The site you
are helping might someday be happy to return the favor, and, after
all, they are doing most of the work.  Also, it is good preparation
for the day when you might decide to track back an intrusion.  Nothing
like a drill to learn just how good you are at locating systems with
just a name or an IP address, and reading and comprehending log files.

But do most sites attempt to trace all probes or intrusions?  All of 
the sites I contacted used different, but similar, criteria for
deciding which incidents deserved follow-up, and do not, in general,
trace back all incidents.  One site always sends a stern "cease-and-desist"
message back to the source--which might be a relay site.  By sending
an email message to a site's technical contact you might at the least
stir them into checking the source system, and perhaps tightening
up security.  

Romig described several criteria useful in deciding how much energy
to expend in tracking an attack back to the individuals involved.
The severity of the incident, damage done, or persistence of the
attacker are important criteria.  Also important is the quality of
the evidence at hand.  "If the sysadmin has already
locked the intruder out or deleted the log files or otherwise
"tainted" the evidence, we're less likely to try to trace it," said
Romig.

Another criteria is the ability to gather more evidence.  If the intrusion
comes from a local source, such as an internal dialup or a local
ISP, "we have a better chance
of getting access to good copies of the necessary evidence to nail to
culprit," stated Romig.  Attacks from other countries make this difficult,
if not impossible.  "If the intruder used
our resources to commit illegal activities at other sites, then we
will of course cooperate fully in all possible (legal) ways to help 
track the activity back to the source."

A New Posse?

Today, things look pretty grim when it comes to tracing attacks back
to the perpetrator.  The shear size of the Internet, the international
dimensions, and the enormous number of sites with poor or no security
make investigation a daunting prospect.  While this might look good 
for the attackers, remember that in the old American West they hanged
horse thieves--partly because horses were so easy to steal and 
hanging was a strong deterrant.  Not that I am recommending hanging
hackers...but rather because I know that someone will get hurt. This
is not a game.

What can you do?  Besides strengthening your own defenses, you can
make it easier for other sites to find the person or persons 
who manage your site security, for example, by posting that
information on your Web site.  You can choose the help desk as
the point of contact if you like.  

You should also practice reading logs, tracking down your own
systems, and using sniffers (when your policy and the law
permits), so that when the time comes, you will be ready.  

Some useful URLs:
A paper by Fred Avolio about tracing email, that includes information
about using whois and nslookup: http://www.avolio.com/tracing.html 

The Network Flight Recorder site: www.nfr.net.  Note that the logs
of most IDS systems can also help in uncovering the source addresses
of intrusions.

US CERT site and paper on incident handling:
http://www.cert.org/incident_notes/index.html
Many countries now have their own CERTs.

FIRST, the Forum of Incident Response Teams; www.first.org.

[SIDEBAR]
AltaVista Web translator: an experiment in tongues.

Although I was aware of Web translation capabilities, I had never
tried any of the services.  As an experiment, I visited
http://babelfish.altavista.com/cgi-bin/translate?, and
sent a request for English to Spanish translation, and had it
translate the Spanish back to English.  First, the original
English:

"I have been probed from your site.  The source of the
probe was the address 128.16.241.2, and the attacker was
using software such as tcp_connect() from SATAN.  Could
you check your logs on that system for December 4?"

The results looked reasonable to me, but I must admit that
it has been fifteen years since as I was moderately fluent
in Spanish:

"Me han sondado de su sitio. La fuente de la punta de prueba era el
direccionamiento 128,16,241,2,  y el atacante utilizaba software
lógica tal como tcp_connect() de SATAN. Podría usted controlar su
entra ese sistema para de diciembre el 4?"

So I took the results, and passed it back with a request for
Spanish to English translation and got this:

"They have sounded to me of its site. The source of the test end
was address 128.16.241.2, and the attacker used logical software
as tcp_connect() of SATAN.  Could you control his you enter that
system for of December the 4?"

Whoops.  If you are at a University, or an organization that may
have people capable of translations, I suggest that you discover
who those people are, and if they would be willing to help you
during an investigation.  You might also consider sending both the
English and the translation.
[END SIDEBAR]