Paul Wernau wrote: > Hi Tony, > > Tony Nguyen wrote: >> James Carlson wrote: >>> Tony Nguyen writes: >>>> Hi Darren and all, >>>> >>>> As part of the Visual Panels project, >>>> >>>> http://opensolaris.org/os/project/vpanels >>>> >>>> we're proposing a generic firewall framework for Solaris. The >>>> framework utilizes IPfilter to provide a simple mechanism to >>>> configure a firewall on Solaris systems. > > So, after looking at this proposal in detail, I have one general > comment, briefly mentioned by Darren Reed earlier. > > Users think of firewalls in terms of services, not ports. > > Unfortunately, IPfilter has kind of decoupled higher level protocol > filtering from ipf.conf and into ipnat.conf into kernel level "proxies" > which may or may not actually proxy in the traditional sense. For some > services, like PASV FTP, to create any kind of rule that just allows > PASV FTP and nothing else, you need to create both an ipf.conf rule and > an ipnat.conf rule, even on a one interface system. > > (PASV ftp improves traditional FTP by having all connections initiated > from the client, but the server still tells the client what ports to > connect to, which are ephemeral and cover a large range.) > > I don't see anything in this proposal that talks about also configuring > ipnat.conf under the covers. > > For example, a real outgoing ftp rule has this for ipf.conf: > > pass out proto tcp from $ME to $YOU port = 21 flags S keep state > > with a corresponding NAT rule like this: > > map $MY_IF from $ME/32 to $YOU/32 port = 22 -> $ME/32 > > Note this doesn't really NAT anything, it just triggers the "proxy" to > do protocol examination and open ephemeral ports, etc. > > One may say that an all outbound-only TCP rule would cover this, as > that's the point of PASV FTP anyway. > > But if you flip that around for inbound FTP, it becomes more important. > > ipf.conf is: > > pass in proto tcp from $YOU to $ME port = 21 flags S keep state > > and corresponding ipnat.conf is: > > rdr $MY_IF $ME/32 -> $ME proxy port 21 ftp/tcp > > Once you start taking away the peer address ($YOU), then the only way to > be able to specify to allow inbound PASV ftp from anywhere, but only ftp > (port 21 and the ephemeral ports the ftp server opens up for you) is to > use both of these rules. Otherwise you need to essentially open up all > high ports from anywhere. > > Right now, IPfilter is woefully devoid of application protocol support > for things other than FTP, but there are half written "proxies", such as > the RPC proxy, that theoretically would provide this support. (There's > also a working rsh proxy, though this is really not something I hope > people are using instead of ssh.) For instance, if the RPC proxy > worked, you'd say allow RPC service <prognum> and would need to use an > ipnat.conf rule. There really should be an NFS proxy and some other > things as well. From a design perspective, I think this should be > considered, or else IPfilter should be retooled to allow specification > of services. > > FWIW, I filed the following RFE 3 years ago attempting to describe the > problem above: > > 6226373 RFE: Need higher level abstraction for ipfilter policy >
Hi Paul, Agree. This issue is one of correctness and isn't an option. A services with available application proxy should generate its NAT rules which will be made active along with the ipf rules. Thanks for pointing out this case. -tony _______________________________________________ networking-discuss mailing list [email protected]
