Here's a status update on the alpha cryptofree server:
Code: Select all
[[email protected] ~]# uname -a
Linux cf-i 3.17.1-cryptostorm #1 SMP Sat Oct 25 10:15:40 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux
On this server, we're running a hardened kernel, most of which consists of the grsecurity kernel patches (see http://grsecurity.net/).
Here's a copy/paste from their website:
Grsecurity is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats through intelligent access control, memory corruption-based exploit prevention, and a host of other system hardening that generally require no configuration. It has been actively developed and maintained for the past 13 years.
Only grsecurity provides protection against zero-day and other advanced threats that buys administrators valuable time while vulnerability fixes make their way out to distributions and production testing. This is made possible by our focus on eliminating entire bug classes and exploit vectors, rather than the status-quo elimination of individual vulnerabilities.
Unlike the LSMs you're used to, grsecurity tackles a wider scope of security problems. While access control has its place, it is incapable of dealing with many real-life security issues, especially in webhosting environments where an attacker can fraudulently purchase local access to the system. To see what you're missing out on by relying on just access control, see our feature comparison matrix.
A major component of grsecurity is its approach to memory corruption vulnerabilities and their associated exploit vectors. Through partnership with the PaX project, creators of ASLR and many other exploit prevention techniques -- some now imitated by Microsoft and Apple, grsecurity makes many attacks technically and economically infeasible by introducing unpredictability and complexity to attempted attacks, while actively responding in ways that deny the attacker another chance.
Grsecurity confines its changes to the Linux kernel itself, making it possible to use with any distribution or device: embedded, server, or desktop. Use your existing distribution's kernel configuration if you wish and answer a simple series of questions about your use case to optimally configure grsecurity automatically. X86, ARM, or MIPS -- grsecurity has been developed for and used on them all and many more.
Grsecurity has been developed and maintained since 2001, from the very first 2.4 Linux kernel to the latest and greatest 3.x. In addition to tracking the latest stable kernel, we provide stable releases for both the 3.2 and 3.14 kernels with additional security backports.
We stay on top of -- and in many cases drive -- the state of the art in security research. While the security teams of Linux distributions react to the latest widespread exploit simply by fixing the associated vulnerability, we quickly work in addition to close down any new exploit vectors, reduce the chance of similar vulnerabilities, and insert additional roadblocks for ancillary techniques that made the exploit possible or reliable.
As a result of this extensive approach, it is not uncommon to find in the event of a published exploit, particularly against the kernel, that the exploit's success is prevented by several separate features of grsecurity.
Grsecurity is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats through intelligent access control, memory corruption-based exploit prevention, and a host of other system hardening that generally require no configuration. It has been actively developed and maintained for the past 13 years. Commercial support for grsecurity is available through Open Source Security, Inc.
In addition to the grsecurity patches, we've also disabled ALOT of kernel features that we have no reason to support, and that also have been known in the past to provide exploitation vectors under certain circumstances (Bluetooth, WiFi, USB, ancient hardware support, sound related things, etc.). Once we get past the mongo bug @ https://jira.mongodb.org/browse/SERVER-12991 (the fix on that page doesn't work for us), we can push this kernel to all the other nodes. So in the extremely unlikely event that someone ever does get shell access to one of our nodes/servers, it's going to be very difficult for them to get root. Of course, we implement other security features to help minimize that possibility (firewalls, SSH keys, insanely complex passwords where passwords are needed, latest version of whatever programs are used on the server, bare minimum services running, etc.)
That's the security side of things (not to mention the usual strong crypto we already do on all the other servers). As for cryptofree's actual launch, we're getting very close. Everything seems to be good on the server except for the bandwidth throttling. We've been doing tests with the linux `tc` command and it appears to be working sometimes, while other times it doesn't. Also, we're not sure if the current throttling code will limit a single IP's session or the overall bandwidth on the entire NIC, or if it's only for ingress or egress (upload/download speeds).
So a few more tests are required, but we're almost there!
P.S. If anyone with a fast connection is willing to be a guinea pig for cryptofree, I'm usually on the CS chat room around noon CST. You can get there by clicking the "LIVE CHAT" banner on the top right of this page, or by going directly to https://cryptostorm.nu/chat . Basically, the only testing needed is for you to connect to a specific OpenVPN server and report back your upload/download speeds.
AND HAPPY HALLOWEEN!!!