Zigzagcom
27th February 2005, 12:02 PM
:) Hi all,
I'm still in the process of debugging a server configuration and stumbled on a couple of interesting issues with 'firestarter'. I have "Webmin" installed as an interface for remote admin, and it runs on its own server on port 10000 by default. This application is extremely versatile and you can configure iptables from within the interface in the networking module.
Out of curiosity I installed 'firestarter v1.0.1' and ran the wizard, but did not set up any specific configuration and exited 'firestarter'.
This means that I have 3 utilities installed with which I could affect iptables, apart from the shell.
1. The 'security level' tool that comes with FC3 by default.
2. The 'Webmin' iptables module
3. 'Firestarter'
Previous to the install of 'firestarter', I had no issues with rebooting and accessing web-content. In other words, the iptables configuration via the 'Webmin' interface remained intact. Once 'firestarter' was installed I consistently was unable to access httpd from other machines on the network, after the server was restarted. After re-applying the "Webmin" iptables config locally, access to the httpd service was restored. I was able to follow the configuration changes via the 'services' app and selecting 'iptables' and querying the status pane. I decided to uninstall 'firestarter' with Synaptic. Synaptic has this cool feature at the end of the uninstall process, warning you of saved files. One of the files was
/etc/firestarter/firewall.rpmsave....a quick su - and 'more firewall.rpmsave' leads me to believe that 'firestarter' can basically hijack an iptables configuration from another app.
I am aware of the conflict that can arise from using the 'security level' tool, but 'firestarter'
seemingly does not dynamically adjust to configuration changes. It just happily hangs onto its configuration and resets iptables on a restart. Funny and vexing. :D
This is possibly a good thing and I obviously don't want to have a hodgepodge of firewalls
on a server. Just thought this was interesting.
I'm still in the process of debugging a server configuration and stumbled on a couple of interesting issues with 'firestarter'. I have "Webmin" installed as an interface for remote admin, and it runs on its own server on port 10000 by default. This application is extremely versatile and you can configure iptables from within the interface in the networking module.
Out of curiosity I installed 'firestarter v1.0.1' and ran the wizard, but did not set up any specific configuration and exited 'firestarter'.
This means that I have 3 utilities installed with which I could affect iptables, apart from the shell.
1. The 'security level' tool that comes with FC3 by default.
2. The 'Webmin' iptables module
3. 'Firestarter'
Previous to the install of 'firestarter', I had no issues with rebooting and accessing web-content. In other words, the iptables configuration via the 'Webmin' interface remained intact. Once 'firestarter' was installed I consistently was unable to access httpd from other machines on the network, after the server was restarted. After re-applying the "Webmin" iptables config locally, access to the httpd service was restored. I was able to follow the configuration changes via the 'services' app and selecting 'iptables' and querying the status pane. I decided to uninstall 'firestarter' with Synaptic. Synaptic has this cool feature at the end of the uninstall process, warning you of saved files. One of the files was
/etc/firestarter/firewall.rpmsave....a quick su - and 'more firewall.rpmsave' leads me to believe that 'firestarter' can basically hijack an iptables configuration from another app.
I am aware of the conflict that can arise from using the 'security level' tool, but 'firestarter'
seemingly does not dynamically adjust to configuration changes. It just happily hangs onto its configuration and resets iptables on a restart. Funny and vexing. :D
This is possibly a good thing and I obviously don't want to have a hodgepodge of firewalls
on a server. Just thought this was interesting.