Re: [OpenAFS] AFS in the age of the wild west internet
> On 4 Mar 2016, at 15:04, Steve Gaarder 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 I
Re: [OpenAFS] Talk slides from 2009 BPW appear unavailable?
On 5/3/2016 10:47 AM, Jeffrey Altman wrote: > On 2/29/2016 12:01 AM, Ben Rosser wrote: >> >> Is this a known issue? Is there somewhere (other than this list) I should >> file >> a bug or something? > > Ben, > > The proper place to send an e-mail would have been > webmas...@openafs.org. I have forwarded your report. > > Jeffrey Altman > The webmaster reports that the slides are once again available via the web servers. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] ad+openafs
On 5/4/2016 1:44 AM, Benjamin Kaduk wrote: > 1.6.14 doesn't need to have single-DES enabled; we shouldn't be > recommending it. The rxkad.keytab method should work fine with AES keys. > > -Ben +1 To be clear, the entire reason that the KDF extension to the rxkad security class was implemented is to permit sites to use non-DES keys for the long term AFS Key and the Kerberos session key while still using a 56-bit key with parity to support the required Fcrypt wire encryption. DES should not be enabled in Active Directory, nor in Heimdal, nor in MIT Kerberos nor in any other Kerberos KDC. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] /var/cache/openafs on btrfs
On Wed, 2 Mar 2016, Fred Drueck wrote: > Hello Everyone, > > According to the OpenAFS admin FAQ, it appears that the officially > supported file systems for the disk cache are: > > ext2 > ext3 > hfs (HP-UX) > xfs (at least on IRIX 6.5) > ufs (Solaris, ?Tru64Unix) > > which is clearly out of date, since there is a working implementation for > OS X that runs on top of HFS+ > > For some time I've been fearlessly using both ext4 and btrfs (on Linux, as > you might infer) as the backing storage for my AFS client cache. > > I have noticed some fairly rare issues with the clients if all file/db > servers (in our cell the same machines) become unavailable. The '/afs' > mount becomes un-accessible and attempts to access files often result in > very long timeouts. I've always been able to fix things by somehow long timeouts are expected when all the db servers are inaccessible. > shutting down the client (in the worst case by physical power-off and > reboot into single user mode) and deleting the cache. > > Is there some chance that this is because I've been causing these problems > by using un-supported file-systems as the backing storage for the client > cache? I think there is some chance, but this is not an area I've looked into for quite some time, and may be misremembering. I do have some recollection that ZFS behaves poorly for a cache partition, and given btrfs's similarities to ZFS, would not really recommend it either, absent further research. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] /var/cache/openafs on btrfs
ZFS requires specific tuning for use as a cache partition; otherwise, its allocation size interacts poorly with the allocation size of cache chunks, IIRC. I'd imagine something similar is true of btrfs, but I know even less about btrfs implementation details than ZFS. -Original Message- From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On Behalf Of Benjamin Kaduk Sent: Wednesday, May 4, 2016 10:21 PM To: Fred Drueck Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] /var/cache/openafs on btrfs On Wed, 2 Mar 2016, Fred Drueck wrote: > Hello Everyone, > > According to the OpenAFS admin FAQ, it appears that the officially > supported file systems for the disk cache are: > > ext2 > ext3 > hfs (HP-UX) > xfs (at least on IRIX 6.5) > ufs (Solaris, ?Tru64Unix) > > which is clearly out of date, since there is a working implementation > for OS X that runs on top of HFS+ > > For some time I've been fearlessly using both ext4 and btrfs (on > Linux, as you might infer) as the backing storage for my AFS client cache. > > I have noticed some fairly rare issues with the clients if all file/db > servers (in our cell the same machines) become unavailable. The '/afs' > mount becomes un-accessible and attempts to access files often result > in very long timeouts. I've always been able to fix things by somehow long timeouts are expected when all the db servers are inaccessible. > shutting down the client (in the worst case by physical power-off and > reboot into single user mode) and deleting the cache. > > Is there some chance that this is because I've been causing these > problems by using un-supported file-systems as the backing storage for > the client cache? I think there is some chance, but this is not an area I've looked into for quite some time, and may be misremembering. I do have some recollection that ZFS behaves poorly for a cache partition, and given btrfs's similarities to ZFS, would not really recommend it either, absent further research. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info :�� T���&j)b� b�өzpJ)ߢ�^��좸!��l��b��(���~�+Y���b�ا~�~ȧ~
Re: [OpenAFS] Request for Assistance with OpenAFS
On Wed, 16 Mar 2016, Nicolas Melot wrote: > Hi, > > I'm trying to setup and use openafs for mobile nodes, not always having a > connection to the openAFS server. I would like to use the openAFS caching > mechanism as an offline disk that synchronizes everything once online again. > > I installed an openAFS 1.6.9 server and client, together with a kerberos > server on debian jessie. Everything works great, including offline operations > and synch after the client is back online. However, I fail of open a afs > session on the client machine while it is offline. To rule out a lack of > kerberos ticket, I installed a kerberos replica on the client machine and I > can get a ticket offline. However, even with a valid ticket, AFS's cache > manager doesn't give access to the files. > > Investigating more and reading the doc, my understanding is that the cache > manager doesn't look for anything to confirm the authorization granted by the > kerberos ticket presented. However, I still fail to open an AFS session with > an offline machine. I think this is because the cache manager requests > information from the protection database (I guess some kind of ACLs) and since > it can't contact it, then it doesn't give access to files at all. This is not exactly true; in normal operation, it is the fileserver that consults the protection database and determines whether a user is authorized to access a given resource. > In a desperate attempt to reach my goal, I started to set up at protection > database replication into the client and see what happens.. well, it looks > like I need to identify protection database server (including the replication > installed in my client machine) with ip addresses. The problem is that both > databases (the original and replica) check if the ip address of machines are > the same in both ends before allowing a replication to happen. That means I > can't configure the client so it connects to 127.0.0.1, which would be the > only way t contact the local protection database when offline, so this > solution doesn't seem to work either. I don't think that having a local protection database is a fruitful area of research; the ubik database synchronization protocol is not really scalable, and is generally used with only 3 or 5 peers. (There is also a hard cap in the current implementation, which might be 16; I forget the exact number.) > Then, finally my question (s): is it possible at all to have openafs working > in offline mode, including opening a session, even if I need to run a Kerberos > and a protection database replica on the client for it (even if that sounds > like a bad idea). Is it possible to prevent the original and the replica > protection databases from checking if the ip addresses are the same, so that I > can have the client machine to contact its local replica of the protection > database on 127.0.0.1 and the original protection database server to contact > the replica through its ip address on the network; better: through its dns > name only. I think what you want would require further development on the offline mode, which in its current state remains an experimental feature but has not seen any significant resources invested in it for several years. I do not have an estimate for the amount of work that would be necessary, but will say that I expect it to be measured in man-years. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
