Stephan Rickauer's Hacking LabA random guy on IT Security, Hacking, Unix and Whatnot.2024-03-29T04:20:50+01:00urn:md5:47eb16560031d91589c6fada7256c7e0DotclearOpenBSD rtables and rdomainsurn:md5:1b0e15c1df5dabd43b76123482bd25332017-07-16T16:51:00+02:002017-07-16T16:51:00+02:00Stephan RickauerOpenBSD<p>Today I was playing with OpenBSD routing domains the first time. Traditionally, multiple interfaces are connected to one routing table. A global switch called 'IP forwarding' will turn packet flows between all interfaces on or off. A more fine-grained control requires some kernel level packet filtering, usually done by PF on OpenBSD. However, with rdomains one can easily isolate traffic to specific routing domains, to separate networks in kernel space.</p> <p>Excerpt from the <a href="https://man.openbsd.org/rdomain.4" hreflang="en">rdomain(4) man page</a>:</p>
<p><q>The traditional kernel routing system had a single table for routes and allowed only non-conflicting IP address assignments. The rtable feature allows multiple lookup tables for routes. The rdomain feature provides a way to logically segment a router between network paths.</q></p>
<h3>Setup</h3>
<p>The following, non-persistent example uses VLAN 71 as the underlying interface. Of course, any physical device can be specified as well. Please note one should always configure the rdomain first, interface IP second. The last command executes the route command for our newly created rdomain 71, providing a default gateway for that very routing table.</p>
<pre>
# ifconfig vlan71 rdomain 71
# ifconfig vlan71 192.168.71.1/24
# route -T71 -n add default 192.168.71.1
</pre>
<p>Our interface and rdomain should be up and running now. Note the newly appearing "rdomain 71":</p>
<pre>
$ ifconfig vlan71
vlan71: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 71 mtu 1500
lladdr 32:37:36:64:33:33
index 15 priority 0 llprio 3
vlan: 71 parent interface: vio0
vnetid: 71
parent: vio0
groups: vlan
status: active
inet 192.168.71.1 netmask 0xffffff00 broadcast 192.168.71.255
</pre>
<p>To show the routing table content, issue the route command with the already learned -T flag:</p>
<p><code>$ route -T 71 -n show</code></p>
<h3>Persistence!</h3>
<p>In order to make that configuration survive a reboot, a <em>hostname.vlan71</em> needs to be created in <em>/etc</em> as usual. It may look like this:</p>
<pre>
$ cat /etc/hostname.vlan71
rdomain 71
inet 192.168.71.1 255.255.255.0 NONE vlandev vio0
!route -T71 -n add default 192.168.71.1
</pre>
<p>Again, beware the order. rdomain definition first, IP assignments second.</p>
<h3>rdomain-aware daemons</h3>
<p>OpenBSD ships a number of daemons of which some are even rdomain-aware. Meaning, they are able to not only serve rdomain 0 but even 254 more :) One example is ntpd, that can be configured to offer network time for a specific routing table. Let's have a look at its self-explanatory configuration file:</p>
<p><code>$ cat /etc/ntpd.conf</code></p>
<pre>
listen on 192.168.26.1
listen on 192.168.71.1 rtable 71
server 0.ch.pool.ntp.org
server 1.ch.pool.ntp.org
server 2.ch.pool.ntp.org
server 3.ch.pool.ntp.org
sensor *
constraints from "https://www.google.com"
</pre>
<h3>rdomain ignorance</h3>
<p>However, not all daemons are able to handle rdomains themselves. There's a nice way overcoming this little issue: <a href="http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rcctl.8?query=rcctl" hreflang="en">rcctl(8)</a> to the rescue.</p>
<p>The following commands will 'clone' the dhcpd daemon resource script by soft-linking it, so <em>rcctl(8)</em> is able to treat them separately, with individual flags:</p>
<pre>
# ln -s /etc/rc.d/dhcpd /etc/rc.d/dhcpd71
# rcctl enable dhcpd71
# rcctl set dhcpd71 rtable 71
# rcctl set dhcpd71 flags "-c /etc/dhcpd71.conf"
</pre>
<p>One can always double check the generated <a href="https://man.openbsd.org/rc.8" hreflang="en">rc(8)</a> configuration file <em>/etc/rc.conf.local</em>. That's it! Of course, the content of <em>dhcpd71.conf</em> needs to be adjusted, so it only serves addresses for the newly created routing domain. One can now start/stop both dhcpd daemons:</p>
<pre>
# rcctl start dhcpd
dhcpd (ok)
# rcctl start dhcpd71
dhcpd71 (ok)
</pre>
<p>The <a href="http://man.openbsd.org/ps" hreflang="en">ps(8)</a> command is able to show which process is running in which routing domain, using the "-o rtable" flags (see last column):</p>
<pre>
# ps aux -o rtable | grep dhcp
_dhcp 63587 0.0 0.1 636 1508 ?? Isp 12:16PM 0:00.00 /usr/sbin/dhcpd 0
_dhcp 32192 0.0 0.1 588 1464 ?? Isp 12:20PM 0:00.05 /usr/sbin/dhcpd 71
</pre>
<h3>Packet filtering</h3>
<p>Depening on the use case, the OpenBSD packet filter is used to control the packet flow between routing domains. A couple of example rules will provide an idea of what's possible. More detailed information can be found in the according man pages: <a href="http://man.openbsd.org/pfctl" hreflang="en">pfctl</a>, <a href="http://man.openbsd.org/pf.conf" hreflang="en">pf.conf</a>.</p>
<pre>
match out on rdomain 71 to !vlan71 nat-to egress rtable 0
pass in log on rdomain 71 proto tcp to port 80
</pre>
<h3>Summary</h3>
<p>OpenBSD rdomains are a very elegant way to isolate routing traffic from each other. Daemons can serve for specific rdomains which obsolete clunky ip or listener restrictions. Management of multiple daemons of a kind is easily possible using <em>rcctl</em>. Packet flow between routing domains is managed by the packet filter <em>PF</em>.</p>
<h3>References</h3>
<p><a href="https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/">Virtualizing the OpenBSD Routing Table</a> - Joel Knight</p>https://lab.rickauer.com/post/2017/07/16/OpenBSD-rtables-and-rdomains#comment-formhttps://lab.rickauer.com/feed/atom/comments/10Recovery boot encrypted macOS Sierraurn:md5:e0375e48d45e0138c41af9f650fb50832017-01-30T20:08:00+01:002017-01-30T20:14:57+01:00Stephan RickauerMacOSSierra<p>While playing with <code>ulimit</code>, <code>launchd</code> and friends I've recently shot myself into the foot. But since it's Unix I did this very efficiently. You might know this old quote from Terry Lambert:</p>
<blockquote><p>
It is not UNIX’s job to stop you from shooting your foot. If you so
choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr. Foot
in the most efficient way it knows.</p></blockquote> <p>So I ended up with a system that wouldn't finish to boot because I've successfully changed 'maxfiles' to ... zero - actually disallowing the operating system to open any files. And thus, having a hard time to do anything useful. Including being able to revert my most intelligent change ...</p>
<p>The usual way of undoing this unwanted change is to boot off some rescue system, mount the file system in question and <code>vi</code> into that file. The challenging part (for me) was to do this on a Mac with an encrypted root partition, instead of OpenBSD or Linux. To be honest, I am not much of a macOS hacker so all you read below is basically a list of successful Google searches.</p>
<h3>Step 1: Recovery mode</h3>
<p>To get into a console / terminal you need to boot into recovery mode first. Press COMMAND-R until the Apple logo appears. From the menu you can now run the Terminal.</p>
<h3>Step 2: Find the UUID of your encrypted volume</h3>
<p>Issueing the command <code>diskutil cs list</code> will show you all CoreStorage Volumes present. The Logical Volume in question is the last one, nested under Logical Volume Group => Logical Volume Family => Logical Volume. Note that each entry has a so called UUID.</p>
<h3>Step 3: Unlock / Mount drive</h3>
<p>The last volume in the hierarchy shown is the one you'll be wanting to mount. Issue the command <code>diskutil coreStorage unlockVolume <UUID></code> where UUID is the previously mentioned ID of your encrypted disk. This will prompt you for the decryption password, unlock and mount the drive.</p>
<h3>Step 4: Edit / Removes relevant files</h3>
<p>You'll now be able to access your root file system. You may want to issue <code>mount</code> in order to see under which directory it has been mounted. Fix it, reboot and you're done.</p>
<p>I was glad to learn that this SOP would also work under macOS. Some kind of a Unix, at last.</p>https://lab.rickauer.com/post/2017/01/30/Recovery-boot-encrypted-macOS-Sierra#comment-formhttps://lab.rickauer.com/feed/atom/comments/9OpenVPN and OpenBSD 6.0urn:md5:7b6c08af003aefed9cecbd75396e4fd92016-10-15T13:23:00+02:002016-10-15T13:47:10+02:00Stephan RickauerCryptoLibreSSLOpenBSDOpenVPNPFTunnelblickViscosity<p>Over the last decade I have been installing and using OpenVPN several times, for professional and home use. However, I didn't follow its development over the last 5 years and now got <a href="https://www.admin.ch/gov/en/start/documentation/votes/20160925/intelligence-service-act.html">interested in it again</a>. In this blog post I will cover those features which were either new to me or made me struggle.</p> <h3>Prerequistes and Installation</h3>
<p>I am running OpenVPN on OpenBSD 6.0. I won't cover the installation details here which are well described in this post called "<a href="http://www.openbsdsupport.org/openvpn-on-openbsd.html">Setting up OpenVPN on OpenBSD</a>". Keep in mind you'll need two packages to install, 'openvpn' and 'easy-rsa'. The latter will pull in OpenSSL, but don't worry, OpenVPN is linked against LibreSSL from OpenBSD base - which, by the way, is yet another reason while I prefer OpenBSD over other systems:</p>
<p>$ ldd /usr/local/sbin/openvpn</p>
<pre> Start End Type Open Ref GrpRef Name
0000015eeff00000 0000015ef03a1000 exe 1 0 0 /usr/local/sbin/openvpn
00000161c26da000 00000161c2af9000 rlib 0 1 0 /usr/local/lib/liblzo2.so.1.0
0000016145aab000 0000016145f05000 rlib 0 1 0 /usr/lib/libssl.so.39.0
000001616dda6000 000001616e377000 rlib 0 2 0 /usr/lib/libcrypto.so.38.0
00000160f5840000 00000160f5d09000 rlib 0 1 0 /usr/lib/libc.so.88.0
0000016191e00000 0000016191e00000 rtld 0 1 0 /usr/libexec/ld.so</pre>
<h3>EKU vs. nsCertType</h3>
<p>Once you have installed OpenVPN and Easy-RSA you need to set up your CA and related keys. Again, the aforementioned blog post does a good job in explaining the details. Make sure you really use Easy-RSA for setting this all up. Version 3, the one that is available as OpenBSD package, takes care of all the gory details, including Extended Key Usage. Those supersede the non-standard ns* extensions (NSCertType) which should no longer be used. Instead, modern certificates leverage Extended Key Attributes to specify what they can be used for (TLS Web Server Authentication vs. TLS Web Client Authentication). This enables one to use the following line in the OpenVPN client config. For more background information consult <a href="https://www.v13.gr/blog/?p=386">this post</a>:</p>
<p><code>remote-cert-tls server</code></p>
<h3>Topology</h3>
<p>OpenVPN has three modes of operation with respect to network topology. If you happen to not run any Windows-based system you are better off to use the modern 'subnet' scheme instead of the old 'net30' which is still the default. All three available topologies are explained in the <a href="https://community.openvpn.net/openvpn/wiki/Topology">OpenVPN wiki</a>:</p>
<pre>
dev tun0
topology subnet
server 10.8.0.0 255.255.255.0
</pre>
<h3>OpenVPN Hardening</h3>
<p>There are a couple of good hardening posts out there but it's not always easy to separate the wheat from the chaff, especially when you are not a crypto guy. That said, the following configuration might not be the best at all. If you spot a mistake, drop me a comment, please. Also, make sure you did your home work: Proper permissions for certs and keys, securing your CA, choose an appropriate key size et. al.</p>
<p>OpenVPN uses two channels, one for control and one for data. Both accept configuration settings and different ciphers. A good intro can be found in the <a href="https://community.openvpn.net/openvpn/wiki/Hardening">OpenVPN wiki</a>.</p>
<h4>auth</h4>
<p>OpenVPN authenticates packets with HMAC using SHA-1 as default message digest algorithm. My OpenVPN clients range from Mac OS X to Android and I have realized my Mac is not able to connect to the server unless the default SHA-1 HMAC is used. You may be able to strengthen this to SHA256 in your environment.</p>
<pre>auth SHA1</pre>
<h4>cipher</h4>
<p>The data channel encrypts packets with BF-CBC by default, (Blowfish in Cipher Block Chaining mode) and a variable key size of 128bit. You may switch to a more modern and widely adopted cipher:</p>
<pre>cipher AES-256-CBC</pre>
<h4>TLS</h4>
<p>The OpenVPN TLS settings steer the control channel security. Two things come to mind: Enforce a minimum TLS version to skip the old and broken ones and choose a secure and fast cipher:</p>
<pre>tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256</pre>
<p>Out of various ciphers available, these seem to be the ones that balance security and interoperability. Although this may hold true for Android and Mac OS X only (haven't connected my girlfriend's iPhone yet...). The <a href="https://community.openvpn.net/openvpn/wiki/Hardening">OpenVPN Hardening page</a> mentions: "Today, OpenVPN does not support TLS-ECDHE-* or more exotic cipher-suites as there is no elliptic curve support currently."</p>
<h3>OpenBSD PF</h3>
<p>Usually, you'd probably allow all encrypted traffic ingressing the tun0 interface, by using a '<code>set skip tun0'</code> line in your '<code>pf.conf</code>'. However, since the tun interfaces are teared down and recreated by OpenVPN whenever the daemon needs a restart, pf will not skip the device but block all traffic. Either you reload your firewall rules on every OpenVPN restart or you specify an early pass of all tun traffic in your config (a third option is to have tun created by hostname.tun0 and start OpenVPN from there - which I dislike):</p>
<pre>pass in quick on tun0</pre>
<h3>Starting the Daemon</h3>
<p>Too many command line arguments are ugly. I like one can specify almost all OpenVPN options in the config file. If you even add '<code>daemon</code>' there, too, the only argument the daemon needs to be given to for launching is the location of your configuration file:</p>
<p><code>/usr/local/sbin/openvpn /etc/openvpn/server.conf</code></p>
<h3>Embedded Key Configuration</h3>
<p>All keys a client requires can be provided within the client's configuration file. That way, a user doesn't have to manage multiple files that should not get renamed or moved around on his computer. If you use embedded keys, make sure to specifiy your '<code>key-direction</code>' in your config file, too. The syntax is easy, a skeleton looks like this:</p>
<pre>
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
</pre>
<h3>Viscosity, Tunnelblick and friends</h3>
<p>OpenVPN historically uses OpenSSL, the root cause of many crypto issues. Modern operating systems like OpenBSD have chosen <a href="http://www.zdnet.com/article/openbsd-5-6-replaces-openssl-with-libressl/">to replace it</a> with a more secure, readable and maintained successor called <a href="https://www.libressl.org/">LibreSSL</a> in 2014. If you choose an OpenVPN client, you are left with the same choices, specific to your platform.</p>
<p>For example, <a href="https://www.sparklabs.com/forum/viewtopic.php?t=1787">Viscosity has no plans to link there OpenVPN client against LibreSSL</a>. However, <a href="https://github.com/Tunnelblick/Tunnelblick/issues/317">Tunnelblick has just included that change</a> in their latest beta 3.6.9beta01. Apple has already replaced OpenSSL with LibreSSL, so it's a pitty the graphical Mac clients statically link their own crypto libraries. <a href="https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-apache-http-client">Android is moving towards BoringSSL</a> in version 6. Oh, and by the way, there are even <a href="https://woohooyeah.nl/openvpn-built-with-libressl-windows-binaries/">pre-build OpenVPN/LibreSSL binaries for Windows</a> :)</p>https://lab.rickauer.com/post/2016/10/15/OpenVPN-and-OpenBSD-6.0#comment-formhttps://lab.rickauer.com/feed/atom/comments/8OpenBSD and PCEngine's APUurn:md5:a98fe597644024bdc2959bc83fcc6edc2016-08-15T11:32:00+02:002016-08-16T12:23:15+02:00Stephan RickauerOpenBSD<p>For quite a while, <a href="http://www.pcengines.ch/" hreflang="en">PCEngine's devices</a> have been known to work well under <a href="http://www.openbsd.org/" hreflang="en">OpenBSD</a>. In the meantime, their famous <a href="http://www.pcengines.ch/alix.htm" hreflang="en">Alix boards</a> have been superseded by the next generation systems called <a href="http://www.pcengines.ch/apu.htm" hreflang="en">APU</a>. At work, we wanted to build a cheap sniffing device that could be used to tap and investigate 'interesting' traffic. An ideal use case to learn about the current state of affairs: OpenBSD on APU.</p> <p>This article won't go into the mere details of system installation et. al. but describes our major learnings only. You'll find tons of information online on how to install OpenBSD on these boards. For the record, we have installed OpenBSD 5.9 on apu1d4 with 4GB RAM and T40E CPU using a 16 GB mSATA SSD with Phison S9 controller. The modem we bought is a Huawei EM770w (3G/GPS/HSPA Mini PCI Express Card). Please find the <a href="https://lab.rickauer.com/public/dmesg.txt">full dmesg here</a>.</p>
<h3>LEDs</h3>
<p>The APU has three LEDs at its front but we found all three non-functional on plain OpenBSD. The first one lights up as soon as the board gets power, but you won't be able to control the LEDs at all. There is PoC code floating around to add them to <a href="http://man.openbsd.org/gpioctl.8" hreflang="en">gpioctl(8)</a> but we didn't feel like hacking the GPIO system, which, according to <a href="http://openbsd-archive.7691.n7.nabble.com/PC-Engine-APU1-GPIO-and-LEDs-td276704.html" hreflang="en">some posts we found online</a>, needs some major overhaul. Out of scope. We live without custom LED controls.</p>
<h3>/dev/speaker</h3>
<p>To our surprise, <code>/dev/speaker</code> allowed us to make the board issue custom beep sequences, by simply sending 'letters' to it (<a href="http://man.openbsd.org/spkr.4">see spkr(4)</a>). It's great for a headless system and checking a certain status, e.g. whether your system booted successfully, established an ssh tunnel etc. Especially when the LEDs won't work either, for example:</p>
<p><code>echo "MLo2e#..c#.e..e#.." > /dev/speaker</code></p>
<h3>Push Button</h3>
<p>One thing I constantly miss with Alix/APU is the lack of a supported hardware button. It would quit all discussions on how to cleanly shut down a headless system immediately. This time we fixed it. We bought <a href="http://www.conrad.ch/ce/de/product/701074/Drucktaster-125-VAC-05-A-1-x-AusEin-SCI-R13-81A-05BK-tastend-1-St" hreflang="de">a push button which fits exactly</a> one of the two holes at the back of the enclosure. Of course, you waste one hole that you could use for a second external antenna. Once you solder the push button to the <a href="http://www.conrad.ch/ce/de/product/741213/Konfektionierte-Litze-Polzahl-Gesamt-2-Rastermass-254-mm-1-St" hreflang="de">ready-to-use cables</a>, connect them to J2 PWR and you're done. OpenBSD 5.9 nicely supports all required ACPI power states.</p>
<h3>Modem (3G)</h3>
<p>The Huawai modem is fully recognized by OpenBSD. In order to bring it online, we configured the modem as follows (Swisscom network):</p>
<p><em>/etc/ppp/peers/em770w:</em></p>
<pre>
cuaU0
connect "/usr/sbin/chat -v -f /etc/ppp/swisscom-chat"
nocrtscts
xonxoff
:0.0.0.2
noipdefault
ipcp-accept-local
defaultroute
novj
nobsdcomp
novjccomp
nopcomp
noaccomp
noauth
nomagic
persist
</pre>
<p><em>/etc/ppp/swisscom-chat:</em></p>
<pre>
TIMEOUT 10
REPORT CONNECT
ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
'' ATZ OK AT&F OK
AT+CGDCONT=1,"IP","gprs.swisscom.ch" OK
ATD*99***1# CONNECT
</pre>
<p><em>/etc/ppp/ppp.conf:</em></p>
<pre>
default:
set log Phase Chat LCP IPCP CCP tun command connect
set device /dev/cuaU0
set speed 384000
swisscom:
set phone "*99#"
set timeout 0
set ifaddr 192.168.0.199/0 10.0.0.0/0 255.255.255.0 0.0.0.0
set dial "ABORT ERROR ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5\
"" ATZ OK_ATZ_OK AT+CGDCONT=1,\\"IP\\",\\"gprs.swisscom.ch\\" OK \\dATD\\TT 40 CONNECT"
add default HISADDR
enable dns
disable ipv6cp pred1 mppe
</pre>
<h3>tcpdump(8)</h3>
<p>For our specific purpose we'd like to capture traffic ideally endlessly. Which means, as long as there is enough disk space available on our externally connected USB hard drive. However, we learned the OpenBSD <a href="http://man.openbsd.org/OpenBSD-5.9/man8/tcpdump.8" hreflang="en">tcpdump(8)</a> command would lack the <code>-C</code> flag present on the <a href="http://www.tcpdump.org/tcpdump_man.html" hreflang="en">upstream version</a>, in order to rotate the output files. Without that feature, we would simply run in the max file size limit of our FAT32 formatted hard drive (4GB). Hence, we had to come up with an ugly workaround, to imitate the rotation mechanism by a custom script.</p>
<p>This work has been primarily done by <a href="https://www.xing.com/profile/Lukas_Heusser">Lukas Heusser</a> as part of his apprenticeship project. Many thanks to his valuable work!</p>https://lab.rickauer.com/post/2016/08/15/OpenBSD-and-PCEngines-APU#comment-formhttps://lab.rickauer.com/feed/atom/comments/7Let's Encrypt on OpenBSDurn:md5:3c1cac2450ee868b491899284383e74a2016-07-14T16:45:00+02:002017-01-30T20:30:46+01:00Stephan RickauerOpenBSD<p><ins>UPDATE</ins>: <code>letskencrypt</code> has been <a href="http://undeadly.org/cgi?action=article&sid=20160901060733" hreflang="en">merged into the base system of OpenBSD</a> and renamed to <code>acme-client</code></p>
<p>When <a href="https://letsencrypt.org/">Let's Encrypt</a> has hit the planet and euphoria calmed down, I decided to give it a spin as soon as a clean, secure and simple OpenBSD client would be available. I may be late some months: <a href="https://github.com/kristapsdz/letskencrypt">letskencrypt has been published on Github</a> on May 12th, 2016 and is currently available in version 0.18. I won't go into the merits of "why yet another client". Read <a href="https://kristaps.bsd.lv/letskencrypt/">Kristaps Dzonsons page</a> on his beautiful design using isolated independent components. No Python. No Ruby. No Bash.</p> <h3>Installation on OpenBSD 5.9-STABLE</h3>
<p>Currently, there is no precompiled binary package available for 5.9. However, <a href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/letskencrypt/">for OpenBSD 6.0 there will be one</a>. A portable version allows other operating systems to easily port it over. Without digging too much, one can find a <a href="https://aur.archlinux.org/packages/letskencrypt/">Linux</a> and <a href="https://www.freshports.org/security/letskencrypt/">FreeBSD</a> version already. Let's download and compile it manually (no cause for alarm):</p>
<pre>
$ ftp -o - https://kristaps.bsd.lv/letskencrypt/snapshots/letskencrypt.tgz | tar -zxvf -
$ cd letskencrypt-0.18/
$ make && doas make install
</pre>
<p>Prepare your directory structure. Note: I will be using the <code>-m</code> flag of letskencrypt which will automagically append the domain name to your paths. This comes in handy if you'd like to structure your directories by domains - mainly for managing multiple domains on one host. Also, I have learned most people tend to store challenge files in <code>.well-known/acme-challenge</code> of your document root but I couldn't find any 'official' standard proposing that (yet).</p>
<pre>
# mkdir -p /etc/letsencrypt/my.domain /etc/ssl/letsencrypt/{my.domain,private}
# mkdir -p /var/www/letsencrypt/.well-known/acme-challenge/
# chmod 700 /etc/letsencrypt /etc/ssl/letsencrypt/private
</pre>
<h3>nginx</h3>
<p>I am using <a href="https://nginx.org/">nginx</a> as reverse proxy. The 'real' web servers are hidden behind. Therefore, my nginx needs to be told to serve Let's Encrypt challenge files locally on port 80. If you serve your web site(s) locally it's even easier: Omit the <code>proxy_redirect</code> parameter. An example for Apache is provided within the <a href="https://kristaps.bsd.lv/letskencrypt/letskencrypt.1.html">letskenrypt man page</a>. Read this <a href="https://github.com/letsencrypt/acme-spec/issues/221#issuecomment-231412373">explanation on nginx location matches</a> for the mere details.</p>
<pre>
# Letsencrypt needs http for acme challenges
location ^~ /.well-known/acme-challenge/ {
proxy_redirect off;
default_type "text/plain";
root /var/www/letsencrypt;
allow all;
}
</pre>
<h3>Get ready to rumble</h3>
<p>Once the scene has been set one can pull the trigger. The options <code>-vnN</code> will create both keys (account and domain) and report output verbosely. Here I do specify the challenge directory manually, as <code>letskenrypt</code> stores them in <code>/var/www/letsencrypt/</code> by default.</p>
<p><code># letskencrypt -vnN -C /var/www/letsencrypt/.well-known/acme-challenge/ -m my.domain</code></p>
<p>After some woodoo output you should now see a couple keys created:</p>
<pre>
# find /etc/letsencrypt/ -ls
13189 4 drwx------ 3 root wheel 512 Jul 13 15:03 /etc/letsencrypt/
13191 8 -r-------- 1 root wheel 3272 Jul 13 14:05 /etc/letsencrypt/privkey.pem
13194 4 drwxr-xr-x 2 root wheel 512 Jul 13 15:03 /etc/letsencrypt/my.domain
13195 8 -r-------- 1 root wheel 3268 Jul 13 15:03 /etc/letsencrypt/my.domain/privkey.pem
# find /etc/ssl/letsencrypt/ -ls
12849 4 drwxr-xr-x 4 root wheel 512 Jul 13 14:54 /etc/ssl/letsencrypt/
13188 4 drwx------ 3 root wheel 512 Jul 13 14:53 /etc/ssl/letsencrypt/private
13192 4 drwxr-xr-x 2 root wheel 512 Jul 13 14:56 /etc/ssl/letsencrypt/private/my.domain
13193 8 -r-------- 1 root wheel 3272 Jul 13 14:56 /etc/ssl/letsencrypt/private/my.domain/privkey.pem
13190 4 drwxr-xr-x 2 root wheel 512 Jul 13 15:03 /etc/ssl/letsencrypt/my.domain
13196 4 -r--r--r-- 1 root wheel 1647 Jul 13 15:03 /etc/ssl/letsencrypt/my.domain/chain.pem
13197 8 -r--r--r-- 1 root wheel 2139 Jul 13 15:03 /etc/ssl/letsencrypt/my.domain/cert.pem
13198 8 -r--r--r-- 1 root wheel 3786 Jul 13 15:03 /etc/ssl/letsencrypt/my.domain/fullchain.pem
</pre>
<p>For nginx you'll want to point your <code>ssl_certificate</code> parameter to the <code>my.domain/fullchain.pem</code> and naturally, the <code>ssl_certificate_key</code> to <code>private/my.domain/privkey.pem</code>. Reload your nginx and your site will serve the new certificates:</p>
<p><code># /etc/rc.d/nginx reload</code></p>
<h3>Renewal</h3>
<p>Let's Encrypt certificates are valid for 90 days only. Without a fully automated renewal mechanism, you'll waste precious life time. You can always manually check the validity period of your certs:</p>
<pre>
# letskencrypt -v -C /var/www/letsencrypt/.well-known/acme-challenge/ -m my.domain
letskencrypt: /etc/ssl/letsencrypt/my.domain/cert.pem: certificate valid: 89 days left
</pre>
<p>For automated renewal, add a <code><a href="http://man.openbsd.org/OpenBSD-current/man8/cron.8">cron(8)</a></code> job. The <code>cert.pem</code> file will be checked for its expiration on every cron run. <code>letskencrypt(1)</code> will only attempt to refresh the signature if the remaining validity period is less than 30 days.</p>
<pre>
# Update Lets Encrypt certificate(s)
0 2 * * * letskencrypt -C /var/www/letsencrypt/.well-known/acme-challenge/ -m my.domain
</pre>
<h3>Revocation</h3>
<p>Even though the short certificate life time reduces the attack surface, key compromises need to be treated urgently. <code>letskencrypt</code> will revoke your certs using the <code>-r</code> option. I haven't tested this myself yet, for obvious reasons. :)</p>
<p>:wq</p>https://lab.rickauer.com/post/2016/07/14/Lets-Encrypt-on-OpenBSD#comment-formhttps://lab.rickauer.com/feed/atom/comments/4Taking the Red Pill - Incident Response outside the Matrixurn:md5:5529d8a46ec022d906633c85092e55ec2016-06-16T16:00:00+02:002016-07-19T15:16:05+02:00Stephan RickauerCSIRT<p>For the sake of completeness I'll add the slides of my talk at <a href="https://www.first.org/">FIRST</a> <a href="https://www.first.org/conference/2016">28th Annual Conference in Seoul</a> here.</p> <p><a href="https://www.first.org/conference/2016/program#ptaking-the-red-pill-incident-response-outside-the-matrix">Original</a> abstract:</p>
<blockquote>
<p>Knock Knock … wake up, Neo. Have you ever considered taking the Blue Pill? Being fully compliant, ignoring threats of real life, enjoying warm & fuzzy cyber banalities and just sitting back hoping for trust? Would that not just fix all of our IR problems?</p>
<p>We have been there. We felt good, until our new boss has forced us to try the Red Pill … and we realized how deep the rabbit-hole goes. The Swisscom CSIRT has been redesigned from scratch in 2014, to diverge from a compliance-driven to a threat-driven approach. This has led to new ways of thinking, questioning established methods and introducing innovative ideas.</p>
<p>During this presentation we'll cover organizational as well as technical aspects. This includes pDNS, Red Teaming, Bug Bounty, ChatOps, Threat Intelligence and others. We will share our various experiences, illustrate possible pitfalls and reveal the vulnerabilities of Agent Smith.</p>
</blockquote>
<p>Full presentation at <a href="https://prezi.com/-0-yuynjqhd8/swisscom-csirt-first-2016-seoul/">prezi.com</a>:</p>
<p><iframe allowfullscreen="" frameborder="0" height="400" id="iframe_container" src="https://prezi.com/embed/-0-yuynjqhd8/?bgcolor=ffffff&lock_to_path=0&autoplay=0&autohide_ctrls=0&landing_data=bHVZZmNaNDBIWnNjdEVENDRhZDFNZGNIUE43MHdLNWpsdFJLb2ZHanI5eXNsTWVEZEV6bnZDa0JPd3dwa1NzNXNnPT0&landing_sign=fejZ6sOw1lU87i-3K-ud5ymFRLwAFfBqEJLIXnn2SCo" webkitallowfullscreen="mozallowfullscreen=" width="550"></iframe></p>https://lab.rickauer.com/post/2016/06/16/Taking-the-Red-Pill-Incident-Response-outside-the-Matrix#comment-formhttps://lab.rickauer.com/feed/atom/comments/6SSH Backdoor in Juniper Devicesurn:md5:7388e0c9cfc2095d17ed98652e69e0732015-12-22T09:46:00+01:002016-07-15T08:58:34+02:00Stephan RickauerHacking<p>Have you ever seen yourself in trouble arguing for the sake of OpenSource when it comes to transparency, security and correctness? Well, the quality of Software isn't defined by whether it is conventional (aka "closed") or OpenSource. There is good/secure closed source software around, as well as there is terrible OpenSource. And vice versa. However, there's a difference.</p> <p>Have you ever seen yourself in trouble arguing for the sake of OpenSource when it comes to transparency, security and correctness? Well, the quality of Software isn't defined by whether it is conventional (aka "closed") or OpenSource. There is good/secure closed source software around, as well as there is terrible OpenSource. And vice versa. However, there's a difference.</p>
<p>While with OpenSource, one can actually <strong>become knowledgeable</strong> about a certain correctness/security level, with closed source one basically has to <strong>rely on the vendor</strong>. That is nothing particularly bad, as long as you know the vendor is telling the truth - or, even more important: you know who is driving the vendors' interests. If three letter agencies are forcing your trusted vendor to include backdoors, you suffer.</p>
<p>Juniper has just gone through this. Well, and they are still. Just the last days, an SSH backdoor has been discovered in their ScreenOS versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20. Anyone knowing the statically stored password can log in to and "administer" your firewall/vpn gateway. (CVE-2015-7755).</p>
<p>No big news? Are Cisco users safe? Choose your poison. As <a href="https://twitter.com/Snowden/status/678245429448937472">Edward Snowden has put it</a>: <q>Juniper just *closed* backdoors in their product. Cisco's still wide open.</q></p>
<p>Here are some links on the topic, for your own research:</p>
<ul>
<li><a href="https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor">https://community.rapid7.com/community/infosec/...</a></li>
<li><a href="https://www.imperialviolet.org/2015/12/19/juniper.html">https://www.imperialviolet.org/2015/12/19/juniper.html</a></li>
<li><a href="http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554">http://forums.juniper.net/t5/Security-Incident-Response/...</a></li>
<li><a href="http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html">http://blog.cryptographyengineering.com/2015/12/...</a></li>
<li><a href="http://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/">http://rpw.sh/blog/2015/12/21/the-backdoored-.../</a></li>
</ul>
<p>
You might ask, "what should I do"? Well, I am bad in giving advices, but I use <a href="http://www.openbsd.org/innovations.html">OpenBSD based software</a> :)</p>
<p>:wq</p>https://lab.rickauer.com/post/2015/12/22/SSH-Backdoor-in-Juniper-Devices#comment-formhttps://lab.rickauer.com/feed/atom/comments/5Hello World!urn:md5:da8e0dd368ede74d7b882a4a37df6e141970-01-01T00:01:00+01:002016-07-15T09:16:33+02:00Stephan Rickauer <p>Yet another blog :/ Well, it's my personal tech blog where I mostly make notes to myself. Enjoy or ignore :)</p>https://lab.rickauer.com/post/2016/07/14/Hello-World%21#comment-formhttps://lab.rickauer.com/feed/atom/comments/3