139 lines
4.6 KiB
ReStructuredText
139 lines
4.6 KiB
ReStructuredText
=======================
|
|
Security considerations
|
|
=======================
|
|
|
|
Transmission security
|
|
=====================
|
|
|
|
Use https for the web interface as well as for the update client (if possible).
|
|
|
|
Otherwise, your username / password (FQDN / update secret) will be transmitted
|
|
in clear text (unencrypted).
|
|
|
|
The web interface will warn you if you use it via http. If WE_HAVE_SSL is
|
|
set to True, it will suggest you better use the https site and link there.
|
|
|
|
Additionally, the service administrator can implement a redirect from the
|
|
http to the https site within the webserver configuration for the WWW_HOST.
|
|
The redirect should **not** be implemented for WWW_IPV4_HOST and WWW_IPV6_HOST
|
|
as it is unknown whether all update clients can deal with a redirect.
|
|
|
|
For the router / update client configuration examples we show when creating a
|
|
update secret, we use update URLs with https: (and we also tell why it might
|
|
not work).
|
|
|
|
On the hosts overview page, we show whether we received the last update via SSL.
|
|
|
|
|
|
Passwords / Secrets / Keys
|
|
==========================
|
|
|
|
Interactive login password
|
|
--------------------------
|
|
|
|
We recommend that you use a rather strong and not guessable password for this.
|
|
Do not re-use passwords, use a password system or a password manager.
|
|
|
|
The interactive login password for the web site is stored using Django's
|
|
default hasher mechanism, which is currently pbkdf2 (a very strong and
|
|
intentionally slow password hash). Brute-Force attacks against such hashes are
|
|
very slow, much slower than against simple hashes like (s)sha1/sha256 etc.
|
|
|
|
It is NOT stored in clear text by nsupdate.info.
|
|
|
|
If you lose the password, you'll have to do a password reset via e-mail.
|
|
|
|
|
|
Automated update secret
|
|
-----------------------
|
|
|
|
The automated update secret for routers or other update clients is a
|
|
random and automatically generated secret. We store it using the sha1 hasher
|
|
of Django (which in fact is salted-sha1, a not very strong, but fast-to-compute
|
|
hash).
|
|
|
|
Considering that a lot of routers or update clients store this secret in clear
|
|
text in their configuration and often transmit it using unencrypted http (and
|
|
not https), this secret is not too safe anyway. We also wanted to save some cpu
|
|
cycles here and rather not use pbkdf2 for this regularly and automatically used
|
|
secret.
|
|
|
|
It is not stored in clear text by nsupdate.info.
|
|
|
|
If you lose the secret, you'll have to generate a new one and change it in your
|
|
update client also.
|
|
|
|
|
|
Nameserver Update Key (backend, RFC 2136)
|
|
-----------------------------------------
|
|
|
|
We currently store this key (which is basically a base64 encoded shared secret)
|
|
"as is".
|
|
|
|
This is somehow critical, but also hard to do better - encryption would only
|
|
help very little here as we would need to decrypt the update key before using it,
|
|
so we would need the unlocked key of that encryption mechanism on the same machine.
|
|
|
|
Make sure no unauthorized person gets that key or he/she will be able to update
|
|
ANY record in the respective zone / nameserver directly (without going over
|
|
nsupdate.info software / service).
|
|
|
|
We support creating random update keys, so you don't need an extra tool for this.
|
|
|
|
|
|
CSRF protection
|
|
===============
|
|
|
|
We use Django's CSRF protection middleware.
|
|
|
|
|
|
XSS protection
|
|
==============
|
|
|
|
Django's templating engine html-escapes inputs by default.
|
|
|
|
|
|
Cookies
|
|
=======
|
|
|
|
The software ("as is") uses these cookies:
|
|
|
|
* "csrftoken" (host-only, for CSRF protection)
|
|
* "sessionid" (host-only, to keep the session when you have logged-in to the
|
|
web interface)
|
|
|
|
If you have set WE_HAVE_SSL to True (because you run the software on a https
|
|
site), you should also set *_COOKIE_SECURE to True to avoid the cookies getting
|
|
transmitted via http.
|
|
|
|
Be careful with domain cookies
|
|
------------------------------
|
|
|
|
The software ("as is") does not use any domain cookies.
|
|
|
|
In case you modify the software, please be extremely cautious with domain
|
|
cookies and in case of doubt, do rather not use them.
|
|
|
|
If you use domain cookies (like for ".yourservice.net", the leading dot
|
|
makes it a domain cookie), all hosts in that domain would be able to read
|
|
and write these cookies. Your site (at e.g. www.yourservice.net), but also
|
|
users' sites (like attacker.yourservice.net).
|
|
|
|
Obviously, this might lead to security issues with stealing, modifying and
|
|
faking domain cookies.
|
|
|
|
|
|
Sessions
|
|
========
|
|
|
|
We use Django's more safe JSONSerializer to serialize session data.
|
|
For Django >=1.5.3, the serializer is configurable.
|
|
For Django >=1.6 json will be the default rather than the less safe pickle format.
|
|
|
|
|
|
Django's SECRET_KEY
|
|
===================
|
|
|
|
Well, it needs to be secret, so don't just keep the value from our settings.py,
|
|
but define a really secret one in your local_settings.py.
|