> On 4 Mar 2016, at 15:04, Steve Gaarder <gaar...@math.cornell.edu> wrote: > > 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’m 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’s obscurity means that it doesn’t 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’t 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’t 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 ‘fcrypt’ 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’s 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’ve 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’t 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’re 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 ‘afs3-bos’ at the firewall. 2) Do you rely on any of the more intrusive ‘bos’ commands? If not, consider enabling ‘bos restricted’ mode, which significantly reduces the damage that someone who gains tokens for the bos service can do. 3) If you don’t 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’t available, but the cell should continue to function. 6) Consider partitioning your data between ‘private’ and ‘public’ fileservers. Keep more sensitive data on fileservers that aren’t exposed to the internet. 7) Consider keeping some of your database servers hidden from the public internet Cheers, Simon — Simon Wilkinson AuriStor Inc. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
