Adam Safier[SMTP:asafier @
explorer .
csc .
com] wrote:
> At 10:44 AM 4/16/96 -0400, Chris Kostick wrote:
> >An earlier post made me think about a problem I'm sure others have
> >thought of, but I haven't seen much on it. Managing firewalls. Mostly,
> >firewalls are managed either via console (a long recommended practice),
>
> Yuck! The next "revolution/age" should let us work from home (or wherever
> we happen to have parked for the day.)
>
> >The problem is that the current
> >scheme used today doesn't fit well into an overall corporate management
> >architecture. Most large companies want an overall solution to their
> >management problem, not another interface to learn, machine to get,
> >protocol to support, etc., etc...
>
> Why should they get it with firewalls when they don't have it with the rest
> of their equipment? :( While SNMP MIBs provide some common parts for
> particular types of equipment most of us still get stuck with proprietary
> extensions to the MIB's and have to go through extensive customization to
> make the info inteligible.
That's an issue outside the scope of the SNMP protocol. All I'm talking
about is getting a secure management structure in place so that the
information can be obtained from a management platform via one mechanism.
*The* information to get is of course, yet to be determined. But that is
what MIB working groups are for.
>
> The real question is: Are the different brands of firewalls sufficiently
> similar in their configuration data that a single common MIB could be
> specified? (At least within a particular firewall type - proxy vs packet
> filter vs circuit.)
One thing at time. The protocol must be accepted first. It is true
that you may not be able to define what it means to 'manage' a
firewall in a common way. I think that's a research problem. The
question is, is anyone researching it?
>
> >So, experts of the field -- specifically the product vendors; how are
> >you solving this? Are there any ongoing conversations with Sun, HP, or
> >Cabletron, that anyone would like to share? Am I out in left field and
> >this is a not concern at all? Who am I? (wait I diverge)
>
> I don't consider myself an expert but I am interested and asked a similar
> question over a year ago. There has to be a better way. I have noticed
> that IBM added secure links and SMIT support for their NetSP product. If
> you are an AIX wizzer you would feel more comfortable with NetSP (though I
> think you still need to get down and dirty with vi and config files for more
> involved installations).
This is a single administrative interface. I'm thinking bigger here --
the management of several platforms.
>
> >I realize the status of SNMPv2 is questionable, but if the security
> >aspect(s) of it were finalized then I would think that would be one of
> >the first solutions to investigate.
>
> I think firewalls are "large" enough that they don't have to worry about a
> little extra overhead in the tranport mechanism. A firewall could use
> SNMPv2, S-HTTP, secure telnet with scripts, VPN channels or any other
> "common" transport.
They use that today. The point is, for management information, everyone
(meaning all devices) should use a common transport mechanism.
> Snmp is successfull in black boxes because it doesn't
> take much resource and is "cheap". The transport for firewall management
> also needs to be "cheap" but that is relative to the available resources.
>
> First we need to define a common firewall MIB.
No, first we need a protocol. Then we can move on. I think SNMPv2 is
our only candidate now. Please anyone, feel free to disagree and tell
me why.
> I would also like to see a
> definition of what kind of data will be displayed and, possibly they key to
> "commonality and one time training", in what formats - i.e. a baseline
> report spec.
>
> I would also suggest development in groups so vendors can implement Group 1
> right away and only add later groups as market demand and their product
> capability warrent.
>
> Lets see if I can get a start on Firewall Security Group 1:
>
> Filtering MIB
> Permitted starting at Time of Day (HH:MM)
> Permitted Duration (or should it be endin time)
> Link Protocol (MAC?)
> Network Protocol (IP, IPX,
> Transport Protocol (TCP, UDP, X.25)
> Inbound Interface - Allow into firewall for processing further
> Outbound Interface - Allow out of firewall interface
> Source IP Address, Port
> Destination IP Address, Port
>
> Password MIB
> UserID
> Authentication Protocol (S/Key, Kerberos, SecureID, V-One, etc.)
> Password/PIN - Oh oh, We'll need file encryption standards.
> Key - same as above.
>
> future items:
> Currently established session count
> Currently established connections count
>
> Services MIB
> UserID
> User's IP Address(es)
> User Port(s)
> Service permitted (HTTP, Telnet, etc.)
>
> User History MIB
> UserID
> User's IP Address
> Session count today
> Session count this week
> Session count this month
> Session count this year
> Connections today
> Connections this week
> Connections this month
> Connections this year
>
> Log File MIB
> ......
>
> There's a lot more I can think of but I have a meeting to go to......
>
> >
> >Comments, questions, debate, pizza -- all are welcome (especially the
> >pizza).
> >
>
> Sounds like a job for an IETF or whatever Firewalls standards committee. I
> don't know the rules and effort required to start one up or join but I would
> be interested in participating.
>
> If we start a new work group I propose the first rule be that pizza is
> available at every meeting. I will keep the debate about the benefits of
> it's consumption between me and my doctor.
>
>
>
> Adam Safier
> CSC-SED-Infosec
> asafier @
csc .
com
>
> Expressed opinions are my own and might not be shared by my employer or
> anyone else.
>
>
|
|
