Category Archive: Work

#Moodle installation on #ISPConfig 3

(Maybe I should have read the ISPConfig manual, but reading manuals is something I almost never do)

W00t! What a drama 🙂

I’ve been on this puzzle for hours, maybe like you too, since you probably found this posting while searching for your own problems with open_basedir restrictions on “moodledata”.
To keep things short, here is the solution:

Change the path for moodledata from /var/www/clients/clientx/webx/moodledata to /var/www/clients/clientx/webx/private/moodledata (only insert /private, don’t change anything else)

Have fun!

A great example of a “slow” brute force attack #ossec

The last couple of days a lot of malicious servers got caught by my Ossec HIDS/IPS and have been send to my iptables jail. However, I’ve been seeing one host ( evading my traps for days. It has been nocking on my door in a slow pace, slow enough not to trigger a brute force detection (causing six events in a small period of time).

So I changed the brute force detection window to 86400 seconds, to see if that helps.

The result:


He got caught and went to jail 🙂

iptables -L


HOWTO: Install OSSEC / WAZUH hids #security #ossec #wazuh

The last few nights I have been working on this project. At first it seemed easy, but a lot of information on the internet is either too old, not well maintained, incomplete, or whatever. Needless to say that these kind of projects are complex, and the IT environment changes fast, so I cannot point any fingers at anyone, and I won’t. By the time YOU find this blog because you run into the same issues, this posting might be outdated as well 🙂

After succesfully testing this at home I implemented it at work in under an hour 🙂


For this project I started at and as usual I ended looking all over the internet. But I took notes, maybe it’ll help you out. Have fun.
(I prepared this posting yesterday and scheduled it for automatic posting at 15:30, dunno if that works)

Installation manual single-host Wazuh HIDS on Debian Jessie 8 (16Gb ram, 40Gb hdd), including ELK Stack (Kibana interface on secured proxy)
Please realize, these are my notes, I didn’t clean it up.

base debian jessie server install with standard system utilities
[already installed]

After install
logon as root
apt-get update
sudo apt-get install openssh-server openssh-client mc curl sudo gcc make git libssl-dev apt-transport-https
adduser wazuh sudo

[insert] wazuh ALL=(ALL:ALL) ALL [after line with %sudo]
su wazuh

cd ~
mkdir ossec_tmp
cd ossec_tmp
git clone -b stable
cd ossec-wazuh
sudo ./

sudo /var/ossec/bin/ossec-control start

[Skip the agent part for now.]

sudo nano /etc/apt/sources.list.d/java-8-debian.list
deb trusty main
deb-src trusty main

sudo apt-key adv –keyserver –recv-keys EEA14886
sudo apt-get update
sudo apt-get install oracle-java8-installer
wget -qO – | sudo apt-key add –
echo “deb stable main” | sudo tee -a /etc/apt/sources.list
sudo apt-get update && sudo apt-get install logstash

[skip the forwarder, I don’t need it since the whole HIDS runs on a single server]

sudo cp ~/ossec_tmp/ossec-wazuh/extensions/logstash/01-ossec-singlehost.conf /etc/logstash/conf.d/
sudo cp ~/ossec_tmp/ossec-wazuh/extensions/elasticsearch/elastic-ossec-template.json /etc/logstash/

sudo curl -O “”
sudo gzip -d GeoLiteCity.dat.gz && sudo mv GeoLiteCity.dat /etc/logstash/
sudo usermod -a -G ossec logstash

wget -qO – | sudo apt-key add –
echo “deb stable main” | sudo tee -a /etc/apt/sources.list.d/elasticsearch-2.x.list
sudo apt-get update && sudo apt-get install elasticsearch
sudo update-rc.d elasticsearch defaults 95 10

sudo nano /etc/elasticsearch/elasticsearch.yml
[find the following variables, uncomment them, and rename them as you wish] ossec ossec_node1
uncomment bootstrap.mlockall: true

sudo nano /etc/security/limits.conf
[insert at the end]
elasticsearch – nofile 65535
elasticsearch – memlock unlimited

sudo nano /etc/default/elasticsearch
[edit and uncomment]
# ES_HEAP_SIZE – Set it to half your system RAM memory

sudo nano /usr/lib/systemd/system/elasticsearch.service

sudo service elasticsearch start
sudo systemctl enable elasticsearch

cd ~/ossec_tmp/ossec-wazuh/extensions/elasticsearch/ && curl -XPUT “http://localhost:9200/_template/ossec/” -d “@elastic-ossec-template.json”
sudo update-rc.d logstash defaults 95 10
sudo service logstash start

wget -qO – | sudo apt-key add –
echo “deb stable main” | sudo tee -a /etc/apt/sources.list
sudo apt-get update && sudo apt-get install kibana

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable kibana.service

sudo service kibana start

In your browser


[wait for the yellow light, it will turn green, if not refresh after 2 minutes]
goto http://IP_OF_HOST_OR_HOSTNAME:5601
– Check “Index contains time-based events”.
– Insert Index name or pattern: ossec-*
– On “Time-field name” list select @timestamp option.
– Click on “Create” button.
– You should see the fields list with about ~72 fields.
– Go to “Discover” tap on top bar buttons.

– Click at top bar on “Settings”.
– Click on “Objects”.
– Then click the button “Import”
– Select the file ~/ossec_tmp/ossec-wazuh/extensions/kibana/kibana-ossecwazuh-dashboards.json
– Optional: You can download the Dashboards JSON File directly from the repository `here`_.
[Refresh the Kibana page and you should be able to load your imported Dashboards.]

mkdir -p /var/ossec/update/ruleset && cd /var/ossec/update/ruleset
chmod +x /var/ossec/update/ruleset/
/var/ossec/update/ruleset/ –help

Update ruleset
./var/ossec/update/ruleset/ -a
This can be cronned in the future.

crontab -e (as root)
@weekly root cd /var/ossec/update/ruleset && ./ -s


sudo apt-get update
sudo apt-get install nginx apache2-utils

sudo rm /etc/nginx/sites-available/default
sudo nano /etc/nginx/sites-available/default
server {
listen 80 default_server; #Listen on IPv4
listen [::]:80; #Listen on IPv6
return 301 https://$host$request_uri;

server {
listen *:443;
listen [::]:443;
ssl on;
ssl_certificate /etc/pki/tls/certs/kibana-access.crt;
ssl_certificate_key /etc/pki/tls/private/kibana-access.key;
server_name “Server Name”;
access_log /var/log/nginx/kibana.access.log;
error_log /var/log/nginx/kibana.error.log;

location / {
auth_basic “Restricted”;
auth_basic_user_file /etc/nginx/conf.d/kibana.htpasswd;

cd ~
[document your passwords for the next part securely!!!]]
sudo openssl genrsa -des3 -out server.key 1024
sudo openssl req -new -key server.key -out server.csr

sudo cp server.key
sudo openssl rsa -in -out kibana-access.key
sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out kibana-access.crt
sudo mkdir -p /etc/pki/tls/certs
sudo cp kibana-access.crt /etc/pki/tls/certs/
sudo mkdir -p /etc/pki/tls/private/
sudo cp kibana-access.key /etc/pki/tls/private/

sudo htpasswd -c /etc/nginx/conf.d/kibana.htpasswd kibanaadmin [note] make up your own kibanaadmin username if you want to]

sudo nano /opt/kibana/config/kibana.yml
[edit and uncomment] “”

sudo service kibana start
sudo service nginx restart

browse: https://your_host_or_ip:443

After a reboot logstash has to be started manualy, I did not spent much time on the issue since I hardly ever need to reboot. I will update when I solve it, meanwhile any tips are very welcome in the comments …
Item added.
Drop me a note if you find an error, thank me not 🙂

@sucurisecurity killed my wordpress site (twice)

w00t w00t! mod_fcgid: stderr: PHP Fatal error: Cannot redeclare class SucuriScanSiteCheck

Yesterday Sucuri for WordPress was updated to 1.7.18, my website immediatly went offline. I got notified about it by Jetpack.
Problem: I cannot deactivate the Sucuri plugin via the WordPress dash since the site is down and I can’t login 🙂
Solution: Logon via FTP and rename the Sucuri plugin directory to .old. My site went back up immediatly.

I tried to revert to my latest backup, which worked, and Sucuri got automaticly updated to version 1.7.19. My website went down again .. and I could start all over again, disabling the plugin over FTP

For now I leave the plugin as is. Hopefully Sucuri comes with a solution soon. I’ll wait ..

Update: after posting this to Twitter Sucuri immediately contacted me and offered to provide a solution. As we speak we are working together to get this solved. Thumbs up for a company like that.

Update2: it’s working again, but the source of the troubles is yet to be determined.

EDIT: Prune backups made with Relax and Recover #rear #linux

People keep asking me how I make incremental backups with rear, so I edited my posting about pruning backups with rear and inserted my config.

Prune backups …

If you don’t want to look that up you find my /etc/rear/local.conf below.

BACKUP_PROG_EXCLUDE=( ‘/tmp/*’ ‘/dev/shm/*’ ‘/mnt/*’ ‘/media/*’ $VAR_DIR/output/\* )

I also rsync my backups to an external (Raspberry Pi 1B) server, will post about that later on.

Have fun backing up!

Monitoring cafeïne levels with @zabbix

Can somebody bring me some coffee? Please?



Driving to work, at 5472 km/h …

Have fun watching ….

HOWTO: Prune backups made with Relax and Recover #rear #linux

I am backing up my Linux machines bare-metal with ReaR, in the form of weekly full backups and incrementals. ReaR does a great job but doesn’t cleanup old backups by itself, so if you do nothing you’re filing up your backup server sooner or later.

As I am lazy Linux sysadmin I don’t want to cleanup leftovers manualy, so I automated it 🙂 Here is how:

First: my /etc/rear/local.conf

BACKUP_PROG_EXCLUDE=( ‘/tmp/*’ ‘/dev/shm/*’ ‘/mnt/*’ ‘/media/*’ $VAR_DIR/output/\* )

This will create a full backup every friday, and incrementals on all other days.

In the picture below you see what happens if you let things run it’s course:


I have got 11 backup archives of which I only need 4 (today) to recover when needed. The archives with an “F” in their name are full backups, the other ones (with “I”) are incrementals. There are also two important files here, basebackup.txt and timestamp.txt. Those two files actually do sort of the same: tell the system when the last full backup was made. ReaR needs this for restoring the system, using the correct files. I only need timestamp.txt for my cleanup job, but I could also use basebackup.txt for them. What’s in those files is not important to me, I use the time and date they where created or modified. Today is march 17, so every archive created before the last full backup (march 13 in this case) may be deleted.

To find out what files can be deleted you can issue the following command in the terminal:

find /media/nfs/lamp02/*tar.gz -type f ! -newer /media/nfs/lamp02/timestamp.txt

(make sure to adjust the path to your own situation!)



To delete them issue the following command:

find /media/nfs/lamp02/*tar.gz -type f ! -newer /media/nfs/lamp02/timestamp.txt | xargs rm -f

(Again, adjust your paths!)

All files created before the last full backup will be gone, keeping your backup server clean 🙂
The only thing you have to do now is create a proper cronjob to automate this. Be sure the command runs AFTER the backups are complete!

For the best results you can do this daily. If you feel you want to keep your files longer, maybe a month, you can tweak around to accomplish that. Maybe I will update this posting with my own solution for that, although in my case I do not need it.

Happy Linux’ing!

(Edit: this posting is now in the official rear user documentation, which is kinda cool)
(Edit 2: people keep asking me how to make incremental backups with ReaR, so I inserted my /etc/rear/local.conf above)

Spam analysis in the works

This is a small workrelated project you may ignore. So please move on 🙂 unfiltered account filtered account

Sorry for the downtime.

More Galleries

Sometimes, life sucks 🙂