Re: firestarter start failure?
- From: NoOp <glgxg@xxxxxxxxxxxxx>
- Date: Mon, 23 Jun 2008 20:33:30 -0700
On 06/23/2008 12:06 PM, Paul Johnson wrote:
On Sun, Jun 22, 2008 at 12:49 PM, NoOp <glgxg@xxxxxxxxxxxxx> wrote:
On 06/21/2008 09:57 PM, Paul Johnson wrote:
Firestarter is not a daemon, it should not show in ps output unless
gui is open. It writes to iptables firewall rules, and then is done,
unless gui is open.
Hmmm....
http://www.fs-security.com/docs/persistence.php
/etc/init.d/firestarter status
should give the status. See: http://www.fs-security.com/docs/faq.php
<quote>
Q: Do I have to start Firestarter after I have rebooted?
Usually, no. When Firestarter is installed from a package, the firewall
is running as a service. You can query the status of the service by
executing /etc/init.d/firestarter status. The excemption to this is
Gentoo users, dial-up users in some cases and persons who have installed
from source and not registered the Firestarter sytem service.
</quote>
Documentation is here:
http://www.fs-security.com/docs.php
This is where the confusion enters, I was asking about it here last
week. I think there is confusion because the term "firewall is on" is
a bit ambiguous.
I agree the firestarter documentation you refer to calls it a system
service, but it is not a system service in the same sense as "anacron"
or "ntp" or most of the others. If you read /etc/init.d/firestarter,
you see that when you say "start" it just runs
/etc/firestarter/firestarter.sh, and that calls
/etc/firestarter/firewall. All that does is slide in the
firestarter-created iptables rules into the iptables firewall that the
kernel is running. There is no "firestarter" program running after
that. It is just iptables reading the rules from firestarter.
As a convenience to users, they have scripted it so that it acts like
a service, but it is not a daemon.
The firewall is "running" in the sense that the kernel uses iptables
to decide if things should be allowed in. When you "start"
firestarter, it simply means that the set of iptables rules that were
created by firestarter are put into the iptables framework.
Go read the file /etc/firestarter/firewall, which is actually doing
the work. It is a bunch of ipchains commands. firestarter itself is
not a daemon, it is not "running in the background." That is why it
does not show up when people use "ps aux" to look to see if it is
running. I wish the firestarter documentation did not claim it is a
service, otherwise we would not have confused people asking 'is my
firewall running."
Thanks, very useful info.
Observe:
$ sudo /etc/init.d/firestarter status
* Firestarter is running...
pauljohn@pols123:/etc/init.d$ ps aux | grep fire
pauljohn 10529 7.0 14.2 264956 147012 ? Sl 13:44 0:43
/usr/lib/firefox-3.0/firefox
pauljohn 11115 0.0 0.0 3008 772 pts/1 S+ 13:54 0:00 grep fire
Nevertheless, I do have firewall rules from firestarter, even though
there is no "firestarter process" running:
$ sudo /sbin/iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 192.168.0.1 anywhere tcp
flags:!FIN,SYN,RST,ACK/SYN
ACCEPT udp -- 192.168.0.1 anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere limit:
avg 10/sec burst 5
DROP all -- anywhere 255.255.255.255
[snip]
Looking at this a little further, you are correct. Indeed it is not a
daemon. And reviewing your info, why they have the
/etc/init.d/firestarter status bit is beyond me.
I have to admit that I only have it on a laptop and only fire it up (no
pun intended) occasionally when I take the laptop someplace, so I'm not
that familiar with FS & had to reinstall it to appreciate your points.
I think where some of the confusion may be, is that FS does, as you
state, modifies the iptables much in the same way that Shorewall. The
rules get applied and then iptables goes on to silently apply the rules.
When you boot the FS GUI & panel applet is not running, but the FS rules
are in effect.
The problem with not having the GUI/Applet running, is that FS doesn't
automatically wake up and tell you that it has just blocked a Samba
request from on of your local machines etc, you need the GUI/Applet
running for this. So the user blissfully goes on and can't figure out
why Samba (for example) is not working; it's only after you turn on the
GUI/Applett that you find out that Samba requests from your other
machine were blocked by FS & all this time you've been blaming your
Samba config files...
This also can create another issue; when I have the laptop at home I
don't want FS doing anything at all as I use my network router's
firewall. Sometimes it drives me crazy trying to figure out what the
problem is & then I remember that I had FS running previously. On the
laptop I resolved this by implementing:
http://www.fs-security.com/docs/faq.php#trayicon
At least that way I remember it's installed/running and it gives me a
GWFW (Goober With FireWall) GUI/Applett reminder.
Rather interesting thread on all of this here:
http://ubuntuforums.org/showthread.php?t=542756
--
ubuntu-users mailing list
ubuntu-users@xxxxxxxxxxxxxxxx
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
- Follow-Ups:
- Simple Iptables (was Re: firestarter start failure?)
- From: Peter Garrett
- Simple Iptables (was Re: firestarter start failure?)
- References:
- firestarter start failure?
- From: Robert Holtzman
- Re: firestarter start failure?
- From: Vitorio Okio
- Re: firestarter start failure?
- From: Robert Holtzman
- Re: firestarter start failure?
- From: Paul Johnson
- Re: firestarter start failure?
- From: NoOp
- Re: firestarter start failure?
- From: Paul Johnson
- firestarter start failure?
- Prev by Date: Re: help needed to enable boot.log in Hardy Heron
- Next by Date: Re: help needed to enable boot.log in Hardy Heron
- Previous by thread: Re: firestarter start failure?
- Next by thread: Simple Iptables (was Re: firestarter start failure?)
- Index(es):
Relevant Pages
|