Exchange 2010 management console after removing a DC

Recently we removed the Domain Controller in an Exchange 2010 setup.
All the accounts that had launched the management console at some points in the past were stuck with an error about not finding the deleted DC.
The fix was easy: there is a cache file that needs to be deleted in:

HSTS with Traefik and Docker

I’ve recently started to move the stuff I host to Docker, using the Traefik reverse proxy as the SSL termination.

Traefik is a really nice piece of software, but unfortunately while the documentation is great, it’s somewhat missing in tutorials and examples.

Among other things, I host a Nextcloud instance, and among the security suggestions, it tells me to add a Strict-Transport-Security header with a value of at least 15552000.

In my case, it was not strictly necessary as is already using HSTS preloading, but I wanted to follow the security suggestions to the letter.

To add the header to any host reverse proxied service, you simply have to add a label such as this:


Proximus DNS management or the absolute lack of security

All of our clients have their own hostnames.
Usually, when they request a new domain name, we ask them to use an OVH account, buy the domain name with it, and assign us technical management rights to our own account. That way, we have the ability to manage it but the client retains the ownership of the domain name.

However, in some cases our clients have used Proximus (formerly Belgacom, Belgium main internet provider) as a registrar and the DNS is managed by Proximus.

When we want to make a change to the DNS configuration of one of the domain name hosted by Proximus, this is the procedure that has to be followed:

That’s all.
Usually less than an hour after the request, you receive an email stating that the change request has been realized.


What this means, is that ANYONE can send an email to Proximus asking for pretty much any change to be done to any of the DNS they host, and Proximus will do it, no questions asked, no authentication required.
There is not even an email sent to the registered owner of the domain to confirm that a change has been made.

That means it would be trivial to MITM all email traffic from a rival company whose DNS is hosted by Proximus (how often do you think small companies check their MX record for change?)

It would also be trivial to hijack ownership of the domain name: you redirect all emails of the domain to a mail server you own, request a transfer, validate the transfer request since you have access to the owner’s email, and in very little time you could be the owner of the domain.

There is a shocking absence of even the most elementary security in Proximus handling of DNS changes.

Rudder and in-file text replacement

At work, we use Rudder to take care of configuration automation.

Today, I was trying to update a small script that we use on all our SMTP gateways, which does an LDAP request.
That LDAP request needed to be updated and instead of connecting to 40+ servers, I made a new Directive in Rudder. Using a regexp, I was trying to replace:




With the help of, I used this regexp at first:


But for some reason it wasn’t working, and I would get:
Error: Because the regular expression '\(objectCategory=group\)' still matches the replacement string

The explanation, of course, is that the regexp I used would still match the replacement line, which means that every time rudder ran, it would be applied.

Thank you rudder for saving my script 🙂

Proftpd on CIFS share

For several of our clients, we provide an FTP server on a linux server, with the files hosted on a windows 2008r2 server and authentication being handled by active directory through proftpd-ldpap.

The windows share are automatically mounted on access with autofs in a /srv/ftp subfolder, and users are jailed in yet another level of subdirectory using proftpd.

I hit a bit of a wall recently with this setup, as everything seemed to be in order, autofs mounted the directory, proftpd allowed login with ldap auth, but for some reason I couldn’t write anything.

If I pointed proftpd at a local directory however, write was fine.


I finally found out that proftpd was trying to use “chmod” on every write, and with SMB < 3, it failed, resulting in a “permission denied” error and nothing whatsoever in the logs.


I fixed it by mounting the CIFS share with the “noperm” option:

homes -fstype=cifs,rw,credentials=/etc/cifscredentials,gid=nogroup,uid=proftpd,vers=2.1,noperm ://SERVER/SHARE\$/SFTP

Fortigate backup script using SCP

At work, we have a whole bunch of fortigate firewalls, and we like to backup them.

I found several scripts to do that, but none of them worked in the way I wanted them to, so I made mine.

It backs up a list of fortinet, using a read only admin of the firewall that is only allowed to log in from the backup server IP, stores it in a date based directory, and zips yesterday’s folder so as to save space.
Afterwards, it sends an email containing the logs to a specified email address.

Here it is: Continue reading “Fortigate backup script using SCP”