[gentoo-user] Secure DNS servers

[gentoo-user] Secure DNS servers

[James]

Hello,

I'm reading up on how to secure DNS primary and secondary servers.
I guess DNSSEC is pretty important. Any other areas I should read
up on?  It's been a few years since I admin'd a dns server....


Also, look for gentoo centric  DNS primary solutions, I see
no mention of hardened, up-mounted or read only partitions, 
etc etc. I wondering if anyone has some general suggestions 
on how to keep a gentoo dns primary only machine secure.

The iptables suggests seem trite and old.  I'll not
be running anything but DNS primary on the machine. When it
is up, I want to test it and see if it can be hacked, by me.
So  a listing of "how to hack-test" your DNS primary server
of ideas would be keen too.


I wonder why the gentoo wiki does not have such information, as 
I'm sure it is commonly needed?

Any other thoughts, suggestions and ideas are most appreciated,
as I have not kept current with all of the latest dns security
issues. I cannot even find a listing of security issues, that
are strictly centric to DNS primary server issues.


James

Re: [gentoo-user] Secure DNS servers

[Michael Orlitzky]

On 06/16/2014 02:15 PM, James wrote:
> Hello,
> 
> I'm reading up on how to secure DNS primary and secondary servers.
> I guess DNSSEC is pretty important. Any other areas I should read
> up on?  It's been a few years since I admin'd a dns server....

The benefits of DNSSEC are debatable. We're moving the centralized trust
from one group of scumbags (the CAs) to another group of scumbags (the
registrars). So the benefits to authentication are not entirely clear-cut.

But, DNSSEC will eventually allow us to do away with the SSL racket, and
that can only improve security through the widespread adoption of
encryption. So it's a good thing either way.

There's a video of DJB at the 27c3 conference floating around where he
discusses some of this stuff. Some of his points shouldn't be taken
seriously, but it's entertaining nevertheless.


> 
> Also, look for gentoo centric  DNS primary solutions, I see
> no mention of hardened, up-mounted or read only partitions, 
> etc etc. I wondering if anyone has some general suggestions 
> on how to keep a gentoo dns primary only machine secure.
> 

Sven Vermeulen maintains some general suggestions here:

  http://dev.gentoo.org/~swift/docs/security_benchmarks/


> The iptables suggests seem trite and old.

Which suggestion? For a DNS server, you probably want something like,

  iptables -P INPUT DROP
  iptables -A INPUT -p ALL -i lo -j ACCEPT
  iptables -A INPUT -p ALL -m conntrack --ctstate ESTABLISHED,RELATED \
    -j ACCEPT
  iptables -A INPUT -p ALL -m conntrack --ctstate INVALID -j DROP

  # Allow SSH, up to you
  iptables -A INPUT -p tcp --dport 22 -j ACCEPT

  # And allow DNS traffic
  iptables -A INPUT -p udp --dport 53 -j ACCEPT
  iptables -A INPUT -p tcp --dport 53 -j ACCEPT

[gentoo-user] Re: Secure DNS servers

[James]

Michael Orlitzky <mjo <at> gentoo.org> writes:

> 
> On 06/16/2014 02:15 PM, James wrote:
> > Hello,
> > 
> > I'm reading up on how to secure DNS primary and secondary servers.
> > I guess DNSSEC is pretty important. Any other areas I should read
> > up on?  It's been a few years since I admin'd a dns server....
> 
> The benefits of DNSSEC are debatable. We're moving the centralized trust
> from one group of scumbags (the CAs) to another group of scumbags (the
> registrars). So the benefits to authentication are not entirely clear-cut.
> 
> But, DNSSEC will eventually allow us to do away with the SSL racket, and
> that can only improve security through the widespread adoption of
> encryption. So it's a good thing either way.

I'm just reading at this point. Listening to follks too. I have formed
no options (yet).

Here is a nice, general listing:

[1]
http://csrc.nist.gov/groups/SMA/fasp/documents/network_security/NISTSecuringDNS/NISTSecuringDNS.htm


> There's a video of DJB at the 27c3 conference floating around where he
> discusses some of this stuff. Some of his points shouldn't be taken
> seriously, but it's entertaining nevertheless.

I thought DJB was mostly deprecated. He's still preaching dns security,
yet does not update his offernings?  Interestingly strange.


> > Also, look for gentoo centric  DNS primary solutions, I see
> > no mention of hardened, up-mounted or read only partitions, 
> > etc etc. I wondering if anyone has some general suggestions 
> > on how to keep a gentoo dns primary only machine secure.
> > 
> 
> Sven Vermeulen maintains some general suggestions here:
> 
>   http://dev.gentoo.org/~swift/docs/security_benchmarks/

Sven is great.  So just the generic hardened  remedies, nothing
special to DNS servers or services, from my quick parse of his
documents on hardened?


Sven's also into "selinux". I see no selinux policies
or rules. Maybe I should drop him a line about selinux related to
dns primary servers?  Surely a selinux policy for a primary only
selinux dns server would been keen?   Not needed ? Overkill ?
I was going to read up a bit, before asking him questions I should
have discovered from robust research on the subject......



> > The iptables suggests seem trite and old.
> Which suggestion? For a DNS server, you probably want something like,
> 
>   iptables -P INPUT DROP
>   iptables -A INPUT -p ALL -i lo -j ACCEPT
>   iptables -A INPUT -p ALL -m conntrack --ctstate ESTABLISHED,RELATED \
>     -j ACCEPT
>   iptables -A INPUT -p ALL -m conntrack --ctstate INVALID -j DROP
>   # Allow SSH, up to you
>   iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>   # And allow DNS traffic
>   iptables -A INPUT -p udp --dport 53 -j ACCEPT
>   iptables -A INPUT -p tcp --dport 53 -j ACCEPT


Ah, you've added to this iptables listing:

http://wiki.gentoo.org/wiki/BIND/Tutorial


So, I am looking for a minimal listing of flags  that is sufficient 
for a dns primary server, ssh and only necessary other services
(make.conf).

I'm thinking there should be tremendously reduced set of C libraries
so as to remove potential  issues found on other services, or a 
secure, blessed C library commonly used for ultra tight servers.

I was also thinking of not mounting some partitions rw, but r only
so  a manual reboot would be need to modify settings critical to
security on the primary server. Good idea? Other similar ideas?


"eix dns" revels many servers, tools and complimentary softwares.
also, /usr/portage/net-dns/  has some ebuilds not discovered by
eix. Any recommended or useful for dns security issues?

Any guidance of those?

secure dns servers: sheerdns, maradns

TOOLS to test the security of a dns server?
fpdns, dnscap, validns, dnstop (with alarms or logging?)
dnshijacker, dnscap, dnstracer, etc etc?

New, relevant DNS RFC's ?


It's more ideas on subjects I should read up on, or specifically
targeted  responses from those current on dns security issues, like
ISP that practice dns-hijacking for their selfished desires and expose
others in the process:

[2] http://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs


CERT. I did find this singular issue: 
 Alert (TA13-088A)   DNS Amplification Attacks

[3] https://www.us-cert.gov/ncas/alerts/TA13-088A

And this compreshensive listing of dns server issues:

http://search.us-cert.gov/search?utf8=✓&affiliate=us-cert&query=all+dns+server+alerts&commit=Search

As well as a current listing of dns server issues, which is
currently empty?


Anyone and Everyone is encouraged to "chime in" on dns server
security issues, particularly related to the primary servers
issues and protection strategies.


James

Re: [gentoo-user] Re: Secure DNS servers

[thegeezer]

On 06/16/2014 08:57 PM, James wrote:
> Michael Orlitzky <mjo <at> gentoo.org> writes:
>
>> On 06/16/2014 02:15 PM, James wrote:
>>> Hello,
>>>
>>> I'm reading up on how to secure DNS primary and secondary servers.
>>> I guess DNSSEC is pretty important. Any other areas I should read
>>> up on?  It's been a few years since I admin'd a dns server....
>> The benefits of DNSSEC are debatable. We're moving the centralized trust
>> from one group of scumbags (the CAs) to another group of scumbags (the
>> registrars). So the benefits to authentication are not entirely clear-cut.
except for the preventions of dns injection/ spoof floods
>> But, DNSSEC will eventually allow us to do away with the SSL racket, and
>> that can only improve security through the widespread adoption of
>> encryption. So it's a good thing either way.
> Sven's also into "selinux". I see no selinux policies or rules. Maybe
> I should drop him a line about selinux related to dns primary servers?
> Surely a selinux policy for a primary only selinux dns server would
> been keen? Not needed ? Overkill ?
how paranoid are you?
are you using SSL and fear the heartbleed will appear here too?
> I was going to read up a bit, before asking him questions I should
> have discovered from robust research on the subject......
>
>
>
>>> The iptables suggests seem trite and old.
>> Which suggestion? For a DNS server, you probably want something like,
>>
>>   iptables -P INPUT DROP
>>   iptables -A INPUT -p ALL -i lo -j ACCEPT
>>   iptables -A INPUT -p ALL -m conntrack --ctstate ESTABLISHED,RELATED \
>>     -j ACCEPT
>>   iptables -A INPUT -p ALL -m conntrack --ctstate INVALID -j DROP
>>   # Allow SSH, up to you
>>   iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>>   # And allow DNS traffic
>>   iptables -A INPUT -p udp --dport 53 -j ACCEPT
>>   iptables -A INPUT -p tcp --dport 53 -j ACCEPT
how secure do you need this to be? how about
iptables -A OUTPUT -m state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT DROP
in case your machine gets hacked ?
do you control all the clients connecting to the DNS ? then disable UDP
dns which is what the entire world uses, and then you can much more
easily control spoof flood amplification
>
> Ah, you've added to this iptables listing:
>
> http://wiki.gentoo.org/wiki/BIND/Tutorial
>
>
> So, I am looking for a minimal listing of flags  that is sufficient 
> for a dns primary server, ssh and only necessary other services
> (make.conf).
it all depends on where the balance lays for you. do you have a text
only requirement for dns and no ssl ?
do you require ldap support or ip6 ? 
a minimal set for ISC BIND i think is nothing -- you can boot minimal
gentoo and websync and emerge net-dns/bind
a minimal gentoo running bind can easily fit with into a couple of GB
(or nothing with PXE boot) and 256MB RAM so you can have a hundred boxes
working in tandem.
assuming of course you have very small zones to load
>
> I'm thinking there should be tremendously reduced set of C libraries
> so as to remove potential  issues found on other services, or a 
> secure, blessed C library commonly used for ultra tight servers.
you might also like to consider looking at embedded setups or
alternative to glibc such as uclibc but this is a little offtopic.
> I was also thinking of not mounting some partitions rw, but r only
> so  a manual reboot would be need to modify settings critical to
> security on the primary server. Good idea? Other similar ideas?
>
A wise idea, but then you are trading off manageability for security.  
ah security, the eternal balance, and only you can know where the
tipping point lies.

Re: [gentoo-user] Re: Secure DNS servers

[Michael Orlitzky]

On 06/16/2014 03:57 PM, James wrote:
> 
>> There's a video of DJB at the 27c3 conference floating around where he
>> discusses some of this stuff. Some of his points shouldn't be taken
>> seriously, but it's entertaining nevertheless.
> 
> I thought DJB was mostly deprecated. He's still preaching dns security,
> yet does not update his offernings?  Interestingly strange.
> 

He's a security researcher, not a system administrator. Most of his
software is in the public domain if someone wants to maintain it. And
while it's getting long in the tooth, e.g. djbdns still has one of the
best track records for security -- you just won't get any new features.


> Sven is great.  So just the generic hardened  remedies, nothing
> special to DNS servers or services, from my quick parse of his
> documents on hardened?

Nothing specific to DNS, no.


> Sven's also into "selinux". I see no selinux policies
> or rules. Maybe I should drop him a line about selinux related to
> dns primary servers?  Surely a selinux policy for a primary only
> selinux dns server would been keen?   Not needed ? Overkill ?
> I was going to read up a bit, before asking him questions I should
> have discovered from robust research on the subject......

I personally don't use SELinux, so my opinion is "overkill." But that
opinion is highly colored by a lazy reluctance to learn how it works.


> 
> Ah, you've added to this iptables listing:
> 
> http://wiki.gentoo.org/wiki/BIND/Tutorial
> 

No! There's a dangerous mistake on that page that I've just fixed. This
line,

  iptables -A INPUT -p tcp --sport 53 -j ACCEPT

puts a big hole in your firewall for anyone smart enough to attack you
from port 53.

Re: [gentoo-user] Re: Secure DNS servers

[Eray Aslan]

On Mon, Jun 16, 2014 at 07:57:31PM +0000, James wrote:
> Any guidance of those?

When I have a choice, I go with nsd for authoritive and with unbound for
recursive dns servers.  Bind is also a popular alternative.

> Anyone and Everyone is encouraged to "chime in" on dns server

Try to seperate your authorative and recursive dns servers.

Learn to use dig.

On Mon, Jun 16, 2014 at 02:49:39PM -0400, Michael Orlitzky wrote:
>   iptables -A INPUT -p ALL -m conntrack --ctstate ESTABLISHED,RELATED
>   \
>     -j ACCEPT

Careful with conntrack.  It is OK for a home/hobby server.  For a high
volume dns server, you don't want to reach conntrack limits before you
reach the limits of your dns software - which are usually much higher.
A stateful firewall for a dns server is not always a good choice - do
not make it easier to DoS.

-- 
Eray Aslan <eras@gentoo.org>

Re: [gentoo-user] Re: Secure DNS servers

[Alan McKinnon]

On 17/06/2014 16:48, Eray Aslan wrote:
> On Mon, Jun 16, 2014 at 07:57:31PM +0000, James wrote:
>> Any guidance of those?
> 
> When I have a choice, I go with nsd for authoritive and with unbound for
> recursive dns servers.  Bind is also a popular alternative.
> 
>> Anyone and Everyone is encouraged to "chime in" on dns server
> 
> Try to seperate your authorative and recursive dns servers.
> 
> Learn to use dig.
> 
> On Mon, Jun 16, 2014 at 02:49:39PM -0400, Michael Orlitzky wrote:
>>   iptables -A INPUT -p ALL -m conntrack --ctstate ESTABLISHED,RELATED
>>   \
>>     -j ACCEPT
> 
> Careful with conntrack.  It is OK for a home/hobby server.  For a high
> volume dns server, you don't want to reach conntrack limits before you
> reach the limits of your dns software - which are usually much higher.
> A stateful firewall for a dns server is not always a good choice - do
> not make it easier to DoS.
> 


You could probably get away with it on an auth server as they tend to be
lighter loaded than a caching server.

But on a cache server - no ways at all.
I watched big busy dns cache servers try to deal with FreeBSD stateful
firewalls once, it was not a pretty sight :-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Secure DNS servers

[Rich Freeman]

On Mon, Jun 16, 2014 at 2:49 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> The benefits of DNSSEC are debatable. We're moving the centralized trust
> from one group of scumbags (the CAs) to another group of scumbags (the
> registrars). So the benefits to authentication are not entirely clear-cut.
>
> But, DNSSEC will eventually allow us to do away with the SSL racket, and
> that can only improve security through the widespread adoption of
> encryption. So it's a good thing either way.

While I agree with your concerns about trust, I think the good thing
about DNSSEC is that you don't have to trust as many people.

With the current SSL racket I need to trust all the folks in my
browser's CA list to not mess with my connection.  Any one of them has
the power to spoof any website on the planet, and have you seen how
long the list is?

With DNSSEC the only person who can tamper with a connection is the
domain owner, registrar, and TLD owner.  So, while Verisign can tamper
with a .com domain, they can't mess with a .uk domain, and at least
the folks who buy a .com domain know who they're getting involved
with.  With SSL Verisign can spoof any domain there is anywhere, since
the trust relationship in SSL is not limited to some domain.

I'd like to see things improved further still, but DNSSEC is a big
step in the right direction.

Rich

Re: [gentoo-user] Secure DNS servers

[thegeezer]

generally using something like ISC BIND you can set filters and easily
create an external view and internal view, so that you can do split dns
based on network connection.  if doing something like this test it and
then test it again to make sure there is no leak due to a typo.

it would be easier if we knew what you were standing up the servers for.
if it is for example your own domain name, you want something simple
like a couple of A addresses and an MX record then you don't need to
deviate much.

if you are looking for dynamic dns updates you want to make sure you
have auth by secured ip (encrypted traffic) and you want to guard your
keys to allow DDNS.

DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you
can see some starter material at ISC BIND website [1]

In terms of "hack my dns server" there are many things that can hamper
it - something at the bleeding edge like gentoo is ace for this kind of
thing (*cough* centos is prehistoric *cough*) and if you were to load up
metasploit with ISC specific filters you can try to see what is
vulnerable. you can filter by CVE on your favourite website [2]

If the server is public facing then you want to be wary of such goodies
as recursive lookups as these can contribute to DoS attacks.  you might
also like to try flooding the server with DNS or spoofed ip and see what
it responds to.  these are not necessarily dns server specific but UDP
server specific and you can start to get an idea of scalability.

in terms of primary to secondary then you have to question the
underlying layers -- is this being xferred across the internet ?
internally over vpn ?  are your secondary servers going to be full
secondaries or just caching forwarders ? how will you control zone
transfers ? consider filtering the type of queries, and the size of queries

also consider the consequences of a hack. use selinux or similar, make
sure dns running in its own username and/or namespace.  primary target
though has to be to change dns zones, so to make www.example.com map to
www.clickads.com, so make sure that you have a remote server doing
lookups regularly and report anomalies. 

hope this gives you a few directions to explore!

[1] http://www.isc.org/downloads/bind/dnssec/
[2]
https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html

[gentoo-user] Re: Secure DNS servers

[James]

thegeezer <thegeezer <at> thegeezer.net> writes:

> 
> generally using something like ISC BIND you can set filters and easily
> create an external view and internal view, so that you can do split dns
> based on network connection.  if doing something like this test it and
> then test it again to make sure there is no leak due to a typo.
> 
> it would be easier if we knew what you were standing up the servers for.
> if it is for example your own domain name, you want something simple
> like a couple of A addresses and an MX record then you don't need to
> deviate much.

Well some things will be very simple (minimal). Then, There is a "portal"
I'm researching where we run all sorts of applications very securely,
for one person at a time. It's eventually (hopefully) going to be
a full LMS Learning Management system, something comprehensive, maybe even
www-apps/moodle and or SWAD. Eventually a full ecommerce system, just
for one company, not as a service to others.

But for now, just running various forms of secure, minimized DNS. Some
machine controls (SCADA) will use the DNS  as part of the  SSL services.

> 
> if you are looking for dynamic dns updates you want to make sure you
> have auth by secured ip (encrypted traffic) and you want to guard your
> keys to allow DDNS.
> 
> DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you
> can see some starter material at ISC BIND website [1]

DNS sec will be down the road. I have time to build, test, research 
and adjust the strategy as this goes along. It's not fixing a desparate
situation; more along the lines of building up various secure dns platforms
along an increasing features set.


> In terms of "hack my dns server" there are many things that can hamper
> it - something at the bleeding edge like gentoo is ace for this kind of
> thing (*cough* centos is prehistoric *cough*) and if you were to load up
> metasploit with ISC specific filters you can try to see what is
> vulnerable. you can filter by CVE on your favourite website [2]

Yep:
http://cyberarms.wordpress.com/2014/04/20/detecting-openssl-heartbleed-with-nmap-exploiting-with-metasploit/

I got that, hense the advise is being sought out, first.


> If the server is public facing then you want to be wary of such goodies
> as recursive lookups as these can contribute to DoS attacks.  you might
> also like to try flooding the server with DNS or spoofed ip and see what
> it responds to.  these are not necessarily dns server specific but UDP
> server specific and you can start to get an idea of scalability.

One of the things I like to do, is profile the traffic, particularly
in "well behaved, machine control networks" with IP services first.
The open them up and gather some statistics, to start to develop
some heuristics for patterns and volumes of excpected and un expected
traffic flows.....

That will be for latter.


> in terms of primary to secondary then you have to question the
> underlying layers -- is this being xferred across the internet ?
> internally over vpn ?  are your secondary servers going to be full
> secondaries or just caching forwarders ? how will you control zone
> transfers ? consider filtering the type of queries, and the size 
> of queries
> 
> also consider the consequences of a hack. use selinux or similar, make
> sure dns running in its own username and/or namespace.  primary target
> though has to be to change dns zones, so to make www.example.com map to
> www.clickads.com, so make sure that you have a remote server doing
> lookups regularly and report anomalies. 
> 
> hope this gives you a few directions to explore!

Yep, THANKS!
James


> 
> [1] http://www.isc.org/downloads/bind/dnssec/
> [2]
>
https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html
> 
> 

Re: [gentoo-user] Re: Secure DNS servers

[thegeezer]

On 06/16/2014 10:08 PM, James wrote:
> thegeezer <thegeezer <at> thegeezer.net> writes:
>
>> generally using something like ISC BIND you can set filters and easily
>> create an external view and internal view, so that you can do split dns
>> based on network connection.  if doing something like this test it and
>> then test it again to make sure there is no leak due to a typo.
>>
>> it would be easier if we knew what you were standing up the servers for.
>> if it is for example your own domain name, you want something simple
>> like a couple of A addresses and an MX record then you don't need to
>> deviate much.
> Well some things will be very simple (minimal). Then, There is a "portal"
> I'm researching where we run all sorts of applications very securely,
> for one person at a time. It's eventually (hopefully) going to be
> a full LMS Learning Management system, something comprehensive, maybe even
> www-apps/moodle and or SWAD. Eventually a full ecommerce system, just
> for one company, not as a service to others.

sounds interesting. going for full interactive video distance learning
too would be a great direction to take, especially if the teacher
controls who has audio (to speak).

the only thing i would add is to keep each system seperated as much as
possible. don't put everything on one server. bad things happen to good
people so try to make sure one thing doesn't affect another.  depending
on the age of the people you are helping they probably will try to use
latest scriptkiddie toys against you first, so think about the ingress
and egress of the network and of the individual nodes when you think
about security.

> But for now, just running various forms of secure, minimized DNS. Some
> machine controls (SCADA) will use the DNS  as part of the  SSL services.
>

scada huh. i wouldn't put it on a public facing internet connection. 
even on a network connected to things i care about. i'm sure you have
good reasons, i would probably urge you to reconsider them [3]

>> if you are looking for dynamic dns updates you want to make sure you
>> have auth by secured ip (encrypted traffic) and you want to guard your
>> keys to allow DDNS.
>>
>> DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you
>> can see some starter material at ISC BIND website [1]
> DNS sec will be down the road. I have time to build, test, research 
> and adjust the strategy as this goes along. It's not fixing a desparate
> situation; more along the lines of building up various secure dns platforms
> along an increasing features set.

if your scada devices are using the public internet to get to your dns
servers i would seriously urge you to rethink things, even if you are
using dnssec.

>
>> In terms of "hack my dns server" there are many things that can hamper
>> it - something at the bleeding edge like gentoo is ace for this kind of
>> thing (*cough* centos is prehistoric *cough*) and if you were to load up
>> metasploit with ISC specific filters you can try to see what is
>> vulnerable. you can filter by CVE on your favourite website [2]
> Yep:
> http://cyberarms.wordpress.com/2014/04/20/detecting-openssl-heartbleed-with-nmap-exploiting-with-metasploit/
>
> I got that, hense the advise is being sought out, first.
>
and bear in mind the security in depth.  your perimeter will be bypassed
- what happens next is down to you.
you are looking at having possible external user generated web content
-- how do you protect other users from XSS exploits ? how about 2factor
auth for staff and/or students ?  how do you sandbox your remote apps ?
having an open network behind "the wall" is convenient, but servers in
your own network not trusting each other by default is how it should be
designed.

>> If the server is public facing then you want to be wary of such goodies
>> as recursive lookups as these can contribute to DoS attacks.  you might
>> also like to try flooding the server with DNS or spoofed ip and see what
>> it responds to.  these are not necessarily dns server specific but UDP
>> server specific and you can start to get an idea of scalability.
> One of the things I like to do, is profile the traffic, particularly
> in "well behaved, machine control networks" with IP services first.
> The open them up and gather some statistics, to start to develop

i for one would be very interested in reading of this work, should you
care to share it

> some heuristics for patterns and volumes of excpected and un expected
> traffic flows.....

there are very many companies that do this such as darktrace for one [4]
but my argument with them is that it is difficult to detect "normal"
unless you aggregate data among very large sites and use big data
statistics on them.
it wasnt' so long ago that usb dsl modems were the norm, and windows xp
had zero firewall on the dialup connection.   viruses came in within
seconds of connectivity. what happens if what you start with is not
normal ?   especially on a proving ground it is not only subject to
change but also you intend to pentest it -- is that flood of syn's
normal because it comes from your IP ? what happens if a friend visits
with his/her laptop and has a trojan that happens to be scanning your
'secure network' as part of a larger subset of networks  ?

> That will be for latter.
>
>
>> in terms of primary to secondary then you have to question the
>> underlying layers -- is this being xferred across the internet ?
>> internally over vpn ?  are your secondary servers going to be full
>> secondaries or just caching forwarders ? how will you control zone
>> transfers ? consider filtering the type of queries, and the size 
>> of queries
>>
>> also consider the consequences of a hack. use selinux or similar, make
>> sure dns running in its own username and/or namespace.  primary target
>> though has to be to change dns zones, so to make www.example.com map to
>> www.clickads.com, so make sure that you have a remote server doing
>> lookups regularly and report anomalies. 
>>
>> hope this gives you a few directions to explore!
> Yep, THANKS!
> James
>
>
>> [1] http://www.isc.org/downloads/bind/dnssec/
>> [2]
>>
> https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html
>>
>
>
>
>
[3] https://benoitis.com/beware-next-circle-hell-unpatchable-systems/
[4] http://www.darktrace.com/#/home

[gentoo-user] Re: Secure DNS servers

[James]

thegeezer <thegeezer <at> thegeezer.net> writes:


> > I'm researching where we run all sorts of applications very securely,
> > for one person at a time. It's eventually (hopefully) going to be
> > a full LMS Learning Management system, something comprehensive, maybe even
> > www-apps/moodle and or SWAD. Eventually a full ecommerce system, just
> > for one company, not as a service to others.
> 
> sounds interesting. going for full interactive video distance learning
> too would be a great direction to take, especially if the teacher
> controls who has audio (to speak).
> 
> the only thing i would add is to keep each system seperated as much as
> possible. don't put everything on one server. bad things happen to good
> people so try to make sure one thing doesn't affect another.  depending
> on the age of the people you are helping they probably will try to use
> latest scriptkiddie toys against you first, so think about the ingress
> and egress of the network and of the individual nodes when you think
> about security.

We're planning on lots of unwanted noise from a range of talented 
problem hackers. Eventually a massive VM system approach will be
deploy, but first I want to test security the old fashion way....

> > But for now, just running various forms of secure, minimized DNS. Some
> > machine controls (SCADA) will use the DNS  as part of the  SSL services.
> >
> 
> scada huh. i wouldn't put it on a public facing internet connection. 
> even on a network connected to things i care about. i'm sure you have
> good reasons, i would probably urge you to reconsider them [3]

Let me share a little background with you on SCADA. Most networks that
have SCADA on them, are really poorly secured. It's just layers upon
layers of MS crap. I do not design those sorts of machine networks.

I have been given the opprotunity of 'fix' many such networks. Most I just
walk away from. I employ techniques I would characterize as "network
partitioning" and "asymmetric traffic routing" and loads of passive
monitoring and profiling. Many scada networks have all sorts of 
improperly configured devices, bounced packets, and no sort
of 'state machine' design on what is and is not need, how often
and why. They have evolved, mostly by technicians and poorly trained
IT folks that just 'got it to work' without optimization or system
design constraints being enforced. Far too many folks and machines
are present on those critical networks. IT folks view a 20 million
dollar gas turbine, just like an expensive printer. Hacking them
is trivial. Most SCADA networks have MS servers on the same segments for
the'convenience' of all sorts of non-essential personel. To boot they
put video surveillance networks in place, so the hackers can actually
"see" the physical layout of the plants.  Stupid does not begin to
characterize the mistakes common to scada operations.

You have the very wrong impression of my scada network designs. Most
companies I talk to, do not like my 'draconian' designs, and I'm never
going to be responsible for MS inspired, stupid networks. That said
the big vendors do make billions of (scada) dollars and I search pretty
hard form companies that will listen and I like enough to work for.

Networks with many machines and without humans are easy to secure,
you just have to think out of the box a bit.... (sorry trade secrets here).
Just keep anybody with an MBA out of the process.


> >> if you are looking for dynamic dns updates you want to make sure you
> >> have auth by secured ip (encrypted traffic) and you want to guard your
> >> keys to allow DDNS.
> >>
> >> DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you
> >> can see some starter material at ISC BIND website [1]
> > DNS sec will be down the road. I have time to build, test, research 
> > and adjust the strategy as this goes along. It's not fixing a desparate
> > situation; more along the lines of building up various secure dns 
> > platforms along an increasing features set.
> 
> if your scada devices are using the public internet to get to your dns
> servers i would seriously urge you to rethink things, even if you are
> using dnssec.

Ok, so even though folks consider these 'devices' as scada, I do not.
I mostly work on industrial control systems, when I choose to do scada
work.
 
What you are referring to, something like using a cell phone to open your
front door, turn on the hot tub, or manipulate your audio gear, is not
really what I consider scada, but others do.  If those things get hacked, 
you flood a basement, illegally enter a house etc etc. Bad things but
not really catistrophic to the neighborhood.  For me, scada means 
big industry, water supply, chemical plants, manufacturing etc etc.
So if you hack them, costs rise astronomically, very quickly. Loss of
life is a distinct possibility. These types of things should not 
depend on MS anything, or using the open internet for anything. Few listen
now a days, because of the allure of sexy visual candy for folks that
do not need access to the data/controls/equipment. Large telecom companies
are the worst offenders, that why the gov. is not considering them
to mandate security standards, under the guise that it is for their
customers......


Stuxnet was a weakup call. Few listen. Far, far worse is bound to happen,
sooner or later.


> >> In terms of "hack my dns server" there are many things that can hamper
> >> it - something at the bleeding edge like gentoo is ace for this kind of
> >> thing (*cough* centos is prehistoric *cough*) and if you were to load up
> >> metasploit with ISC specific filters you can try to see what is
> >> vulnerable. you can filter by CVE on your favourite website [2]
> > Yep:
> >
http://cyberarms.wordpress.com/2014/04/20/detecting-openssl-heartbleed-with-nmap-exploiting-with-metasploit/
> >
> > I got that, hense the advise is being sought out, first.
> >
> and bear in mind the security in depth.  your perimeter will be bypassed
> - what happens next is down to you.
> you are looking at having possible external user generated web content

I'm looking for consolidated information. I have a very very good track
record for (2) things.   Keeping machines very secure and pissing
off managers by designing system with a need to know and very very
limited access. I usually save folks signficantly by using the word
"No" to all sorts of stupid ideas. One customer paid me out a fraction of
the savings they realized, for a very long time.

What managers need are reports from databases on systems, production and
security scans, not real time access......  However, go to a trade show
on scada and it's a feeding freenzy for hackers....... Vendors are putting
controls on cell phones and have security equivalent to WEP.

Thanks for your input. My goals here are building a series of dns servers
from very simple and very secure, and on up, slowly learning and creating
a portal for other to experinece what I figure out.  My techniques on
machines are pretty much unpublished and unique. In a big industrial 
environment, I teach folks to build something unique, and not follow 
the vendor main-line approach. Few listen, hence all the noise lately
about the chineese hacking industries in the US...... The sad thing 
is most industries think the US governement is watching their network,
will swoop in just in time to save them, and not make the managers look
like idiots, when press reports are leaked. They do not understand that
government agenices have a singular focus to increase their funding, and not
to protect anyone.   You nor I can get through to them, until 
after the pooper has been hacked.

idiots....abound, sorry for the digression.

peace,


James