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 |