Configuring LetsEncrypt on a CentOS 6 NGinx Reverse Proxy

For those who haven't come across it, LetsEncrypt allows you to obtain free DV SSL Certificates but requires a server side script to be run periodically in order to renew the certificates (for better or worse, a 90 day expiration period has been used).

Although the provided script has plugins to allow support for automatically generating SSL certs based on NGinx and Apache configurations, the script assumes that the server is the origin and that the relevant docroot is available for writing to.

In the case of a reverse proxy - this won't be the case. We want the certificate on the Reverse Proxy (being the endpoint the client connects to) but the websites files are hosted on another server.

This documentation details a simple way to work around that on a NGinx reverse proxy (it should be possible to adjust the config for Apache's mod_proxy if needed).

Read more ...

A Practical Demonstration of what IPB will allow

There have been numerous write-ups of the threat that the Draft Investigatory Powers Bill poses to our privacy and security.

The intention of this post is not simply to repeat those, but to provide a practical demonstration of exactly the kind of information that the proposed powers would compel your Internet Service Provider (ISP) to record.

As well as demonstrating what an ISP would soon be collecting (and how simple it is to extract), we'll look at the issues the IPB presents in the context of the information we've extracted.

As the IPB isn't exactly explicit about exactly what it allows, especially in terms of techniques, I've made some assumptions (though I believe their fair and reasonable).

Most of the results were exactly what I expected, but I think describing them explicitly is probably more helpful than not - to that end, I've tried to keep the language as accessible as possible, as those who understand how tech works at the network level are unlikely to find much of surprise here.

Read more ...

Building a Tor Hidden Service From Scratch - Part 4 - Conclusion

You may not be finished

Although we've examined designing and implementing Tor Hidden Service in quite some depth, some users will likely find that there are still additional considerations that they need to make.

For example, whilst we discussed the risks of traffic leakage, we did very little to avoid it - one solution, assuming you have out-of-band access to the host system, is to add iptables rules to ensure that all TCP and DNS traffic is redirected to the ports operated by the Tor Daemon.

You'd still then need to look at filtering out other protocols (including UDP on all other ports) in case someone discovers a means to have your host system send arbitrary traffic.

Similarly, we haven't discussed the impact of your Guard being compromised, those with serious concerns may need to look at running their own guards to help reduce the effectiveness of common Hidden Service de-anonymisation attacks

It's also important to remember that this documentation may not cover threats which have not been discovered yet, security is a continuous exercise.

Read more ...

Installing and Configuring KDump on Debian Jessie

Having kdump enabled on a server provides a number of benefits, not least that in the event of a kernel panic you can collect a core-dump to help investigations into the root cause. It may simply be bad luck, but my experience with Debian Jessie has been that JournalD is absolutely hopeless in the event of a kernel panic.

Pre SystemD we used to (sometimes) get a backtrace written out to a log, even a partial backtrace could help point investigations into a rough direction, but even with JournalD configured to pass through to rsyslogd those traces just don't seem to be appearing (which to be fair, might be because of the nature of the panic rather than the fault of journald).

This documentation details the steps required to install and configure KDump on Debian Jessie

Read more ...

Building a Tor Hidden Service From Scratch - SELinux

On a system with SELinux, upon attempting to start Tor, you may see errors similar to the following

    [root@localhost tor]# service tor start
    Raising maximum number of filedescriptors (ulimit -n) to 16384.
    Starting tor: Apr 02 15:53:14.041 [notice] Tor v0.2.5.11 (git-83abe94c0ad5e92b) running on Linux with Libevent 1.4.13-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.3.
    Apr 02 15:53:14.042 [notice] Tor can't help you if you use it wrong! Learn how to be safe at
    Apr 02 15:53:14.042 [notice] Read configuration file "/etc/tor/tor-rpm-defaults-torrc".
    Apr 02 15:53:14.042 [notice] Read configuration file "/etc/tor/torrc".
    Apr 02 15:53:14.056 [notice] Opening Socks listener on
    Apr 02 15:53:14.057 [warn] Could not bind to Permission denied
    Apr 02 15:53:14.058 [notice] Opening DNS listener on
    Apr 02 15:53:14.060 [warn] Could not bind to Permission denied
    Apr 02 15:53:14.060 [notice] Opening Transparent pf/netfilter listener on
    Apr 02 15:53:14.062 [warn] Could not bind to Permission denied
    Apr 02 15:53:14.062 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
    Apr 02 15:53:14.062 [err] Reading config failed--see warnings above.
    /usr/bin/torctl start: tor could not be started

Which is almost certainly the result of a selinux policy

Read more ...