| 2009-11-30 12:52:30 |
ceg |
bug |
|
|
added bug |
| 2009-11-30 12:53:27 |
ceg |
summary |
firhol not started on boot (with START_FIREHOL=yes) |
firehol not started on boot (with START_FIREHOL=yes) |
|
| 2009-12-01 16:32:13 |
Johnathon |
security vulnerability |
no |
yes |
|
| 2009-12-02 13:34:24 |
Marc Deslauriers |
firehol (Ubuntu): status |
New |
Triaged |
|
| 2009-12-02 13:34:31 |
Marc Deslauriers |
firehol (Ubuntu): importance |
Undecided |
High |
|
| 2010-03-17 11:10:43 |
ceg |
summary |
firehol not started on boot (with START_FIREHOL=yes) |
not started on boot (DNS resolv fails) |
|
| 2010-03-17 11:24:45 |
ceg |
description |
Binary package hint: firehol
ubuntu 9.10
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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 |
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship more specific firehol upstart definitions and config files:
1) /etc/init/firehol-prep.conf that stats firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
|
| 2010-03-17 11:25:18 |
ceg |
description |
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship more specific firehol upstart definitions and config files:
1) /etc/init/firehol-prep.conf that stats firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship more specific firehol upstart definitions and config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
|
| 2010-03-17 11:27:44 |
ceg |
description |
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship more specific firehol upstart definitions and config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
|
| 2011-04-16 07:11:14 |
ceg |
summary |
not started on boot (DNS resolv fails) |
start script fails (if config requires DNS resolv) |
|
| 2011-04-16 07:24:03 |
ceg |
description |
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However after a reboot:
# iptables 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
|
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However, after a reboot the chains are empty:
# iptables 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
Solution:
Load only a basic (blocking) config file with numeric IPs in the early boot process,
and (re)load the real firehol.conf later, each time a network device got set up.
Workaround:
Call "firehol /etc/firehol/firehol.conf start" again from /etc/rc.local.
(Warning: System is without protection until a successful firehol start.) |
|
| 2011-04-16 07:24:43 |
ceg |
description |
Binary package hint: firehol
ubuntu 9.10
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However, after a reboot the chains are empty:
# iptables 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
Solution:
Load only a basic (blocking) config file with numeric IPs in the early boot process,
and (re)load the real firehol.conf later, each time a network device got set up.
Workaround:
Call "firehol /etc/firehol/firehol.conf start" again from /etc/rc.local.
(Warning: System is without protection until a successful firehol start.) |
Binary package hint: firehol
ubuntu 9.10, 10.04, 10.10, ...
The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.
However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:
1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).
2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf
Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
* /etc/init.d/firehol script is there
* /etc/firehol/firehol.conf is in place
* firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
* symlinks in /etc/rc?.d do exist
However, after a reboot the chains are empty:
# iptables 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
Solution:
Load only a basic (blocking) config file with numeric IPs in the early boot process,
and (re)load the real firehol.conf later, each time a network device got set up.
Workaround:
Call "firehol /etc/firehol/firehol.conf start" again from /etc/rc.local.
(Warning: System is without protection until a successful firehol start.) |
|
| 2011-04-16 07:28:45 |
ceg |
summary |
start script fails (if config requires DNS resolv) |
start script fails with upstart (if config requires DNS resolv) |
|
| 2011-04-16 10:05:51 |
Phil Whineray |
bug |
|
|
added subscriber Phil Whineray |
| 2011-11-09 21:57:55 |
Jamie Strandboge |
removed subscriber Ubuntu Security Team |
|
|
|
