Like many data storing daemons with predictable filenames, apt-cacher-ng is vulnerable to symlink attacks and similar malicious actions. Therefore, the user must make sure that the cache and log directories are writable only to the user account under which apt-cacher-ng is running.
General network access control can be established with operating system's facilities in kernel space (see below) or in user space (e.g. with inetd, see section 5.3). There is also experimental built-in access filter feature which uses the TCP Wrapper library for filtering (i.e. uses the same mechanism as tcpd). See section 5.2 for details.
As to the program's internal security, apt-cacher-ng has been developed with concern about a certain grade of attacks from internal users as well as from malicious external hosts. However, no guarantees can be made about the security of the program. It is recommended to run apt-cacher-ng under a dedicated system account which has no write access to any files outside of the cache and log directories. Refer to the manuals of the administration utilities of the system distribution (like start-stop-daemon) to create the required configuration.
If relaxed permissions are required, e.g. to make files group-writeable, this can be established through the appropriate use of umask command in the startup scripts of apt-cacher-ng (see /etc/default/apt-cacher-ng, for example) and the sticky bit on the cache directories (see chmod(1) manpage for details). However, write permissions should be assigned very carefully because that may make the server vulnerable to symlink attacks and like-minded activities.
The management web interface which allows execution of certain operations can be protected by HTTP credentials (username/password). The trust levels for most actions depend on their purpose. Those which should never be able to destroy important local files can be triggered by anyone if no password is set. And on the other hand, some operations are considered dangerous and can only be accessed when the admin password is configured and was entered correctly.
A simple control method for incoming connections is listening only to network interfaces which are inside a secure perimeter, e.g. belong to the local network. See section 8.10 for details on this configuration parameter. The default setting is listening to all interfaces.
If the access control with operating system's ip filters is not possible, the embedded filtering might be using instead. It is turned on if the feature is included at build time and the UseWrap option is set to non-zero. If UseWrap is not set at all, it might be enabled implicitly if the hosts.allow or hosts.deny files have rules for apt-cacher-ng.
For more information about host access list creation, refer to hosts_access(5) manual page (or manual pages for hosts.allow and hosts.deny).
The libwrap filtering method has a little drawback compared to alternatives. The host checks are called in single-threaded context and can add some lag for other incoming connections.
In some situations, access filtering by client IP or hostname might be not supported directly or there are other reasons to use inetd to wrap access to apt-cacher inetd. For this case, an inetd daemon is shipped with the package which makes the use of tcpd possible. Installation is done in following steps:
1. compile the inetd bridge tool "in.acng", if not already done (check /usr/lib/apt-cacher-ng).
2. Edit apt-cacher-ng's configuration (acng.conf, for example), and set a path for a new file in a writable directory, like this:
SocketPath:/var/run/apt-cacher-ng/socket
3. Edit /etc/inetd.conf and add following line with appropriate path names and TCP port:
3143 stream tcp nowait user /usr/sbin/tcpd
/usr/local/sbin/in.acng /var/run/apt-cacher-ng/socket
4. Edit hosts.allow and other files to configure ACLs for port 3143. See tcpd(8) and related manpages for further details.
5. Configure clients to use the alternative port (3143 in the example above).
Looking at performance, the most efficient way to estables access control by source IP is the use of system's native mechanisms. For the Linux kernel, it can be created with iptables rules like in the following example, usually stored in system's firewall setup script (or any init script like /etc/rc.local):
iptables -A INPUT -p tcp --dport 3142 --source 127.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 3142 --source 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 3142 -j REJECT --reject-with tcp-reset
In the default configuration, apt-cacher-ng restricts the choice of the target port on the remote mirror to the default HTTP port (80). This is intended to prevent creation of HTTP tunnels and similar malicious user activities.
Cache administrator can define an own list of allowed ports by setting them as (space separated) list with the AllowUserPorts configuration directive.
Alternatively, access to custom TCP ports can be established through custom remapping specification.