When you get error 29 while trying to access a site ‘protected’ by Incapsula, check the SSL settings for the site. It’ll generally be because the site “has not got SSL” - log a support ticket and they’ll fix whatever they’ve broken.

I wanted to make a quick battery charger just for giggles, the basic requirements were “allows me to plug in a USB cable to charge my phone” - which is fairly easy to accomplish going by all the crazy devices you can buy on the market currently.

I found an eight-pack of C cell batteries at the local Kmart for $5 and I had a few other parts lying around, so I had a go in ten minutes or less.

I work in computer security lately, so I figure I should probably ensure that my site is vaguely secure 🙂 The Qualys SSL test for yaleman.org was showing a ‘B’ grade because of a few things.

Firstly it wasn’t presenting the full SSL CA chain, so I fixed that. Previously I was only presenting the certificate, with the client having to have the root CA.

1. Downloaded the ca bundle files from the details Comodo provided me.
2. Made the bundle file (their support page helped)

cat *.crt > yaleman.org.cabundle

3. Uploaded the file to the server
4. Reconfigured Apache as per the config from Comodo by adding this line to  the virtualhost SSL configuration (replace $filename with the file location)

_SSLCertificateChainFile $filename_

5. Confirmed the config by running apachectl -t, then restarted apache
6. Reran the Qualys test and that showed up OK.

The next step was to remove the SSL methods vulnerable to POODLE and FREAK

It’s taken a lot of changes, along with a hell of a lot of growing up to finally stabilize that line, and I’m feeling a lot more relaxed for having done it.

Before the graph started, I had a car crash that left me with permanent whiplash damage, changed jobs, moved houses a bunch of times and spent a lot of money on distracting myself from all of it. I ate terribly, exercised only sparingly and didn’t have a plan other than buy all the things!

So, I posted this on Facebook a while back (I started writing this in June 2013):

I wonder if the increase in childhood obesity has a weak correlation with the programs to reduce bullying?

Originally it was based on a stupid line on an episode of  8 out of 10 cats, a crazy comedy show with Jimmy Carr and a bunch of other comedians. It got me thinking about how there’s strange correlations between so many things and it’s surprising where the data shows how things are linked.

It’s a strange word, and like many fascinating words it’s German. Zettlekasten basically means “index card” and refers to a system of organising your thoughts onto cards.

The modern equivalent for us techie folk would be something like a wiki, which would allow for more efficient searching and linking between concepts. It’s a fascinating idea and something I’m going to play with.

The article has a lot more explanation than I can add, and it’s well worth a read.

Basically we’ll set up another chain for it to be forwarded to, filter the packets to move them to the chain, then a logging command created to log if packets end up in that chain.

Enabling logging

We’ll need to know where to put the filter for the redirection:

$ sudo iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
[snip]
10 DROP all -- anywhere anywhere

In this example, use line 9 on the second command.

Error on the sender end’s ($SPLUNK_HOME/var/log/splunk/splunkd.log)

02-18-2015 12:32:06.160 +1000 ERROR TcpOutputFd - Read error. Connection reset by peer

Error on the receive end’s ($SPLUNK_HOME/var/log/splunk/splunkd.log)

02-18-2015 12:31:14.423 +1000 ERROR TcpInputProc - Error encountered for connection from src=senderip:47960. error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

I checked the certificate to make sure the common name is right:

sudo openssl x509 -text -noout -in $SPLUNK_HOME/etc/auth/mycerts/sender.pem | grep Subj
Subject: C=AU, ST=Queensland, L=Brisbane, O=sender, OU=Company, CN=sender.example.com/[email protected]

/opt/splunkforwarder/etc$ sudo grep -i sender * -R

etc/system/local/server.conf:serverName = sender
etc/system/local/inputs.conf:host = sender
etc/system/local/outputs.conf:sslCertPath = $SPLUNK_HOME/etc/auth/mycerts/sender.pem

So, the common name on the certificate is different to the name presented by the server. I reissued the cert for the new server name, restart, still no no good.

SSL is great, except when you’re trying to audit access or filter things, let alone simple troubleshooting. Long story short, we run a Man In The Middle style system where our proxies are the HTTPS clients and they have an SSL certificate which all of our clients trust.

This relies on the proxies trusting the certificate chain, and these chains need to be updated periodically. Here’s an example of how to fix it when it goes wrong.

This is most definitely my favourite set of this year’s advent calendar! I hope you enjoyed the journey, I’ll be putting up a list of all the posts soon.

Have a merry Christmas!