nginx

HTTP flood drop with nginx

The other day at ${DAYWORK} we got hit by a simple yet efficient DDoS attack, basically, there were lots of regular HTTP queries with a specific query parameter but using either GET, POST or HEAD methods: www.customer.com:443:80 174.76.48.233 - - [19/Mar/2020:17:26:11 +0000] "POST /?=Best_HTTP_Flooder_For_FREE_by_PassDDoS&9716 HTTP/1.0" 200 62861 "http://validator.w3.org/feed/check.cgi?url=https://www.customer.com" Fortunately, the parameter was always the same, and as we use an nginx reverse proxy farm in front of our customer’s websites, we could deploy this simple trick in order to get rid of the attack:

Let's Encrypt certificates using LEGO

This post is more like a self-reminder on how I setup automatic SSL/TLS certificate renewal on my servers. I chose LEGO to handle my certificates renewal with Let’s Encrypt because it’s simple to use, has no dependency, great documentation and is worked on at a constant pace. I found this and this articles very useful, but they are outdated in their use of the tls and http parameters. So here are my notes.

date over HTTP

I always manage to get myself into weird issues… I have this (pretty old) wrt54g router that works well with dd-wrt v3.0-r34311 vpn release. This router is installed in an apartment intended for rental where I happen to crash every now and then. It connects to an OpenVPN hub of mine so I can monit it and be sure guests renting the apartment have working Internet access. The apartment is located on a small mountain and electricity is not exactly stable, from times to times power goes down and comes back up.

Letsencrypt friendly nginx configuration

So I use this great cheat sheet in order to use letsencrypt free Certificate authority on my own servers, but while this small doc is very straightforward it doesn’t explain much about nginx’s configuration. So I’ll drop my own right here so your journey through TLS is even simpler: $ cat /usr/pkg/etc/nginx/nginx.conf # this nginx installation comes from pkgsrc for both Linux and NetBSD # you might have to adapt paths to suit your needs.

Start pkgsrc's nginx with systemd

Not so long ago, I wrote about using pkgsrc on Debian GNU/Linux, and assumed you’d start an installed service using rc.d. When I setup the new iMil.net server, I decided to give a try to kvm as it is easier to maintain, has good performances (sometimes better than Xen), nice administration tools, plus NetBSD now has a good VirtIO driver but no PVHVM support yet. The first thing I do when setting up a Debian Jessie server is getting rid of systemd, whose philosophy and quality don’t match my personnal taste; but in that case, I wanted to use libvirtd so I could manage my virtual machines with virt-manager, and as a matter of fact, libvirtd has a hard dependency on systemd.

Bypass neufbox 6 avec NetBSD (update 07/2015 NB6-MAIN-R3.4.5)

Comme je l’expliquais dans le post précédent, je suis passé chez SFR/neuf avec un forfait fibre. La box de l’opérateur, la neufbox donc, ne supportant pas de mode bridgé, quelques opérations sont nécessaires à une intégration cohérente dans votre réseau domestique. Je me suis grandement inspiré de cette excellente documentation pour réaliser le bypass de la neufbox, cependant plusieurs éléments du tutoriel ne sont plus d’actualité. Je ne rentrerai donc pas dans le détail théorique puisque l’article de neufbox4.

SaltStack: dynamic sls (updated for 0.15.3)

I’ve been learning and diving into SaltStack for about a month now, for both work and personal interest, that thing simply rocks. In the meantime, I’ve contributed a couple of modules, like bridging and Xen support, plus a couple of grains improvements for NetBSD. But most of all, I’ve been preparing my ${DAYJOB} infrastructure for Salt, and I must say this has been much easier than I thought, thanks to this beautifully designed piece of code.

auto-FQDN logging

While migrating the GCU-Squad! website to nginx, I wanted to keep the configuration as small as possible. In order to keep sites configuration files thin, I used this trick to automatically create log files using site’s FQDN: But I quickly noticed that some unwanted FQDN’s where appearing on the log directory. In order to keep control on the created files, I figured out a simple way to ensure unwanted domains to be logged in the general access.

Wordpress 3.5 and Naxsi (update 7, now in production)

Update: This setup is now in production, you are actually reading this blog through a Naxsi protected WordPress ! Update 2: This setup is also in production on GCU-Squad’s Website. I’m slowly preparing iMil.net migration to a new server. Yeah, it’s a bit confusing to be the CTO of a hosting company and having my personnal website elsewhere, but you know, time and stuff… anyway, it’s coming. While preparing the migration, I decided to get rid of Apache’s modsecurity and to put naxsi, the WAF plugin for nginx in front of the website.

Ça va pas être possible avec vos baskets

Dans ma boîte, l’équipe sécurité a publié voila quelques mois de cela un module pour nginx: un firewall applicatif du nom de naxsi. Ce module, sous licence GPLv2, je viens de le publier dans pkgsrc current sous la forme d’une option de www/nginx. Je me propose de vous montrer ici comment sécuriser simplement votre serveur web / proxy inverse nginx grâce à naxsi. Premièrement, si comme moi (et comme il se doit) vous utilisez une branche stable de pkgsrc, mettez simplement à jour www/nginx comme ceci: