<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Reindl , I agree with you.<br>
One Firewall should be enough.<br>
So, what you consider this firewall should do ? <br>
In my opinion:<br>
Block requests coming from a blacklist (Who will generate this list
?)<br>
Block denial of service requests. It needs to measure the requests
rate to detects when is under attack.<br>
Block port scanners on publics ips.<br>
<br>
I dont know what else ....<br>
Thanks.<br>
Leandro.<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/09/15 15:49, Reindl Harald wrote:<br>
</div>
<blockquote cite="mid:55E9E7C0.4070702@thelounge.net" type="cite">
<br>
<br>
Am 04.09.2015 um 20:41 schrieb Leandro:
<br>
<blockquote type="cite">I think that regarding security issues, is
better to prevent as much as
<br>
possible.
<br>
Here we have two different opinions:
<br>
People that agree to use firewall and people against (or arguing
that is
<br>
not necessary):
<br>
<br>
I would like to hear both and then decide. If we share our
points maybe
<br>
can get a better conclusions
<br>
<br>
So I would like to learn about firewall techniques to protect a
DNS.
<br>
And for people against firewall , wich are the security
considerations
<br>
to take in order to protect the service without firewall.
<br>
</blockquote>
<br>
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
<br>
<br>
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)
<br>
<br>
what you need is *one* firewall you trust
<br>
<br>
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
<br>
<br>
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
<br>
<br>
well, and that attackers are shooting directly to your firewalls
too
<br>
<br>
<br>
<blockquote type="cite">On 04/09/15 14:27, Mike Hoskins (michoski)
wrote:
<br>
<blockquote type="cite">On 9/4/15, 1:12 PM,
"<a class="moz-txt-link-abbreviated" href="mailto:bind-users-bounces@lists.isc.org">bind-users-bounces@lists.isc.org</a> on behalf of
<br>
/dev/rob0" <a class="moz-txt-link-rfc2396E" href="mailto:bind-users-bounces@lists.isc.orgonbehalfofrob0@gmx.co.uk"><bind-users-bounces@lists.isc.org on behalf of
rob0@gmx.co.uk></a>
<br>
wrote:
<br>
<br>
<br>
<blockquote type="cite">On Thu, Sep 03, 2015 at 11:02:23PM
+0200, Reindl Harald wrote:
<br>
<blockquote type="cite">Am 03.09.2015 um 22:59 schrieb
Robert Moskowitz:
<br>
<blockquote type="cite">On 09/03/2015 04:35 PM, Leandro
wrote:
<br>
<blockquote type="cite">Ok ...
<br>
I got BIND 9.10.2-P3 working.
<br>
I compiled with
<br>
<br>
./configure --with-openssl --enable-threads
--with-libxml2
<br>
--with-libjson
<br>
make
<br>
make install
<br>
<br>
Json statistics channel is working and chroot is not
longer
<br>
mandatory.
<br>
</blockquote>
But do make sure you have selinux enforced. Or run
behind
<br>
multiple firewalls...
<br>
</blockquote>
behind *multiple firewalls* - ?!?! - oh come on and get
serious
<br>
instead promote snakeoil -
<br>
</blockquote>
I quite agree here. Firewalls that attempt to filter DNS
have
<br>
terrible reputations for *breaking* DNS. A single firewall
is bad
<br>
enough; multiple firewalls sounds like a disaster.
<br>
</blockquote>
<br>
True, have fixed many of those over the years, though in
fairness this is
<br>
often a matter of expecting to run a firewall (or anything)
"out of box"
<br>
without understanding the config. If that's the stance of the
admin, you
<br>
likely have a lot more to worry about security-wise than named
<br>
chroot. :-)
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">typically BIND is *not* running as
root and hence does not need
<br>
any special handling compared to any other network service
<br>
</blockquote>
I don't know if we can say what is "typical". We can say,
for
<br>
running on Linux at least, that running as root is safe. A
<br>
compromised named would get root after having dropped
superuser
<br>
privileges, so it wouldn't be able to do much.
<br>
</blockquote>
<br>
I probably misunderstand your response or am reading too much
into the
<br>
wording. Named doesn't run as root due to -u giving up
permissions.
<br>
That
<br>
combined with the fact chroot itself has known shortcomings is
why it's
<br>
fallen out of BCP amongst name server operators. It's not
that anyone
<br>
suggests the alternative to chroot is to just run as root.
You are still
<br>
running as a non-privileged user post-startup, and
permissioning things
<br>
appropriately to minimize damage in the event of a compromise.
<br>
<br>
<br>
<blockquote type="cite">Regardless, again I quite agree that
special handling is not
<br>
necessary. Look at the various BIND9 security announcements
over
<br>
the years. When have you seen one which involved a
compromise of
<br>
any kind?
<br>
<br>
I cannot say with authority that BIND9 has never had a
compromise,
<br>
but I am confident in saying I have never seen one.
<br>
</blockquote>
<br>
I appreciate the viewpoint, and I can even agree with it, but
the past is
<br>
not necessarily a key to the future. The reality is none of
the nastiest
<br>
0-days were ever expected. As a security professional you try
to
<br>
insulate
<br>
against potential risks, not just things you have already
observed. It's
<br>
up to each operator to determine appropriate cost/benefit, and
this is
<br>
not
<br>
an argument for chroot, but I do caution against an "I've
never seen it
<br>
before so wouldn't worry about it" stance on security.
<br>
</blockquote>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
</body>
</html>