Correct me if I am wrong, please.
This discussion is whether adding perl/c compilers to the firewall machine
is an additional security risk in your architecture. Well, picture this: in
your scenario somebody has just compromised the most hardened, best
monitored host on your network, without you knowing about it. How hard do
you think it would be for this individual, who has just hacked that
ultra-secure machine, to reconfigure it, and upload binaries for what he
needs. Let's take this into perspective. If somebody had sufficient skill
to compromise a properly configured firewall machine, getting stuff like
compilers and perl installed on it would be a joke. However, having perl on
that machine, actively scanning log files, could have stopped the intruder
dead in his track.
Although I strongly believe in defence in depth, I don't believe that not
having perl on a firewall is a sufficient additional security measure to
warrant being called an extra layer. At this point, it is nothing but a
VERY minor annoyance to the intruder, one he would be able to bypass quite
easily. On the other hand, those perl programs parsing your log files could
have alerted you of the break in in the first place. You decide.
-Igor
PS when I refer to a firewall, I am talking about a "properly" hardened
host running no network services, who's sole job is to decide whether it is
going to move a packet from one network card to another, and log those
decisions. If this is not what you would concider a firewall (not a
sufficiently hardened host, etc..) then perhaps you should address those
issues before takling perl/C compilers.
At 07:51 AM 3/14/00 -0500, Paul D. Robertson wrote:
>On Tue, 14 Mar 2000, Kempter, Lynda L. wrote:
>
>> To perl, or not to perl; that is the question. Literally.
>>
>> A request has been made to install perl on the firewall. (It
>> would run some system audit routines, bring it in line with the
>> rest of the internal unix systems.) Given the choice, I'd rather
>> not. Why give the hackers yet another tool to use when they
>> break into the firewall? I wouldn't put a C compiler on the system
>> for the same reason. The argument for installing perl is that it's
>> much more "secure" than something like C, and no more insecure
>> than shell scripts.
>>
>> I'd be most grateful for opinions, pro and con, from the list.
>
>I used to remove all the compilers, interpreters and scripting languages
>(incluing complex shells) from firewall boxes. These days there's very
>little to gain in it unless you're on a strange architecture. It doesn't
>take that long to install a binary of perl, gcc, python or whatever, and
>if you're on x86, Alpha or Sparc they're really easy to get, PA-RISC,
>OSFwhateveritsnameistoday, MIPS or another "almost common" architecture,
>it's a matter of a couple of extra minutes at most.
>
>I'll go out on a limb here:
>
>Most intruders run canned exploit scripts, and the majority of exploit
>code I've see is in C. gcc is widely ported enough that getting enough of
>a binary to build a new version isn't that difficult. If someone gets a
>shell on your firewall, they'll likely be able to add languages at well
>unless you're playing off of a CD or write protected floppy diskette.
>Even then you'll need to worry about RAM disks and stuff like that.
>
>If you haven't taken the time to NOSUID/NOEXEC filesystems, chroot
>programs and do group-related access control, not having an interpreter
>isn't going to help a bunch. If you have, then having it isn't going to
>hurt much. There are suggestions about doing that with the interpreter in
>this thread that are worth the time to do.
>
>If adding the interpreter doesn't give you better assurance, then by all
>means don't add it. But I really think that unless you're doing some
>significant host-based stuff anyway and logging off the wire, it won't be
>that much of a challenge to add an interpreter or compiler to a system
>that's compromised.
>
>If you're doing enough to stop that, you can tell because adding perl will
>require two reboots.
>
>Paul
>-----------------------------------------------------------------------------
>Paul D. Robertson "My statements in this message are personal opinions
>[EMAIL PROTECTED] which may have no basis whatsoever in fact."
> PSB#9280
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
