Methinks John Gateley <gateley @
jriver .
jriver .
com> wrote:
>On Wed, 30 Oct 1996, Frank Willoughby wrote:
>> At 10:58 AM 10/30/96 -0600, you wrote:
>> ... Putting the Web & Mail Servers outside
>> of the firewall puts the servers at a very high risk...
>
>Putting web servers outside the firewall is a fairly common practice
>I believe. They are "sacrificial lambs", with good backups for restoring
>them when they have been hacked. Perhaps the mail server here is
>based on a similar idea.
John,
Thanks for your mail. You brought up some pretty good points that I
would like to expound on.
I agree that putting web servers outside of the firewall is a fairly
common practice (sadly). The problem is that it leaves the servers
pretty much defenseless and incapable of stopping a determined hacker.
Using the "sacrificial lamb" concept will ensure that manpower is
needlessly expended (restoring backups, performing damage control,
and spending utilizing internal & law enforcement resources to conduct
an investigation - of an avoidable incident.
My preference is incident avoidance. Secure the connection and let
the hacker move on to easier prey.
However, it is important to note that there are times (albeit rare)
when a "sacrificial lamb" is acutally useful. One of these is when
the company is conducting an investigation and you are running multiple
taps & traces on the extternal line going into the sacrifical lamb
and you are dumping packets (& keystrokes) for use as evidence.
Generally, this is a joint effort between the company & someone from
the law enforcement community. Hopefully, this would only be used
if something major were going down. (I wouldn't waste my time.)
>> DO NOT DO THIS AS A WAY TO LEARN ABOUT HACKER TECHNIQUES <<
While we are on the subject, there are some who profess that one
way to learn hacker techniques is to set up a sacrificial lamb
on a secure system and monitor the keystrokes of a hacker. While
this may be the secret fantasy of every Information Security Officer,
I STRONGLY recommend that this NOT be implemented. Here's a few
reasons why this should be avoided:
ONE
You run the risk of setting the stage for entrapment and risking
public embarassment to the company and legal liabilities.
TWO
If you have a secure environment (secure O/S or created a jail for
the hacker), and put up puny defenses for the hacker to blast through,
the hacker will usually bite at the bait and try to gain access to
the system. After a while (daysm weeks, months), the hacker will
eventually realize that he/she is being toyed with and that there
is no hope of taking over the system. At this point, you have invoked
the ire of the hacker who has now made it a personal issue of wrecking
havoc on your company. This is not a very wise thing to do. (Hell
hath no fury like a hacker scorned). Further, it is almost guaranteed
that no matter how secure you think your company really is, most hackers
would have little trouble in causing intense grief to your company.
My preference is to leave well enough alone and set up a secure
environment where hackers can't get through and after a while, they
will give up and go on to easier prey. Leading them on / toying with
them is a danerous move and very unproductive, IMHO.
>j
>--
>John Gateley, gateley @
jriver .
com
>En el meu menjador, ha crescut un arbre... Pere Calders, "El Arbre"
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
<standard disclaimer>
The opinions expressed above are of the author and may not
necessarily be representative of Fortified Networks Inc.
Fortified Networks Inc. - Information Security Consulting
http://www.fortified.com Phone: (317) 573-0800 FAX: (317) 573-0817
Home of the Free Internet Firewall Evaluation Checklist
|
|
