Should I be upgrading all my dependencies on a regular basis?

For projects I maintain, I try to keep dependencies up to date on a regular basis. But not all people work like that, some live by the adage of "if it ain't broken don't fix it", but that is not an approach I subscribe to in software development.

A common reason to update software dependencies is to fix security issues or bug fixes that plague the project at hand. My main argument in favour of making more frequent updates is that when you suddenly need to make an update (because of an imminent security threat) it won't be hard; when dependencies haven't been updated in a long time it can be hard to to make the update.

There are risks involved in updating dependencies: A new version might introduce breaking changes, things that you rely on suddenly don't work or exist anymore. It might even introduce new bugs that may not be apparent on the first run. And when your test suite is not on par, verifying if everything works as expected is time consuming. But that can all be address…

Block troublemakers using fail2ban

I don't mind running my own virtual servers. Fail2ban is a tool I've had running on my servers for years. It helps fencing of requests from ip-addresses that repeatedly misbehave when connecting to SSH and postfix. I never got to creating my own rules. I thought I had to write it in some arcane scripting language, but recently I learned it is pretty easy.

In this case I wanted to block 500 (internal server error) and 422 (Unprocessable Entity) errors. A server error once in a while is expected, but repeated server errors are suspicious. Common source of these errors are scripts that scan for things like SQL injections.

Examples given are for Debian.

/etc/fail2ban/filter.d/nginx-errors.conf

[Definition]

failregex = ^ -.*"(GET|POST|HEAD).*HTTP.*" (500|422)
port = http,https
ignoreregex =
backend = auto
logpath = /var/log/nginx/access.log
bantime = 600
maxretry = 10

And appending to /etc/fail2ban/jail.local…

Het groene slotje en Symantec

Veilige verbindingen zijn gebaseerd op een keten van vertrouwen. Browsers en computers vertrouwen standaard een beperkt aantal zogenaamde ‘root’-certificaten. Deze root certificaten kunnen gebruikt worden om een groen slotje te geven aan een site. Meestal gebeurd dat met een tussenliggend certificaat: De site betrouwbaar omdat deze Certificaat A heeft welke vertrouwd is omdat het ondertekend is door Certificaat B en Certificaat B wordt vertrouwd omdat het ondertekend is door een root certificaat (de keten kan complexer en langer zijn); een certificaat dat vastgelegd is in de browser of het besturingssysteem. Het is dus belangrijk dat een beheerder van een root certificaat er alles aan doet dat diens vertrouwen niet wordt geschonden. Dat is vorig jaar bij Symantec (het bedrijf dat bekend is geworden met Norton Utilities en later AntiVirus) gebeurd.

Certificaten mogen alleen worden uitgegeven aan eigenaren van een domeinnaam; certificat…

Becoming your own local certificate authority (and issue your first certificate)

It has been quite some time ago, but here is another 'how i do it' article :)

If, by 'accident' you have, like me, chosen projectname.dev for your local development as a convention, and you want to continue using this convention; you will need to become your own CA. There is no other way around it. I tried searching disabling HSTS for localhost.dev, certificate for localhost.dev, but to no avail. Being your own CA, however, makes you HSTS proof (note that you can’t typically override an already set HSTS certificate, that is by design). However, in the old days you could simply mark your own self-signed certificate as trusted for your own domains. This is becoming less of an option these days. Becoming your own CA, however, still is an option.

Warning: The chain of trust

You should trust yourself not share your rootCA’s key and cert with anyone e…

Let’s encrypt! It’s easy!

There important reasons to use HTTPS. It makes your systems more secure, helps to protect your users privacy, and will prevent others to hijack your account to deface your site.

If you’ve ever tried to secure your site you may have found how hard it is. You have to generate a private key, a certificate signing request, upload that request somewhere, pay, process the e-mail, upload the certificate, configure your server and set a reminder that in 1, 2, 3 or 5 years you’ve got to go through most of that same process again (which I described before in more detail in an earlier "how I do it"-article. Well, no longer! Enter: Let’s encrypt.

> Actually, Let’s encrypt is so easy that I had doubts whether I should even write this post. But maybe it wins an extra soul or two over.

The recommended way to get sta…

Setting up https/spdy communication for your website with nginx

In case you do something with user accounts on your website, you definitely want to make sure you're using https. In general it protects the user's privacy, also when just reading content on your website. The only thing that can be seen by a middleman is that the person is viewing something at your server, the rest is all encrypted. And since Google has started to rank https-websites higher it has even become a SEO technique :) ). This article explains you how to serve your pages over https.

Update: a better option exists nowadays for non-domain validated certificates: Let's encrypt!

While the path to your server from someones desktop could be considered relatively ok in the past (harder to tap, putting a lot of trust in everything from the ISP to the internet exchanges and everything else in between), things have changed now. Wit…

A somewhat secure Debian server with nginx, Passenger, rbenv for hosting Ruby on Rails with mail support and deployment with Capistrano

Basically this is a technical note to myself, in case I need to setup another server for running yet another personal Ruby on Rails project. And don't worry, I'm not going to replicate all nice guides out there, just filling in the gaps.

So let's start with the list of bookmarks I follow as a start. Note that in these tutorials mostly a user is used named 'deploy'. Typically I create a user per project and name databases etc. accordingly.

1. Get security right first: My first 5 minutes on a server or essential security for Linux servers
2. Then I get Rails up and running with this how to install Ruby on Rails with rbenv on Debian
3. (in case you want to use the server as your remote git repo too) [Git setting up a …

No signing in

IMPORTANT: the assumption made here is incorrect. I suggested using a hashing function, but one should make a special message authentication code function such as HMAC…

A thing I've been rediscovering as of late is the bookmarklet. Not that I use many, but in contrast to many of the browser extensions, bookmarklets are really minimalistic and hence very simple to use (although installing them on mobile devices is not) pieces of software. Currently I use the Tumblr, Instapaper and Pinterest bookmarklets, but they all share a common problem: they require you to authenticate before you can actually use them.

Not satisfied with the third parties, not satisfied with hot they work…

I'm using the Tumblr blogging service simply because it makes posting, via its bookmarklet, easier than posting s…

Oplossingen die wel werken zijn veiliger.

Waar vroeger de gaafste machine’s bij professionele instellingen stonden staan deze nu bij de mensen thuis. ‘Het werk’ kan inmiddels gedaan worden op machine’s met de kracht van misschien wel 10 jaar terug. En ondertussen dendert de trein die voldoet aan Moore's law voort: snellere en krachtige machine’s voor minder geld. Consumenten blijven wel doorkopen en inmiddels zijn thuis apparaten waar menig bedrijf… nee ze zijn niet jaloers, de bedrijven zijn inmiddels trots op hun super-beheersbare systemen. Dat ze qua gebruiksvriendelijkheid ook in eind jaren 90 zijn blijven steken doet daar niets aan af. Of wel?

Het is een trend die lijkt te breken. De jongeren nemen gewoon hun betere en slimmere ‘telefoons’ mee, met betere kalender en e-mail functionaliteit dan de standaard telefoons die ze uitgereikt krijgen. Vervolgens worden deze naar wens aangevuld met vele extra communicatiekanalen die hen in staat stelt hun werk sneller gedaan te krijgen. Het is jammer dat sommige instelling…

Hacken is creatief programmeren

“Dat's de bom man.” op een luchthaven zeggen kan waarschijnlijk ook tot problemen leiden. Toch is het, mogelijk alweer achterhaalde, opmerking die positief bedoeld is. En zo is hacken ook een positieve bezigheid, alleen…

Onlangs floepte er bij mij in net de verkeerde context het volgende eruit: “Ik heb wel een beetje een hack mentaliteit”. Ik was op kennismakingsgesprek voor een nieuwe opdracht bij een bank. Aj. In de IT wereld wordt hacking als iets positiefs gezien: schouders er onder, niets is onmogelijk, kijk maar… En als het niet kan zoals we van plan waren, dan lossen we het wel net iets anders op.

In plaats van te zuchten en kreunen over hoe de ideale werkelijkheid - die toch niet bestaat - er uit zou moeten zien probeert een hacker met zo min mogelijk moeite de bestaande systemen zodanig aan te passen dat het doel behaald wordt1. Niet alles eerst proberen te bedenken vanuit dat perfecte ideaal om er vervolgens achter te komen dat dit toch niet werkt of nog ma…