On Wed, 1 Apr 1998, Dave Wreski wrote:
> 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?
Good - but they don't exist and we won't be writing anything for
windows. Ssh also causes us export problems, so we need to think that
sort of thing through (there is also the ssh licence to consider).
> 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.
Dead right!
> 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.
Good point.
> - 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?
Having sold security services as a consultant, my experience has been
that showing management *anything* this technical tends to result in
their eyes glazing over. They have NO hope of understanding this stuff
unless they have more than a passing knowledge of TCP/IP. So I really
don't see this as any argument.
> - 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..
This is a huge issue. My approach was to turn each firewall rule into
a checking rule...but that presents problems as a bug in ipfwadm that
sets up a rule wrongly could return a check wrongly too...
On the ICMP issue you mention, ipfwadm and the Linux kernel firewall
capability would leave ICMP blocked - as the the first matching rule
in the list is ALWAYS applied to a packet. This is why ordering the
rules from the least specific to the most is so important in ipfwadm
firewalls.
> - 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
All good points - and they exist in commercial products like
Watchguard. Having this capability as a standad linux package would be
great - but I don't see us writing it here at Red Hat in the near
future.
Probably the best bet for this would be a linuxconf module for
establishing, checking and managing/testing an ipfwadm firewall.
> Good to see you around again, and hope to see you at the Expo...
I'm giving a paper...better finish writing it!
Robert Hart [EMAIL PROTECTED]
Red Hat Software Inc. Phone: +1-919-547-0012 Fax: +1-919-547-0024
4201 Research Commons Suite 100, 79 TW Alexander Dr., Research Triangle Park,
NC 27709, USA
--
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.
