> > X-based utilities aren't always ideally suited for server environments.
> > Remember, one of Linux's advantages is that it doesn't suffer the overhead
> > NT does because the Linux GUI, X, isn't mandatory. Providing X-based
> > tools, while nifty, reduce some of Linux's advantage. I would like to see
> > more Web-based tools, myself. (Actually, I prefer console/command-line
> > tools.)
I didn't say anything about having to install X on the firewall machine.
Why not a windows client that uses ssh, or a Linux client from another
workstation that uses ssh, to communicate with the firewall to
add/modify/delete rules?
Generally, it isn't a good idea to have X installed on the firewall, if
for no other reason than to limit the potential for exploit.
> I happen to agree (I edit the config files using emacs) - but the
> individual was complaining because there wasn't an X based config tool
> - and I was pointing out that this was part of our distribution.
I guess I should clarify. _I_ don't mind having to do it manually,
especially for a firewall. I am familiar enough with ipfwadm (much thanx
to Robert :) as well as shell scripting, editing init files, etc. But
there are several reasons the corporate world (at least my corporate
world) would like to do it graphically:
- Speed. Having to type in the actual command-line that gets executed
each time is very time consuming. Especially when the rule could be there
for only a week, then change to something completely different.
- Presentation. What am I supposed to use to show management what rules
we have? Write it out on paper each time? Surely you can't expect an
upper-level manager to view ipfwadm source to figure out what the rules
are?
- Sanity checking. My ipfwadm firewall rules look something like this:
ipfwadm -O -a a -P tcp -S ${GWHOST} ${PORT1} ${PORT2} -D \
${REMHOST} ${PORT3} ${PORT4} -W ${IFNAME}
Now, not including any syntax mistakes I might have made, this may make it
very difficult for a fw admin to check. I may have fourty hosts that my
firewall is protecting, and I would need to keep track of all this
information that may be defined in other places. I realize this situation
can be rectified, but it is not easy unless you are always familiar with
the status of the firewall. Additionally, Once there becomes quite a good
number of rules, how am I to know there aren't two rules that cancel each
other out? Or how am I to know that I'm not blocking ICMP, for example,
near the top of the file, and maybe thirty rules down allowing ICMP? An
interface to ipfwadm could do this sanity checking, and point out any
descrepencies..
- Learning curve. What happens when there are four or five firewall
admin's, controlling two or three firewalls? Are we supposed to train
four or five people on how to use the command-line interface (as well as
general firewall training, naturally) Does the firewall administrator
absolutely have to know how to do shell programming? In other words,
using a graphical version expedites the process of:
- finding the criteria to build the rule from a list, instead of
having to type it in each and every time
- facilitates administration, by providing a button to do tedious
tasks (like viewing the fw log)
- typically provides error checking, and can verify what has been
entered
- instantly disabling a service or rule, without having to go thru
the entire list looking for it, or wihotut having to add a rule
at the top that blocks it
> > BTW, Robert, it's good to see you posting again. You've been silent
> > too long.
>
> Needless to say, I will be around the lists when time permits - but I
> can assure you that working at Red Hat ensures you have no time to get
> bored :-)
Good to see you around again, and hope to see you at the Expo...
Dave
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
