I have recently moved this, and a bunch of other sites I host, over to new infrastructure.

Unfortunately, for reasons I won’t bore you with (mainly because I’ve not yet figured them out), the standard ip-tables ban action in fail2ban has stopped working. However, since I am already behind a firewall, all I really need is to block the script kiddie attacks for the various website logins.

I already have some filters for this, so I wrote some quick actions to add these IP addresses to ban lists that can be used by Apache.

I have two flavours, one for apache 2 and another for apache2.4.

Usage

Copy the appropriate action config into your /etc/fail2ban/action.d directory, and enable the action in the usual way.

Then, to actually use the block list, you’re going to need to include it into your vhost config by referencing it in your <directory> block, e.g.:

<RequireAll>
    Require all granted
    Include /var/run/fail2ban/fail2ban.apache24
</RequireAll>

Link to fail2ban.apache for the apache 2 version.

Hope this is useful to folks!

» Visit the project on Github...

Just a very quick one, really as a aide-mémoire for when this inevitably happens again and leaves me scratching my head.

So, if you’re creating a foreign key relationships between two tables in your mysql / mariadb database, and you get errors along the lines of:

errno: 150 "Foreign key constraint is incorrectly formed"

or

Failed to add the foreign key constaint. Missing index for constraint 'BLAH' in the referenced table 'whatever'

and you’ve checked that your statement is correctly constructed and otherwise correct, check that the tables in question are the same collation using show create table TABLENAME

It is easy to miss, but foreign keys can only exist between tables of the same table collation and type. So, if they’re different, you’ll need to do an alter table, e.g.

alter table TABLENAME convert to character set utf8 collate utf8_unicode_ci;

Hope this helps someone!

Going on 5 years ago, I had to do some integrations with SimpleSAMLPhp for a client. Now, in a Day Job, one of my colleagues is trying to get an integration working, and I’m amused that they find that my post is top hit when they google the error.

Anywho… what I wrote in my post wasn’t working, so I had to dig a little deeper.

Logins were working, but not from Chrome.

After digging into it a little, I found that SameSite headers were being set on the cookie, but no Secure flag.

This is Not Good, and so a lot of the more security focussed browsers will ignore these headers. You can even see this if you look at your developer tools.

Ok, so set the secure flag in your app, and job done, right?

Well. Normally, yes. But the added complexity comes from how our estate is currently configured – containers sat behind a load balancing gateway. This gateway, running haproxy, performs SSL offloading (yes, I know, NSA Smiley, but this is just temporary).

Solution

Once I figured out what was going on, the fix is quite simple. Namely, rewrite any cookies coming from the backend containers to include the secure flag.

This is fine, since none of our services are available over vanilla HTTP.

Adding the following:

rspirep ^(set-cookie:.*) \1;\ Secure

Did the trick after a restart.

Of course, previous tips still apply, you’re going to want to clear your caches etc so that the old cookie isn’t preserved, etc.

Hope this helps!