On 08/21/08 13:50, Paul Wernau wrote:
> FWIW, I filed the following RFE 3 years ago attempting to describe the
> problem above:
>
> 6226373 RFE: Need higher level abstraction for ipfilter policy
This is related to what I was trying to get at in that I think this
high level description should be in the service manifest in a neutral
format.
I.e. looking at the ftp manifest I should be able to deduce that it
will allow tcp port 21:X local:remote and while that is open tcp port
(with a hint that it should match 20:X and/or X:20) will be valid based
on some protocol "ftp". The ipfilter native part starts at knowing how
to take the "ftp" protocol and port info and turn it into the
corresponding policy.
Putting this data for local services in tool specific places (or worse
in tool specific data in the services manifest or methods) is data
mismanagement. An admin who changes the port on a service (or
duplicates a service to run on a new port) can be expected to change it
in one place (i.e. vpanels/service) no matter how many network tools
various parts of the community ship. (Though for most historical
services it must be duplicated between manifest and historical config.)
-Will
>
> Thanks,
> Paul
> _______________________________________________
> security-discuss mailing list
> [EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
