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:
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 edzilla.info 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:
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:
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.
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 https://regex101.com, 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 🙂
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
We are in the process of moving our monitoring platform from a non working whatsup’gold to Zabbix.
Among other things, we wanted to monitor our domains at OVH (expiration date, essentially) and Eset Nod32 remote management server.
Here are the templates I designed, along with the necessary scripts:
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”