-
Notifications
You must be signed in to change notification settings - Fork 58
FAQ
Please refer to the README.
Yes, and you should, for security reasons. There is an example config for nginx in the README. Avoid exposing Hauk on port 80 directly for privacy and security reasons.
That's up to you, but I strongly recommend against it. The traffic would be passed unencrypted, meaning others in your network can sniff on your location, get your password, and more.
Yes. You should ideally only allow traffic to port 443 with HTTPS. If clients connect with plain-text HTTP on port 80, the proxy should be set up to redirect them to HTTPS.
You probably forgot to set the public_url setting in the config file.
Most likely, you're trying to edit a config file that is not being read by Hauk, because another copy of the config file elsewhere on your system is taking precedence. Hauk will look for the config file in these locations, read the first one it can find, and ignore everything else:
- /etc/hauk/config.php
- /usr/local/etc/hauk/config.php
- hauk_install_path/include/config.php
If you're e.g. editing the config file in include/config.php, but another copy already exists in /etc/hauk/config.php, then that copy will be read because it's higher on the precedence list above, and your changes will thus not apply. Make sure that the config file only exists in one of the locations listed above.
The app version can be checked in two ways. For version >= 1.6, open the app, go to the Settings menu and scroll down to "About Hauk". For older versions, open your device's Settings, go to Apps, find Hauk and check the version number there.
The backend version can be checked by running either of the following commands in a terminal:
curl -o /dev/null -D - https://YOUR_HAUK_URL/api/create.php 2>/dev/null | grep X-Hauk-Version
wget -o /dev/null -O - --save-headers https://YOUR_HAUK_URL/api/create.php | grep X-Hauk-VersionYou can also look for the BACKEND_VERSION line near the top of the file include/inc.php on the backend.
Anyone with the sharing link. The link is 8 randomly generated letters and numbers by default.
You are encouraged not to use any public instances except for demonstration purposes. If you connect the app to a public instance, nothing prevents its administrator from logging your location with no transparency or external oversight.
Until it expires, or until you stop it.
Hauk does not save your location to disk; it is kept only in memory. Hauk uses Memcached to store its data. If you restart Memcached, the data is lost.
No. It can only be seen by people you share the link with.
No. The only connections the app make are to the Hauk server you specify.
The app requests these permissions:
-
ACCESS_FINE_LOCATION- for getting your location, so that it can be shared -
FOREGROUND_SERVICE- for keeping the share running when the app is minimized -
INTERNET- for communicating with your Hauk backend server
Set a password in the configuration file. An explanation of how is provided in the config file itself.
You can configure a reverse proxy to deny access to the root URL of Hauk if a query string is missing, so your site returns e.g. HTTP 403 or 404 if the base URL of Hauk is visited. For instructions on how to do this, and a sample configuration for nginx, see this comment.
Yes, but this is very strongly discouraged. Self-signed CAs nullifies the security benefit of HTTPS unless all users of your instance (including viewers) have the root CAs marked as trusted by their devices. Trusting a custom root CA makes all encrypted communications from these devices vulnerable to man-in-the-middle attacks by whoever owns said CA. If the CA private key is not adequately protected, and a malicious party obtains that private key, they can use it to completely undermine the security of all devices where that CA is installed.
Use Let's Encrypt's automatic certificate provisioning for your domain instead.
You can still use Let's Encrypt to get a certificate for that dynamic DNS name through webroot verification.
You can get yourself a free (sub)domain via e.g. freeDNS and get a certificate for that through Let's Encrypt.
You can use your own root CA if you wish, but the risk of doing so is entirely on you. Be aware of how usage of such a CA affects your (and others!) security before you do this. The only cases in which you need to use a custom CA is if you absolutely need to connect directly to your server via IP address, or if you run your own sslstrip MITM on your network.
Make sure that Memcached/Redis is not accessible to the public Internet. This is already done for Memcached on Ubuntu and Debian, so no further action is needed for those configurations. This is also the case for the official Hauk Docker image. If you are using another operating system, or if you are unsure, make sure that Memcached/Redis is configured to only listen on localhost (127.0.0.1 and/or ::1) and not on all interfaces (0.0.0.0 and/or ::). You can check this with netstat -tlpn. If you see something like this (note the Local Address field):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 931/memcached
tcp6 0 0 ::1:11211 :::* LISTEN 931/memcached
... then Memcached is correctly configured.
Alternatively, or additionally, you can block TCP ports 11211 (Memcached) and 6379 (Redis) in your firewall. If you're using ufw with any sane settings then this should already be done, but you can add an explicit deny rule using ufw deny 11211/tcp (Memcached) or ufw deny 6379/tcp (Redis).
Note that some guides on setting up Memcached will ask you to allow Memcached or Redis through the firewall using commands like this:
firewall-cmd --permanent --zone=public --add-port=11211/tcp
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 11211 -j ACCEPT
This is very insecure and you should never do this unless you know exactly what you are doing.