Reindl , I agree with you.
One Firewall should be enough.
So, what you consider this firewall should do ?
In my opinion:
Block requests coming from a blacklist (Who will generate this list ?)
Block denial of service requests. It needs to measure the requests rate
to detects when is under attack.
Block port scanners on publics ips.
I dont know what else ....
Thanks.
Leandro.
On 04/09/15 15:49, Reindl Harald wrote:
Am 04.09.2015 um 20:41 schrieb Leandro:
I think that regarding security issues, is better to prevent as much as
possible.
Here we have two different opinions:
People that agree to use firewall and people against (or arguing that is
not necessary):
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.
AFAIR nobody said anything against firewalls in general, but the
"multiple firewalls in a row" is just nonsense and don't improve
security in a deterministic way
but it brings more points of failure and in the worst case more
vulnerable points in case of one or more of that firewalls are
outdated and vulerable itself - commercial "security appliances" are
famous for all sort of outdated software where a simple security audit
shows you more vulerabilities on that crap than in your whole network
(Barracuda Networks as example)
what you need is *one* firewall you trust
if you don't trust it and that is the only valid reason to build up a
cascade of firewalls put it out of your network
mostly people who are throwing as much as possible appliances and
firewalls in front of their machines doing that because missing
knowledge and hope some of the stuff they are throwing in the mix will
magically catch whatever - that's not how security really works, you
need to understand what you are installing and doing, throwing as much
as possible things in the mix just leads that you no longer understand
what your own network really does, but that don't bother attackers
shooting blindly with all sorts of expolits in the hope one hits
well, and that attackers are shooting directly to your firewalls too
On 04/09/15 14:27, Mike Hoskins (michoski) wrote:
On 9/4/15, 1:12 PM, "bind-users-boun...@lists.isc.org on behalf of
/dev/rob0" <bind-users-boun...@lists.isc.org on behalf of
r...@gmx.co.uk>
wrote:
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
--with-libjson
make
make install
Json statistics channel is working and chroot is not longer
mandatory.
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
