Services automaticly change firewall rules to open access to themselfs.

Simo Sorce ssorce at redhat.com
Mon Aug 20 16:54:24 UTC 2007


On Mon, 2007-08-20 at 12:40 -0400, Jeremy Katz wrote:
> On Mon, 2007-08-20 at 16:20 +0000, "Jóhann B. Guðmundsson" wrote:
> > Any thoughts on implementing  automatically port opening for service 
> > that need to open port access in the firewall
> > as in when service is started that needs port opening it would 
> > automatically read some firewall.conf
> > file for that and open the port automatically according to those 
> > settings in the firewall.conf file
> > ( add the iptables rules automatically when the service is started and 
> > remove those rules when the service is stopped )
> > 
> > Doing chkconfig service or service service start/stop and it would also 
> > open the port for that service in the firewall
> 
> I think it's a great idea and would go a long way towards making things
> more usable.  One of the questions is do you do the firewall change on
> service start/stop or at chkconfig time.  And I'm a little bit torn on
> that one.  chkconfig time makes it "simpler" as far as not requiring
> initscript changes.  start/stop seems like it's probably more "correct",
> but would then require initscripts to call a new function on start/stop

Why should it be "more correct" to do it at start/stop ?
It seem more correct to do it at chkconfig, so that even if you stop the
service and iptables -Lv will show you what is the "normal" firewall
situation.

Letting services poke holes in the firewall is not something admins will
really love, if I set a rule to block traffic for a certain service I
_really_mean it and I don't want to have to change the init scripts or
have to reapply the rule each time I start/stop a service.

Also what networks do you plan to apply this to? (at minimum you have lo
and eth0 interfaces, and you may have also tun0 or others)
all? some? which?
(I use samba + cifs on a pair of machines and I have firewall ruels to
allow that _only_ on the vpn connecting the 2: eg. NO CIFS connections
on eth0/eth1 etc...)

Simo.





More information about the fedora-devel-list mailing list