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
