I'm not sure about the security of Perl vs. C, nor do I wish to start the
Jihad over this. :-)
I have heard of administrators loading compilers and what not on separate
drives and either not mounting them or physically disconnecting them until
needed. I have also heard, and done so myself, removed all compilers from
a system, compiled statically linked binaries on a duplicate system. This
way the box only has executables, and not the means to alter them.
I would imagine that this could be the debate over compiled vs. interpreted
languages. In the end the goal seems to be "give you adversary as little
as possible to work with."
As far as interpreting logs, you can use the suggestion of ssh'ing them to
another system, or have them out put to another machine via a serial
port. I have done this as a demonstration once. We used a 486 as the
firewall that sent log entries (mostly via syslog) out /dev/ttyXX which was
connected to another machine that constantly read from its serial port. I
should also note that this logging server was never attached to the network
either.
Just my 2 cents,
- Bennett
At 10:40 AM 3/14/00 +0800, 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.
...snip...
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
