Hi,
On my public servers, I usually run BIND for DNS. I see CentOS offers a preconfigured (sort of) bind-chroot package. I wonder what's the effective benefit of this vs. a "normal" BIND setup without chroot. On my Slackware servers, I have a rather Keep-It-Simple approach to all things security, e. g. run no unneed services, open only needed ports etc. but I don't run the extra mile (and haven't been bitten so far).
Any suggestions? (No flamefest please.)
Niki
On 4/12/2017 3:11 PM, Nicolas Kovacs wrote:
On my public servers, I usually run BIND for DNS. I see CentOS offers a preconfigured (sort of) bind-chroot package. I wonder what's the effective benefit of this vs. a "normal" BIND setup without chroot. On my Slackware servers, I have a rather Keep-It-Simple approach to all things security, e. g. run no unneed services, open only needed ports etc. but I don't run the extra mile (and haven't been bitten so far).
Any suggestions? (No flamefest please.)
bind went through a rocky stage where there were a LOT of security holes in it. by running it in a chroot, you limit its ability to be used as a hacking point of entry. recent versions of bind (basicially, 9 and newer) are much more secure, so this is less of a concern.
On 04/12/2017 06:18 PM, John R Pierce wrote:
On 4/12/2017 3:11 PM, Nicolas Kovacs wrote:
On my public servers, I usually run BIND for DNS. I see CentOS offers a preconfigured (sort of) bind-chroot package. I wonder what's the effective benefit of this vs. a "normal" BIND setup without chroot. On my Slackware servers, I have a rather Keep-It-Simple approach to all things security, e. g. run no unneed services, open only needed ports etc. but I don't run the extra mile (and haven't been bitten so far).
Any suggestions? (No flamefest please.)
bind went through a rocky stage where there were a LOT of security holes in it. by running it in a chroot, you limit its ability to be used as a hacking point of entry. recent versions of bind (basicially, 9 and newer) are much more secure, so this is less of a concern.
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
Cheers,
Niki
On 04/13/2017 01:05 AM, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
Cheers,
Niki
I don't use SELinux because it gets in my way far more than it every actually protects me from anything.
I'm sure there are systems where it absolutely is necessary, but I don't like to have stuff fail because I used mv instead of cp to install a certificate, for example.
For authoritative DNS I also do not use chroot but authoritative DNS is all those servers do, and I use zones signed externally via DNSSEC (no private keys on the server)
On 04/13/2017 04:23 AM, Alice Wonder wrote:
On 04/13/2017 01:05 AM, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
Cheers,
Niki
I don't use SELinux because it gets in my way far more than it every actually protects me from anything.
I'm sure there are systems where it absolutely is necessary, but I don't like to have stuff fail because I used mv instead of cp to install a certificate, for example.
I need to do DNSSEC next; got to bother Mark Andrew over at ISC, did not get to sit down with him on this at IETF. So I don't know what certs I will need as yet. For my mailserver, I am using self-signed, and see my Apache setup, towards the end, how I create a set of certs:
http://medon.htt-consult.com/Centos7-mailserver.html#Setting%20up%20Apache
I had some help on this from the OpenSSL list.
For authoritative DNS I also do not use chroot but authoritative DNS is all those servers do, and I use zones signed externally via DNSSEC (no private keys on the server)
Something to consider, but I would do it on one of my internal systems. Not a third party; why should I trust them? Unless they are providing a full DNS PKI service.
On 04/13/2017 03:15 AM, Robert Moskowitz wrote:
On 04/13/2017 04:23 AM, Alice Wonder wrote:
On 04/13/2017 01:05 AM, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
Cheers,
Niki
I don't use SELinux because it gets in my way far more than it every actually protects me from anything.
I'm sure there are systems where it absolutely is necessary, but I don't like to have stuff fail because I used mv instead of cp to install a certificate, for example.
I need to do DNSSEC next; got to bother Mark Andrew over at ISC, did not get to sit down with him on this at IETF. So I don't know what certs I will need as yet. For my mailserver, I am using self-signed, and see my Apache setup, towards the end, how I create a set of certs:
http://medon.htt-consult.com/Centos7-mailserver.html#Setting%20up%20Apache
I had some help on this from the OpenSSL list.
For authoritative DNS I also do not use chroot but authoritative DNS is all those servers do, and I use zones signed externally via DNSSEC (no private keys on the server)
Something to consider, but I would do it on one of my internal systems. Not a third party; why should I trust them? Unless they are providing a full DNS PKI service.
I meant DNSSEC signing is done externally to the authoritative DNS.
I do the signing myself. Point being if someone hacked my authoritative DNS server, they could not alter my zone files in a way DNSSEC enforcing resolvers would accept because the signing keys are not there.
On 04/13/2017 04:05 AM, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
For basic authoritative server, I have the one magic setting needed in your configuration.
Otherwise it is working 'out of the box'.
On Thu, April 13, 2017 3:05 am, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
Another alternative with at least same level of security, though not giving me any trouble I hear people sometimes have with SELinux is to run services in separate jails (or other containers) - with base system mounted inside jail read-only (I use FreeBSD jails - apologies for mentioning, but Linux experts here can suggest fair Linux equivalent).
Valeri
I understand there's a wealth of information about SELinux. Any recommendations for a newbie-friendly primer? I don't mind to RTFM, even extensive documentation, but I prefer stuff that's well-written.
Cheers,
Niki
-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Am 13.04.2017 um 17:40 schrieb Valeri Galtsev galtsev@kicp.uchicago.edu:
On Thu, April 13, 2017 3:05 am, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
Another alternative with at least same level of security, though not giving me any trouble I hear people sometimes have with SELinux is to run services in separate jails (or other containers) - with base system mounted inside jail read-only (I use FreeBSD jails - apologies for mentioning, but Linux experts here can suggest fair Linux equivalent).
bind-chroot is a subpackage and quite straight forward (yum install bind-chroot). No need to handle jails and there environment updates when the base system gets updated (we use rpms trigger scripts for that).
-- LF
On 04/13/2017 12:11 PM, Leon Fauster wrote:
Am 13.04.2017 um 17:40 schrieb Valeri Galtsev galtsev@kicp.uchicago.edu:
On Thu, April 13, 2017 3:05 am, Nicolas Kovacs wrote:
Le 13/04/2017 à 04:27, Robert Moskowitz a écrit :
But make sure to have SELinux enabled if you do not run it chrooted.
I have mine running that way.
I bluntly admit not using SELinux, because until now, I mainly used more bone-headed systems that didn't implement it. Maybe this is the right time to get started.
Another alternative with at least same level of security, though not giving me any trouble I hear people sometimes have with SELinux is to run services in separate jails (or other containers) - with base system mounted inside jail read-only (I use FreeBSD jails - apologies for mentioning, but Linux experts here can suggest fair Linux equivalent).
bind-chroot is a subpackage and quite straight forward (yum install bind-chroot). No need to handle jails and there environment updates when the base system gets updated (we use rpms trigger scripts for that).
Correct, no real need for creating something special, bind-chroot has been around for years and just works. Before SELinux it was what we did. My last DNS server was Redsleeve 6 that I could not get SELinux working, so I just ran chroot. Now I have Centos7-arm with SELinux so no chroot.
Le 13/04/2017 à 00:18, John R Pierce a écrit :
bind went through a rocky stage where there were a LOT of security holes in it. by running it in a chroot, you limit its ability to be used as a hacking point of entry. recent versions of bind (basicially, 9 and newer) are much more secure, so this is less of a concern.
OK. Thanks for the clarification.
Niki
-
Alice Wonder -
John R Pierce -
Leon Fauster -
Nicolas Kovacs -
Robert Moskowitz -
Valeri Galtsev