Gentoo Archives: gentoo-user

From: thegeezer <thegeezer@×××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Secure DNS servers
Date: Mon, 16 Jun 2014 22:06:57
Message-Id: 539F6A7A.9080608@thegeezer.net
In Reply to: [gentoo-user] Re: Secure DNS servers by James
1 On 06/16/2014 10:08 PM, James wrote:
2 > thegeezer <thegeezer <at> thegeezer.net> writes:
3 >
4 >> generally using something like ISC BIND you can set filters and easily
5 >> create an external view and internal view, so that you can do split dns
6 >> based on network connection. if doing something like this test it and
7 >> then test it again to make sure there is no leak due to a typo.
8 >>
9 >> it would be easier if we knew what you were standing up the servers for.
10 >> if it is for example your own domain name, you want something simple
11 >> like a couple of A addresses and an MX record then you don't need to
12 >> deviate much.
13 > Well some things will be very simple (minimal). Then, There is a "portal"
14 > I'm researching where we run all sorts of applications very securely,
15 > for one person at a time. It's eventually (hopefully) going to be
16 > a full LMS Learning Management system, something comprehensive, maybe even
17 > www-apps/moodle and or SWAD. Eventually a full ecommerce system, just
18 > for one company, not as a service to others.
19
20 sounds interesting. going for full interactive video distance learning
21 too would be a great direction to take, especially if the teacher
22 controls who has audio (to speak).
23
24 the only thing i would add is to keep each system seperated as much as
25 possible. don't put everything on one server. bad things happen to good
26 people so try to make sure one thing doesn't affect another. depending
27 on the age of the people you are helping they probably will try to use
28 latest scriptkiddie toys against you first, so think about the ingress
29 and egress of the network and of the individual nodes when you think
30 about security.
31
32 > But for now, just running various forms of secure, minimized DNS. Some
33 > machine controls (SCADA) will use the DNS as part of the SSL services.
34 >
35
36 scada huh. i wouldn't put it on a public facing internet connection.
37 even on a network connected to things i care about. i'm sure you have
38 good reasons, i would probably urge you to reconsider them [3]
39
40 >> if you are looking for dynamic dns updates you want to make sure you
41 >> have auth by secured ip (encrypted traffic) and you want to guard your
42 >> keys to allow DDNS.
43 >>
44 >> DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you
45 >> can see some starter material at ISC BIND website [1]
46 > DNS sec will be down the road. I have time to build, test, research
47 > and adjust the strategy as this goes along. It's not fixing a desparate
48 > situation; more along the lines of building up various secure dns platforms
49 > along an increasing features set.
50
51 if your scada devices are using the public internet to get to your dns
52 servers i would seriously urge you to rethink things, even if you are
53 using dnssec.
54
55 >
56 >> In terms of "hack my dns server" there are many things that can hamper
57 >> it - something at the bleeding edge like gentoo is ace for this kind of
58 >> thing (*cough* centos is prehistoric *cough*) and if you were to load up
59 >> metasploit with ISC specific filters you can try to see what is
60 >> vulnerable. you can filter by CVE on your favourite website [2]
61 > Yep:
62 > http://cyberarms.wordpress.com/2014/04/20/detecting-openssl-heartbleed-with-nmap-exploiting-with-metasploit/
63 >
64 > I got that, hense the advise is being sought out, first.
65 >
66 and bear in mind the security in depth. your perimeter will be bypassed
67 - what happens next is down to you.
68 you are looking at having possible external user generated web content
69 -- how do you protect other users from XSS exploits ? how about 2factor
70 auth for staff and/or students ? how do you sandbox your remote apps ?
71 having an open network behind "the wall" is convenient, but servers in
72 your own network not trusting each other by default is how it should be
73 designed.
74
75 >> If the server is public facing then you want to be wary of such goodies
76 >> as recursive lookups as these can contribute to DoS attacks. you might
77 >> also like to try flooding the server with DNS or spoofed ip and see what
78 >> it responds to. these are not necessarily dns server specific but UDP
79 >> server specific and you can start to get an idea of scalability.
80 > One of the things I like to do, is profile the traffic, particularly
81 > in "well behaved, machine control networks" with IP services first.
82 > The open them up and gather some statistics, to start to develop
83
84 i for one would be very interested in reading of this work, should you
85 care to share it
86
87 > some heuristics for patterns and volumes of excpected and un expected
88 > traffic flows.....
89
90 there are very many companies that do this such as darktrace for one [4]
91 but my argument with them is that it is difficult to detect "normal"
92 unless you aggregate data among very large sites and use big data
93 statistics on them.
94 it wasnt' so long ago that usb dsl modems were the norm, and windows xp
95 had zero firewall on the dialup connection. viruses came in within
96 seconds of connectivity. what happens if what you start with is not
97 normal ? especially on a proving ground it is not only subject to
98 change but also you intend to pentest it -- is that flood of syn's
99 normal because it comes from your IP ? what happens if a friend visits
100 with his/her laptop and has a trojan that happens to be scanning your
101 'secure network' as part of a larger subset of networks ?
102
103 > That will be for latter.
104 >
105 >
106 >> in terms of primary to secondary then you have to question the
107 >> underlying layers -- is this being xferred across the internet ?
108 >> internally over vpn ? are your secondary servers going to be full
109 >> secondaries or just caching forwarders ? how will you control zone
110 >> transfers ? consider filtering the type of queries, and the size
111 >> of queries
112 >>
113 >> also consider the consequences of a hack. use selinux or similar, make
114 >> sure dns running in its own username and/or namespace. primary target
115 >> though has to be to change dns zones, so to make www.example.com map to
116 >> www.clickads.com, so make sure that you have a remote server doing
117 >> lookups regularly and report anomalies.
118 >>
119 >> hope this gives you a few directions to explore!
120 > Yep, THANKS!
121 > James
122 >
123 >
124 >> [1] http://www.isc.org/downloads/bind/dnssec/
125 >> [2]
126 >>
127 > https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html
128 >>
129 >
130 >
131 >
132 >
133 [3] https://benoitis.com/beware-next-circle-hell-unpatchable-systems/
134 [4] http://www.darktrace.com/#/home

Replies

Subject Author
[gentoo-user] Re: Secure DNS servers James <wireless@×××××××××××.com>