firestarter start failure?

[Paul Johnson]

On Fri, Jun 20, 2008 at 12:01 AM, Robert Holtzman <holtzm at cox.net> wrote:
> Just had occasion to reboot 8.04 and got a boot message that firestarter
> had failed to start. When the boot was complete I opened firestarter and
> it's status was shown as active.
>
I just went through this.

Possible explanations.

1. Do you have two network interfaces, say eth0 and eth1 or wlan0?  If
so, is the config for firestarter pointed at the one that is ON at the
time firestarter tries to initiate?   I see an error when I try to do
/sbin/ifup eth0 if the firestarter is configured only to look on
wlan0, and wlan0 is unavailable.

Once you use the firestarter gui to tell it the active wire, you see this:

$ sudo /etc/init.d/firestarter restart
 * Stopping the Firestarter firewall...
           [ OK ]
 * Starting the Firestarter firewall...
           [ OK ]

But if firestarter is set to go on an inactive eth0 or wlan0 (I just
re-ran firestarter and set the preference-network thing to the
wireless, but I'm on the wire), you see what happens when I bring up
the wire (on eth0):

$ sudo /sbin/ifdown eth0
 * Stopping the Firestarter firewall...
   ...done.
 * Starting the Firestarter firewall...
   ...fail!
run-parts: /etc/network/if-down.d/50firestarter exited with return code 2
pauljohn at pols123:etc$ sudo /sbin/ifup eth0
 * Stopping the Firestarter firewall...
   ...done.
 * Starting the Firestarter firewall...
   ...fail!
run-parts: /etc/network/if-up.d/50firestarter exited with return code 2

I can't start it as a service, either.
$ sudo /etc/init.d/firestarter start
 * Starting the Firestarter firewall...
           [fail]

2. To see if firewall rules are "in place" and used by iptables, run

sudo /sbin/iptables -L

I'm a little surprised right now because, after setting firestarter to
the wrong device, the iptables output tells me that the firewall is
not blocking anything:

$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


>From previous testing, I had the (apparently wrong??) impression that
the iptables rules are put in and always used by iptables, but that
the additional "personal firewall" of firestarter was not operating.
I must have been fooling myself, or had made some other change,
because now it certainly is not good. Or else I broke something. I
could swear that, from the firestarter manual, I had set firestarter
to run as a "system service".  The "personal firewall" is an
additional service that an individual user can adjust to open or close
ports, and it is supposed to be "on top" of the system service.

If I am supposed to reconfigure firestarter every time I go between
wireless and wire, it is too big of a hassle.  So I will just dump
firestarter altogether and run ufw instead.  ufw appears to run on all
ethernet devices, is good all the time.

I'm disabling the firestarter script for now
# cd /etc/rcS.d
# sudo mv S65firestarter K35firestarter

# sudo ufw enable
Firewall started and enabled on system startup
# sudo /sbin/iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ufw-before-input  all  --  anywhere             anywhere
ufw-after-input  all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
ufw-before-forward  all  --  anywhere             anywhere
ufw-after-forward  all  --  anywhere             anywhere

[Snip]

OK, so ufw does monitor all incoming, blocks everything. That's good.

Now allow through port 22 for ssh and port 631 for ipp printing:

# sudo ufw allow 22
# sudo ufw allow 631

$ sudo ufw status
Firewall loaded

To                         Action  From
--                         ------  ----
22:tcp                     ALLOW   Anywhere
22:udp                     ALLOW   Anywhere
631:tcp                    ALLOW   Anywhere
631:udp                    ALLOW   Anywhere

Now, here's a tip.  ssh is one of the services that will monitor the
file /etc/hosts.deny.  If you add at the end

ALL: ALL

then all incoming ssh connections will be rejected.

Then, in /etc/hosts.allow, you add specific provisions that allow in
the sites that you want.

In my system, I installed the denyhosts deb package and fiddled its
configuration to dump the IP addresses of suspected attackers into a
file /etc/denyhosts.blocked.   Then I have /etc/hosts.allow set to
check that file first, then go on to allow in just some particular IP
ranges that I trust.

### /etc/hosts.allow
portmap: 129.237.61
ALL: 127.0.0.1
sshd : /etc/denyhosts.blocked : deny
sshd: 66.45.
sshdfwd-X11: 66.45.

In 1998, I had a system online and some script kid tried thousands and
thousands of logins until he found an account that worked.  After
that, I try to be more conservative in opening up things.

One good thing about the default Ubuntu configuration is that root is
not allowed to log in, so your system will ignore all efforts by
hackers to log in as root.

Hope that helps.  Helped me to write it down!




-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas