Installing bind is not very clear for me
ingrogger at gmail.com
Fri Sep 4 18:41:19 UTC 2015
I think that regarding security issues, is better to prevent as much as
Here we have two different opinions:
People that agree to use firewall and people against (or arguing that is
I would like to hear both and then decide. If we share our points maybe
can get a better conclusions
So I would like to learn about firewall techniques to protect a DNS.
And for people against firewall , wich are the security considerations
to take in order to protect the service without firewall.
On 04/09/15 14:27, Mike Hoskins (michoski) wrote:
> On 9/4/15, 1:12 PM, "bind-users-bounces at lists.isc.org on behalf of
> /dev/rob0" <bind-users-bounces at lists.isc.org on behalf of rob0 at gmx.co.uk>
>> On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote:
>>> Am 03.09.2015 um 22:59 schrieb Robert Moskowitz:
>>>> On 09/03/2015 04:35 PM, Leandro wrote:
>>>>> Ok ...
>>>>> I got BIND 9.10.2-P3 working.
>>>>> I compiled with
>>>>> ./configure --with-openssl --enable-threads --with-libxml2
>>>>> make install
>>>>> Json statistics channel is working and chroot is not longer
>>>> But do make sure you have selinux enforced. Or run behind
>>>> multiple firewalls...
>>> behind *multiple firewalls* - ?!?! - oh come on and get serious
>>> instead promote snakeoil -
>> I quite agree here. Firewalls that attempt to filter DNS have
>> terrible reputations for *breaking* DNS. A single firewall is bad
>> enough; multiple firewalls sounds like a disaster.
> True, have fixed many of those over the years, though in fairness this is
> often a matter of expecting to run a firewall (or anything) "out of box"
> without understanding the config. If that's the stance of the admin, you
> likely have a lot more to worry about security-wise than named chroot. :-)
>>> typically BIND is *not* running as root and hence does not need
>>> any special handling compared to any other network service
>> I don't know if we can say what is "typical". We can say, for
>> running on Linux at least, that running as root is safe. A
>> compromised named would get root after having dropped superuser
>> privileges, so it wouldn't be able to do much.
> I probably misunderstand your response or am reading too much into the
> wording. Named doesn't run as root due to -u giving up permissions. That
> combined with the fact chroot itself has known shortcomings is why it's
> fallen out of BCP amongst name server operators. It's not that anyone
> suggests the alternative to chroot is to just run as root. You are still
> running as a non-privileged user post-startup, and permissioning things
> appropriately to minimize damage in the event of a compromise.
>> Regardless, again I quite agree that special handling is not
>> necessary. Look at the various BIND9 security announcements over
>> the years. When have you seen one which involved a compromise of
>> any kind?
>> I cannot say with authority that BIND9 has never had a compromise,
>> but I am confident in saying I have never seen one.
> I appreciate the viewpoint, and I can even agree with it, but the past is
> not necessarily a key to the future. The reality is none of the nastiest
> 0-days were ever expected. As a security professional you try to insulate
> against potential risks, not just things you have already observed. It's
> up to each operator to determine appropriate cost/benefit, and this is not
> an argument for chroot, but I do caution against an "I've never seen it
> before so wouldn't worry about it" stance on security.
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
More information about the bind-users