[OpenAFS] AFS in the age of the wild west internet

[Simon Wilkinson]

> On 4 Mar 2016, at 15:04, Steve Gaarder <gaarder@math.cornell.edu> =
wrote:
>=20
> How safe is it to leave AFS open to the world?

The answer to this depends on a wide variation of factors, including =
your threat model, and individual risk assessments. The most important =
consideration here is how much benefit you gain from keeping AFS =
accessible outside of the organisation, versus the potential threats =
that doing so brings. So, I=E2=80=99m not going to aim to directly =
answer this, but hopefully provide a number of things to think about.

Most of these considerations apply to targeted attacks only. AFS=E2=80=99s=
 obscurity means that it doesn=E2=80=99t feature in exploitation =
toolkits, which means that the risk of having servers compromised as =
part of a trawling exercise is less than for other, more widely deployed =
systems. This, of course, can change with little to no notice, so =
probably shouldn=E2=80=99t be relied upon!

In terms of targeted attacks, there are a number of areas of concern:

The first is transport security. Whilst the rxkad-kdf work closes a =
significant loophole in key security, it doesn=E2=80=99t fix the whole =
problem. AFS session keys remain DES only, and are as vulnerable to a =
brute force attack as any DES key. If an attacker can capture a session =
key for long lived token which has a high level of privilege, they can =
trivially gain access to your entire cell. In addition, little is known =
upon the cryptographic strength of the underlying =E2=80=98fcrypt=E2=80=99=
 algorithm. rxgk is the long term solution here.

The second is code quality. OpenAFS servers all run as root. If an =
attacker can take advantage of a buffer overflow, or similar coding =
issue, in an OpenAFS server they gain root access to the machine that =
that server runs on. It=E2=80=99s hard to say how likely it is that =
unpatched issues remain in the OpenAFS code base, but the last set of =
Coverity results I saw for OpenAFS contained 400 or so security =
sensitive issues. At AuriStor, we=E2=80=99ve fixed all of these in =
shared code. Issues that we have identified as security sensitive have =
been reported to OpenAFS, but there are also other issues which have =
been fixed without in depth analysis, and many, many more where the code =
in question has simply been removed, or completely rewritten.

The third issue is denial of service attacks. This is an emerging area =
of interest, which I don=E2=80=99t want to say too much about, but there =
are significant amplification attacks possible against RX that have =
already been discussed on other lists. It is trivially possible for an =
attacker to overwhelm a server without expending a significant amount of =
resources themselves. At AuriStor, we=E2=80=99re working with others in =
examining ways of preventing these attacks in RX. However, OpenAFS also =
has additional vulnerabilities here - its use of fixed size thread =
pools, and many fixed size data structures, means that a significant =
increase in load (be it legitimate, or malicious) can easily overwhelm a =
server. This is of particular concern for database servers, where a DoS =
attack against a small number of systems can take down the whole cell.

The fourth issue is information disclosure. OpenAFS clients (and =
servers) have historically provided a large amount of debugging =
information to aid in remote diagnosis. Many of these are used by people =
on this list to help other
cells who encounter problems. However that information (made available =
by rxdebug, cmdebug, xstat and so on) also discloses details about your =
cell, your data, and your users. OpenAFS also, by default, provides far =
more information
via the pt and vl database services to anonymous users than is required =
to allow those users to access data in your cell.
It is worth looking at all of the data that is disclosed in this way, =
and making a determination of whether that is acceptable, or whether =
some if it should be locked down.

Given all of these, if you do decide to leave your cell open to the =
public internet, there are a number of mitigating measures that you can =
take:

1) Do users on the wider internet really need to be able to administer =
your servers? If not, block =E2=80=98afs3-bos=E2=80=99 at the firewall.
2) Do you rely on any of the more intrusive =E2=80=98bos=E2=80=99 =
commands? If not, consider enabling =E2=80=98bos restricted=E2=80=99 =
mode, which significantly reduces the damage that someone who gains =
tokens for the bos service can do.
3) If you don=E2=80=99t move volumes outside of the firewall, then block =
access to the afs3-volserver port.
4) Consider locking down anonymous access to the vl database
5) Consider whether you need to provide access to the pt database to =
users outside of your firewall. Some things (managing ACLs, aklog) work =
differently if the ptserver isn=E2=80=99t available, but the cell should =
continue to function.
6) Consider partitioning your data between =E2=80=98private=E2=80=99 and =
=E2=80=98public=E2=80=99 fileservers. Keep more sensitive data on =
fileservers that aren=E2=80=99t exposed to the internet.
7) Consider keeping some of your database servers hidden from the public =
internet

Cheers,

Simon
=E2=80=94=20
Simon Wilkinson
AuriStor Inc.