Onderwerp: DNS queryen van subdomeinen

Niet sterk genoeg. Die kan je ook opnemen in je DNS-server als zijnde toegestane slave. Daarnaast (ik weet dat het moet) moet ik de eerste partij nog zien die daadwerkelijk secondairy blijft draaien na een verhuizing...

Je kunt prima restricties geven aan de IP's die het mogen...

Code:

Using username "admin".
Authenticating with public key "rsa-key-20081112" from agent
Last login: Fri Oct 23 13:43:19 2009 from fiberaccess.enschede.ispi.nl
-bash-3.2$ su
Wachtwoord:
[root@sv01 admin]# cat /etc/named.conf | grep allow
        allow-transfer {212.79.238.133;};
[root@sv01 admin]#

Oorspronkelijk geplaatst door Randy

Je kunt prima restricties geven aan de IP's die het mogen...

Stimmt. Daarom zie ik ook niet waarom je AXFR toe zou moeten staan

Oorspronkelijk geplaatst door DiedX

Niet sterk genoeg. Die kan je ook opnemen in je DNS-server als zijnde toegestane slave. Daarnaast (ik weet dat het moet) moet ik de eerste partij nog zien die daadwerkelijk secondairy blijft draaien na een verhuizing...

De meesten zullen inderdaad geen secondairy draaien. En als je het al zou willen zou je het ongetwijfeld kunnen automatiseren.

Maar het is een gebruik van AXFR waarvoor je het eventueel niet wil dichtzetten.

Voor de rest ben ik het uiteraard wel eens met dat het in principe gewoon dicht hoort te zitten. Zolang je je maar bewust bent van het feit dat dichtzetten het niet onzichtbaar maakt. Afgezien van dat zul je dan ook wat creatiever moeten zijn dan admin.domain.tld of intra.domain.tld

Oorspronkelijk geplaatst door Pur

. Afgezien van dat zul je dan ook wat creatiever moeten zijn dan admin.domain.tld of intra.domain.tld

Dit is nu juist het punt wat ik wilde maken, je moet de beveiliging van ditisheelmoeilijkteraden.domain.tld net zo strict maken als admin.domain.tld

Wat ik nog erger vond is dat degene die reageerde die blijkbaar in IT security werkzaam is wel ageerde op het feit dat axfr dicht moet staan, maar het heel normaal vond dat websites schrijfrechten hadden op sites van andere klanten.

Oorspronkelijk geplaatst door vDong

Dit is nu juist het punt wat ik wilde maken, je moet de beveiliging van ditisheelmoeilijkteraden.domain.tld net zo strict maken als admin.domain.tld

Uiteraard moet je beveiliging gewoon in orde zijn. Hoewel ditisheelmoeilijkteraden.domain.tld minder last zal hebben van script kiddies die hele webservers afscannen op exploits. Net zoals er zoveel scans voor exploits zijn te vinden op standaard urls zoals /phpmyadmin/

Maar dat neemt niet weg dat de zaken gewoon altijd goed beveiligd moeten worden op een hoger niveau dan security through obscurity.

Is het trouwens niet zo dat uberhaubt veel hosting providers nog steeds hun apache's onder www-data of nobody hebben draaien? Dus geen zaken zoals mod_ruid of suphp bijv? En dus alle sites op die server te raken zijn als de file permissies moet ver genoeg open staan als sitevandefietsenwinkelopdehoek.nl een security issue bevat?

Oorspronkelijk geplaatst door Pur

Is het trouwens niet zo dat uberhaubt veel hosting providers nog steeds hun apache's onder www-data of nobody hebben draaien? Dus geen zaken zoals mod_ruid of suphp bijv? En dus alle sites op die server te raken zijn als de file permissies moet ver genoeg open staan als sitevandefietsenwinkelopdehoek.nl een security issue bevat?

Dat is niet mijn ervaring, een zeer groot aantal providers (ik durf wel 99% te zeggen) werkt met control panels, die zijn op een paar enge uitzonderingen na allemaal ingericht op permissies per user en zullen (behalve misschien voor het panel zelf) niet onder www of www-data of nobody hebben draaien.