ipfw changes being contemplated..

[AT Matik]

On Wednesday 18 April 2007 21:22, Julian Elischer wrote:
> AT Matik wrote:
> > On Wednesday 18 April 2007 18:08, Julian Elischer wrote:
> >> Also One possibility of 6 would be to make a family of
> >> firewalls rather than one, that work together,
> >
> > Hi
> >
> > probably I do not understand what you are trying to achieve ...
> >
> > basicly I am missing a reason for this "making it complicated"
> >
> > the beauty of ipfw is it's easy use and easy to read, short, it is clear
> > so why do you want to complicate it?
> >
> >> e.g. L2FW (layer 2 firewall) that knows about MAC packets etc
> >> but calls IPFW for ip packets should it want to do so.
>
> this comes from working within ipfw.
> there is a bit of "mess" added to make it (an IP layer firewall)
> know about and handle link level packets.
>
> It might be cleaner to have a separate link level firewall
> then to have the hacks in ipfw to make in know about L2 stuff.
>
> This is not something I'm working on, just something that occurs
> to me every time I have to look inside the firewall code.
>

I think it is better for me to understand and wait for what you wrote in 
another mail: 

> "I think I'll firm up my proposal a bit before trying to explain too much 
more"



> > that is perfectly possible today as it is
>
> I KNOW it can do it.. but it is a mess as far as information scope is
> concerned.
>

you mean logging? good there are some missing points today but adding better 
log sensus does not need a general ipfw change right?



> >> IPFW in turn the ability to call TCPFW
> >> for some sessions and TCPFW would know about
> >> modules that in turn know about different
> >> protocols.
> >
> > you can perfectly write sh functions which you call under certain
> > circumstances, there is no need to reinvent the wheel
>
> you can write sh functions in ipfw?
> I don't get your point here.

ah you know what I mean, not in ipfw but in the ipfw script you can use any sh 
programming you want and use it 


>
> >> IPFW could be called from the IP layer, or from the FW of a lower layer.
> >> each layer would have the ability to do some inspection of the payload
> >> to help decide which higher layer might be relevant.
> >
> > please give a real world reason and/or example for this need, which then
> > of course could not be solved be actual ipfw functions or rc.firewall
> > script engineering
>
> I work on a product that monitors on a bridge and at the IP router level.
> We have some of our own changes to ipfw.
> the rules get to be fairly tricky when you have so many
> entry points coming into the same firewall.
> front, but if I use a  "keep state" for a packet at one
> layer then I can not use "keep-state" in another
> situation for anything that may see the same packet as there is no way
> to keep separate states for different entry points.
> having separate firewalls for diffrent entry points allows me to
> have different state at different layers even for the same packet.
>

I don't know if skipping ip packages to one point and layer2 packages to 
another is not exactly what this is about, I also do not know how you can 
achieve statefull firewall on layer2 packages, sounds kind of nasty to me

look, anyway this seems to become then a product hard to understand for most 
users

I really like to repeat that ipfw is one of the best application we have 
because of it's straight forward logic, easy to understand by anybody ( since 
the beginning). And overall it is working. Nothing is perfect but changing it 
would be a wrong decision. Changing how it works will bring lots of problems 
and obviously bugs and bugs and bugs. Imagin how many people want to hang you 
if their production servers do not firewall anymore. I only remember a small 
thing like the proto ip versus proto ipv4 thing which was not well announced. 

Anyway, enhancements (if really) can be interesting but only so long as they 
do not touch any of the actual functionality and logic. Otherwise you better 
write a ipfw_nested fork to do what you pretend to do and then it is up to 
the people use it or stay with what they are used to.



João







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br