Securing Your Server
By default the server is open to the world; which means that anybody who can connect to your server can browse or play any of your available music, see your statistics, or perform searches.
If you wish to impose tighter controls you have two options:
IP Address Restriction
Allowing Addresses
This is the simplest method of restricting which visitors can browse and stream your music. Edit the configuration file and include all the IP addresses, or ranges which you'd like to be able to use your via the 'allowed_clients' setting.
If you wish to enable everybody to access the server then leave the setting as it is by default 'allowed_clients = all' - otherwise follow the examples to limit access, eg:
# Limit the clients who can connect and use your server by IP address. # # Multiple entries are allowed - simply seperate the values by ';' as # shown in some of the examples below. # # Only people on the same subnet, (class C): # allowed_clients = 192.168.2.x # # Only one machine may connect: # allowed_clients = 192.168.2.12 # # Everybody local, and one remote address: # allowed_clients = 192.168.2.x; 194.247.82.33 # # Everybody local, and one remote range: # allowed_clients = 192.168.2.x; 194.237.82.x #
Denying Addresses
To complement the 'allowed_clients' option there is a matching 'denied_clients' setting which allows you to deny particular address.
The deny options take precendence over the allowed options, so in the following example all the IP addresses in the 192.168.2.x range have acesses except 192.168.2.2, and 192.168.2.44
allowed_clients = 192.168.2.0/8 denied_clients = 192.168.2.2; 192.168.2.44
Restrict access via password protection
You may also restrict access to the server by username + password. This is enabled by default you just need to create a password file inside your music repository.
The password file must be called '.password' and should contain a list of all the usernames and passwords which are accepted. (Note that this file must be readable to the user which the server is running as).
The password file is assumed to be in the following format:
username1:password1 username2:password2 username3:password3 ... usernameN:passwordN
If the visitor enters a valid username and password they will be able to browse - otherwise they won't.
Password Protection Evasion
Every few months a user will report a security issue with the server when they realise that if they know the name of an audio file they can download it without being prompted for a password.
This is a deliberate hole. Although that might seem nonsensical its mandated by the way the server works.
If you enable the password protection what you are actually doing is denying random visitors the ability to browse your music archives GUI, including the playlists.
However you're not protecting against the users who know what directory structure you have - if a remote user knows you have the following file they can download it directly:
http://some.host.name:port/foo/bar/test.mp3
Why is that?
It's because 99% of available MP3 players know nothing of HTTP authentication, which is used to prompt visitors for their password.
If we protected the audio files as well as the GUI files then the client MP3 players would be unable to download the audio tracks and streaming would break for all users.
So, whilst the password protection is useful, and does stop somebody from discovering your archive structure it doesn't give foolproof protection.
I'll reiterate this one last time:
If you want full security restrict access by IP addresses and only allow known-good clients to connect.