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
Thoughts anyone.
Best regards Johann B.
Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg@hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801
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
Jeremy
On 8/20/07, Jeremy Katz katzj@redhat.com 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
Jeremy
I was actually thinking about this last night. My idea was to have it _possible_ for services to open a few ports on start, and close them on stop. But they wouldn't do so directly, they would ask system-config-securitylevel. This would allow admins to disable this functionality easily.
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.
Am Montag, den 20.08.2007, 12:54 -0400 schrieb Simo Sorce:
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.
No, in fact I would hate it with a vengeance.
If I have an apache server listening for traffic, that doesn't mean I want people outside my network connecting to it; nor do I want people connecting to my ssh server.
Why not just disable the firewall altogether? That would have the effect you are looking for: all services that are running can accept connections.
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.
Am Montag, den 20.08.2007, 12:54 -0400 schrieb Simo Sorce:
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.
No, in fact I would hate it with a vengeance.
If I have an apache server listening for traffic, that doesn't mean I want people outside my network connecting to it; nor do I want people connecting to my ssh server.
Why not just disable the firewall altogether? That would have the effect you are looking for: all services that are running can accept connections.
I run custom firewall rules. If you can get this idea to play nicely with my custom script, and with Shorewall setups, and with s-c-securitylevel, go for it. But I'm highly sceptical. If installing squid blows up my custom firewall settings, I'm getting out my pitchfork. :)
Simo.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 8/20/07, Jon Ciesla limb@jcomserv.net wrote:
Am Montag, den 20.08.2007, 12:54 -0400 schrieb Simo Sorce:
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.
No, in fact I would hate it with a vengeance.
If I have an apache server listening for traffic, that doesn't mean I want people outside my network connecting to it; nor do I want people connecting to my ssh server.
Why not just disable the firewall altogether? That would have the effect you are looking for: all services that are running can accept connections.
I run custom firewall rules. If you can get this idea to play nicely with my custom script, and with Shorewall setups, and with s-c-securitylevel, go for it. But I'm highly sceptical. If installing squid blows up my custom firewall settings, I'm getting out my pitchfork. :)
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
On Mon, 2007-08-20 at 12:33 -0500, Arthur Pemberton wrote:
I run custom firewall rules. If you can get this idea to play
nicely with
my custom script, and with Shorewall setups, and with
s-c-securitylevel,
go for it. But I'm highly sceptical. If installing squid blows up
my
custom firewall settings, I'm getting out my pitchfork. :)
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
I think the ideal solution would be to use existing protocols (UPnP, NAT-PMP) to talk to a daemon (avahi-daemon for example) that is configured with basic policy settings (accept requests from this user, IP, interface, etc) and could also talk on DBUS for GUI prompt type stuff. The daemon would have config options to specify what chains to alter, so that it can be made to work with other firewall scripts easily and obtrusively. By using existing protocols, the exact same mechanism can work with home routers and such, and likely even SOHO 'firewalls'.
Besides that, a lot of programs already have support for standardized protocols. Sure, for a totally local-only type of thing, it's a larger number of hurdles to jump through, but then it can be the same hurdles for local-only vs small-LAN, and potentially even larger LANs.
On Mon, 20.08.07 15:19, David Hollis (dhollis@davehollis.com) wrote:
On Mon, 2007-08-20 at 12:33 -0500, Arthur Pemberton wrote:
I run custom firewall rules. If you can get this idea to play
nicely with
my custom script, and with Shorewall setups, and with
s-c-securitylevel,
go for it. But I'm highly sceptical. If installing squid blows up
my
custom firewall settings, I'm getting out my pitchfork. :)
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
I think the ideal solution would be to use existing protocols (UPnP, NAT-PMP) to talk to a daemon (avahi-daemon for example) that is configured with basic policy settings (accept requests from this user, IP, interface, etc) and could also talk on DBUS for GUI prompt type stuff. The daemon would have config options to specify what chains to alter, so that it can be made to work with other firewall scripts easily and obtrusively. By using existing protocols, the exact same mechanism can work with home routers and such, and likely even SOHO 'firewalls'.
Actually someone has started to work on a NATPMP client and server for inclusion in Avahi:
He usually lurks as "tedp" on #avahi on freenode.
Lennart
On 8/20/07, David Hollis dhollis@davehollis.com wrote:
On Mon, 2007-08-20 at 12:33 -0500, Arthur Pemberton wrote:
I run custom firewall rules. If you can get this idea to play
nicely with
my custom script, and with Shorewall setups, and with
s-c-securitylevel,
go for it. But I'm highly sceptical. If installing squid blows up
my
custom firewall settings, I'm getting out my pitchfork. :)
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
I think the ideal solution would be to use existing protocols (UPnP, NAT-PMP) to talk to a daemon (avahi-daemon for example) that is configured with basic policy settings (accept requests from this user, IP, interface, etc) and could also talk on DBUS for GUI prompt type stuff. The daemon would have config options to specify what chains to alter, so that it can be made to work with other firewall scripts easily and obtrusively. By using existing protocols, the exact same mechanism can work with home routers and such, and likely even SOHO 'firewalls'.
Besides that, a lot of programs already have support for standardized protocols. Sure, for a totally local-only type of thing, it's a larger number of hurdles to jump through, but then it can be the same hurdles for local-only vs small-LAN, and potentially even larger LANs.
Even better. All I ask is that more control over the security of the system is given to s-c-secuirtylevel. I like the console, esp. on a server. But when assisting people it is often convenient to point them to the appropriate GUI.
On Mon, 2007-08-20 at 12:33 -0500, Arthur Pemberton wrote:
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
That would be a checkbox.
[ ] Trust all enabled services.
Basically, what this means is, "don't allow incoming traffic except where root says it's ok", which might sometimes be what you want to achieve.
If there's some easy way to include this service-generated "white list" in a specified place in a custom firewall configuration, that could perhaps be useful.
/abo
On 8/31/07, Alexander Boström abo@kth.se wrote:
On Mon, 2007-08-20 at 12:33 -0500, Arthur Pemberton wrote:
Hence why I suggest doing this through s-c-secuirtylevel so that that functionality can centrally be disabled
That would be a checkbox.
[ ] Trust all enabled services.
Basically, what this means is, "don't allow incoming traffic except where root says it's ok", which might sometimes be what you want to achieve.
If there's some easy way to include this service-generated "white list" in a specified place in a custom firewall configuration, that could perhaps be useful.
By the way, I still think that tis is a good idea.
"AP" == Arthur Pemberton pemboa@gmail.com writes:
AP> On 8/31/07, Alexander Boström abo@kth.se wrote:
That would be a checkbox.
[ ] Trust all enabled services.
Basically, what this means is, "don't allow incoming traffic except where root says it's ok", which might sometimes be what you want to achieve.
AP> By the way, I still think that tis is a good idea.
It would be nicer if the bind() failed in the application. At least the application would have a chance at telling the user what went wrong, instead of just not working properly.
/Benny
On 9/1/07, Benny Amorsen benny+usenet@amorsen.dk wrote:
"AP" == Arthur Pemberton pemboa@gmail.com writes:
AP> On 8/31/07, Alexander Boström abo@kth.se wrote:
That would be a checkbox.
[ ] Trust all enabled services.
Basically, what this means is, "don't allow incoming traffic except where root says it's ok", which might sometimes be what you want to achieve.
AP> By the way, I still think that tis is a good idea.
It would be nicer if the bind() failed in the application. At least the application would have a chance at telling the user what went wrong, instead of just not working properly.
/Benny
Starting services don't normally give error messages. Certainly not if you use s-c-services
On Sat, 2007-09-01 at 09:34 +0200, Benny Amorsen wrote:
It would be nicer if the bind() failed in the application. At least the application would have a chance at telling the user what went wrong, instead of just not working properly.
I think using SELinux instead of ip(6)tables here would achieve that.
/abo
On 9/1/07, Alexander Boström abo@kth.se wrote:
On Sat, 2007-09-01 at 09:34 +0200, Benny Amorsen wrote:
It would be nicer if the bind() failed in the application. At least the application would have a chance at telling the user what went wrong, instead of just not working properly.
I think using SELinux instead of ip(6)tables here would achieve that.
/abo
Not everyone uses SELinux. Everyone (almost) uses iptables.
"AP" == Arthur Pemberton pemboa@gmail.com writes:
AP> Not everyone uses SELinux. Everyone (almost) uses iptables.
Applications already know how to ask for incoming connections. It's generally done by calling bind().
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
The whole point of firewalling is to explicitly specify what should be allowed and denied. If you take away that control, there is no reason to have firewalling.
/Benny
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
I think the idea of having some way to help people who want a service available to the internet at large or some local ip addresses is a good idea, but it needs to be an add on step that can be skipped, not some invisible change behind the scenes.
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
So being able to easily disable this wouldn't be enough?
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
This is something that would/should work only if you're using system-config-firewall
I think the idea of having some way to help people who want a service available to the internet at large or some local ip addresses is a good idea, but it needs to be an add on step that can be skipped, not some invisible change behind the scenes.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sat, Sep 01, 2007 at 12:05:00 -0500, Arthur Pemberton pemboa@gmail.com wrote:
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
So being able to easily disable this wouldn't be enough?
I don't think so. I thought making it easy for people to shoot themselves in the foot was the Microsoft way.
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
This is something that would/should work only if you're using system-config-firewall
And how is the code going to determine that?
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 12:05:00 -0500, Arthur Pemberton pemboa@gmail.com wrote:
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
So being able to easily disable this wouldn't be enough?
I don't think so. I thought making it easy for people to shoot themselves in the foot was the Microsoft way.
I do not see a parallel here, please explain
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
This is something that would/should work only if you're using system-config-firewall
And how is the code going to determine that?
By having the init script ask s-c-firewall to open the port as has been suggested.
On Sat, Sep 01, 2007 at 22:30:12 -0500, Arthur Pemberton pemboa@gmail.com wrote:
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 12:05:00 -0500, Arthur Pemberton pemboa@gmail.com wrote:
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
So being able to easily disable this wouldn't be enough?
I don't think so. I thought making it easy for people to shoot themselves in the foot was the Microsoft way.
I do not see a parallel here, please explain
Microsoft makes things convenient even when what is being made convenient is a dumb idea from a security perspective. Think email clients that run programs to view attachments of type other than plain/text without even asking.
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
This is something that would/should work only if you're using system-config-firewall
And how is the code going to determine that?
By having the init script ask s-c-firewall to open the port as has been suggested.
Does the init script know that s-c-firewall is what wrote the current set of firewall rules? If so, I'd be curious to know how it does. Because if s-c-firewall didn't write the rules, it is possible that the changes it makes will cause problems.
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
I think the idea of having some way to help people who want a service available to the internet at large or some local ip addresses is a good idea, but it needs to be an add on step that can be skipped, not some invisible change behind the scenes.
I wonder if the solution is to display the linkage between services and firewall rules in the configuration tools. People would make the changes in the tools but they would know what is needed. For system-config-securitylevel, one possibility is to highlight the services that are enabled but haven't been opened.
Another help would have system-config-services print out a warning if the user enables a service but the firewall rule is not opened. system-config-services could probably show a dialog box that opens the firewall rule. This would probably only work if system-config-securitylevel is managing the firewall.
- Ian
On 9/4/07, Ian Burrell ianburrell@gmail.com wrote:
On 9/1/07, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Sep 01, 2007 at 14:07:17 +0200, Benny Amorsen benny+usenet@amorsen.dk wrote:
Administrators sometimes want to limit which traffic can reach applications, and perhaps limit the risk when accidentally starting applications. Automating firewall setup makes that useless.
That is probably the main reason. And having apps undo restrictions seems like a really really bad idea.
Plus I have no confidence that apps can properly rewrite iptables rules correctly. iptables setups can have complications which will make it hard to change them. I have used subroutines for checking reserved ip ranges and have had services configured to only be available to local ip addresses or specific interfaces.
I think the idea of having some way to help people who want a service available to the internet at large or some local ip addresses is a good idea, but it needs to be an add on step that can be skipped, not some invisible change behind the scenes.
I wonder if the solution is to display the linkage between services and firewall rules in the configuration tools. People would make the changes in the tools but they would know what is needed. For system-config-securitylevel, one possibility is to highlight the services that are enabled but haven't been opened.
Another help would have system-config-services print out a warning if the user enables a service but the firewall rule is not opened. system-config-services could probably show a dialog box that opens the firewall rule. This would probably only work if system-config-securitylevel is managing the firewall.
Seems like a fair compromise.
How about each service dropping a config snippet (as a separate file) into something like /etc/sysconfig/service-firewall-rules and having a setting on the firewall config GUI which allowed these to be included in [or not].
You could also provide an appropriately rich environment setup to allow all the standard requirements of basic firewall rules (ie interface name/addr etc).
It would obviously take work to get this infrastructure in place.
Nigel.
Le Mer 5 septembre 2007 10:32, Nigel Metheringham a écrit :
How about each service dropping a config snippet (as a separate file) into something like /etc/sysconfig/service-firewall-rules and having a setting on the firewall config GUI which allowed these to be included in [or not].
You could also provide an appropriately rich environment setup to allow all the standard requirements of basic firewall rules (ie interface name/addr etc).
It would obviously take work to get this infrastructure in place.
In an handwaved perfect word, service-firewall-rules would display a graph of the current firewall network ruleset (showing the packet flow through blocks of rules), and services would just dump new blocks in this graph that'd be grayed out till activated by the admin.
This is something like a SoC project though.
Regards,
On Wed, 2007-09-05 at 11:30 +0200, Nicolas Mailhot wrote:
In an handwaved perfect word, service-firewall-rules would display a graph of the current firewall network ruleset (showing the packet flow through blocks of rules), and services would just dump new blocks in this graph that'd be grayed out till activated by the admin.
This is something like a SoC project though.
What's Fedora's stance on firewall / iptables management, anyway. Specifically with regards to other "iptables applications"? So far, the only way I see that external apps can co-exist with s-c-s is by using the "Custom Rules File" which simply appends rules to the end of the rules generated by s-c-s.
I have two applications right now (one to limit DROP successive ssh accesses and another to DROP access from spam sources configured dynamically) and the use of the Custom Rules File is insufficient for the way it works (some rules need to be inserted at an arbitrary position relative to the rules generated by s-c-s and a regeneration of the integrated /etc/sysconfig/iptables file is needed whenever dynamic changes are made).
How does Fedora intend to handle firewall management requests from external apps? Will it export some kind of IPC API? Or is Custom Rules File finally it? --
Richi Plana
On Saturday 01 September 2007 03:34:29 Benny Amorsen wrote:
Basically, what this means is, "don't allow incoming traffic except where root says it's ok", which might sometimes be what you want to achieve.
AP> By the way, I still think that tis is a good idea.
It would be nicer if the bind() failed in the application.
We now have rsyslog in the distribution. It should be simple to create a configuration command that greps for iptables events and notifies the user in realtime kind of the way that setroubleshoot does. As a matter of fact, what might be even more useful is a command that watches for disk drive errors and tells the user that its starting to see the hard drive fail.
But from a security point of view, I don't think its a good idea for apps to be able to punch a hole in the firewall.
-Steve
On Sat, Sep 01, 2007 at 08:25:34 -0400, Steve Grubb sgrubb@redhat.com wrote:
We now have rsyslog in the distribution. It should be simple to create a configuration command that greps for iptables events and notifies the user in realtime kind of the way that setroubleshoot does. As a matter of fact, what might be even more useful is a command that watches for disk drive errors and tells the user that its starting to see the hard drive fail.
For the disk drive part of this, it already exists. smartd does self tests on disks and logs the messages. These messages get reported by logwatch in an email message once a day.
Hi.
On Sat, 1 Sep 2007 10:32:42 -0500, Bruno Wolff III wrote
For the disk drive part of this, it already exists. smartd does self tests on disks and logs the messages. These messages get reported by logwatch in an email message once a day.
It would be nicer if smartd could call out to the notify daemon to make a window appear on the users desktop.
Users do not read logwatch reports, the usually do not even get them.
On Monday 03 September 2007 07:53:35 Ralf Ertzinger wrote:
For the disk drive part of this, it already exists. smartd does self tests on disks and logs the messages. These messages get reported by logwatch in an email message once a day.
Does this only work for smart drives or all drives? What if you don't have smartd installed? rsyslog has its hands on all the interesting data. Its in a position to make these kind of alerts no matter what is installed on a system.
It would be nicer if smartd could call out to the notify daemon to make a window appear on the users desktop.
Users do not read logwatch reports, the usually do not even get them.
Agreed. Besides, I've seen drives go from good to crap within an hour. A daily report would be too late to be of use. I'd rather see us develop the infrastructure for messaging around rsyslog so that each daemon does not need to be modified if there was something that an admin wanted to be alerted for.
-Steve
On Mon, Sep 03, 2007 at 08:08:48 -0400, Steve Grubb sgrubb@redhat.com wrote:
Agreed. Besides, I've seen drives go from good to crap within an hour. A daily report would be too late to be of use. I'd rather see us develop the infrastructure for messaging around rsyslog so that each daemon does not need to be modified if there was something that an admin wanted to be alerted for.
You can schedule smartd to run more than once a day. This might particularly make sense for the short selft tests that run in a couple of minutes. And smartd itself can send mail alerts when specific things are detected. Since you can specify a command to run to send the mail, this notification could also do other things.
On Mon, Sep 03, 2007 at 01:53:35PM +0200, Ralf Ertzinger wrote:
On Sat, 1 Sep 2007 10:32:42 -0500, Bruno Wolff III wrote
For the disk drive part of this, it already exists. smartd does self tests on disks and logs the messages. These messages get reported by logwatch in an email message once a day.
It would be nicer if smartd could call out to the notify daemon to make a window appear on the users desktop.
Users do not read logwatch reports, the usually do not even get them.
Not that for many setups the person in front of the computer does not have a root password and would prefer not to get spammed with messages about things he can do nothing about (even if he did care).
For the record smartd does send emails right away if it detects something wrong with the disk.
Cheers, Kostas Georgiou
On Mon, 2007-08-20 at 12:54 -0400, Simo Sorce wrote:
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.
I was just going to file this as a bug, but I wanted to raise it here first: NIS doesn't work with the default fedora firewall. If I turn off the firewall, NIS starts to behave.
Is this intended (per the 'don't mess with my firewall' thoughts), or a bug I should file?
(The problem is particularly around broadcast packets, so this might be more like the Samba netbios name resolution issue we had, till an iptables module was written).
Thoughts?
Andrew Bartlett
On Mon, 2007-08-20 at 16:20 +0000, "Jóhann B. Guðmundsson" wrote:
( 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
How would this interact with VPNs. I tend to run services with full VPN internal access (openvpn) but no access from the public Internet.
Also what services would default to opening firewall ports? CUPS, for example, opens a port both for local printing and for remote use. If I have CUPS on a box without local printers, it likely doesn't need firewall holes.
Perhaps modify system-config-security to allow ports to be opened by service (not by port) and have initscript functions look at that?
"JBG" == Jóhann B Guðmundsson johannbg@hi.is writes:
JBG> Any thoughts on implementing automatically port opening for JBG> service that need to open port access in the firewall as in when JBG> service is started that needs port opening it would automatically JBG> read some firewall.conf file for that and open the port JBG> automatically according to those settings in the firewall.conf JBG> file ( add the iptables rules automatically when the service is JBG> started and remove those rules when the service is stopped )
This functionality is available already. You invoke it by doing service iptables stop or rpm -e iptables.
/Benny