How to configure PiHole in QubesOS (ProxyVM)

Pi Hole is a framework that aims to block advertisements on your network using a sinkhole approach on known advertisements domains.

PiHole is based on Raspberry PI, a device that almost all computer enthusiasts have in their home, it is built on top of DNSMasq weaponized with community-maintained blacklist and can be backed with your favorite DNS servers.

But PiHole is not just and adblocker: it provides also a DHCP server and a dashboard for configuration, monitoring and tracking visited urls, allowing the PI owner to detect suspicious behaviors in the network.
Is very convenient to use it, because you have a central point in the network in which ads are conveyed avoiding the usage of addons that act browser-level, and preventing anti ad-blockers mechanisms.
Furthermore, it's open-source and available on GitHub
If you like to play with dedicated hardware, you can adopt a standard approach buying a cheap Raspberry Zero, installing PiHole on it, configuring it to be recognized as an USB ethernet adapter and play with NAT on your machine to give connectivity to him.

The annoying thing comes when you use to use a laptop: you don't have your Raspberry PI in your pocket and, if you

Google Apps Script to automatically tag emails with date-based labels

I use to automatically tag my e-mails with time based labels, on Gmail.
Can I simply use filters?
Maybe yes, but I didn't get to make them work when specifying only dates as criterias.
Maybe I'm idiot, but Gmail simply doesn't allow me to specify such filters.
So I tricked him with a small Google Apps Script, that tags emails with a current year and a current month nested labels.
Please note that it just works for 2017 and month names are in Italian.
I scheduled it to run once a minute.

function labelAllMessages() {

  var label2017 = GmailApp.getUserLabelByName("2017");

  var months = ["gennaio", "febbraio", "marzo", "aprile", "maggio", "giugno", "luglio", "agosto", "settembre", "ottobre", "novembre", "dicembre"];

  var getNumberOfDaysByMonth = function(i) {
    return (i==1) ? 28 : (  !(i>=7 ^ !(i&1)) ? 30:31  );

  var getDateRangeForMonth = function(ind) {
    var month = months[ind];
    var range = {
      start: new Date(2017, ind, 1).valueOf(),
      end: new Date(2017, ind, getNumberOfDaysByMonth(ind)).valueOf(),
      label: GmailApp.getUserLabelByName("2017/" + month)
    return range;

  var threads ='-label:2017 -label:"before 2017"')
  if (threads.length <= 0) {
    Logger.log("No untagged message")
  for (var i=0; i<threads.length; i++) {
    var message_date = threads[i].getLastMessageDate().valueOf();
    for (var

Kernel Linux, patch veloce ma adozione ritardataria

Via - Link all'articolo

Le maggiori distro GNU/Linux hanno da poco introdotto una patch rilasciata più di un anno fa per un pericoloso bug che consentirebbe l'esecuzione di codice arbitrario via UDP. Ma il rischio per i dispositivi Android ed embedded resta alto

Roma - Già nota dagli ultimi mesi del 2015, cui è seguita una patch silente ma immediata, la vulnerabilità CVE-2016-10229 di tipo arbitrary code execution, che riguarda le versioni del kernel Linux comprese tra la 2.6 e la 4.5, è stata catalogata nel Common Vulnerability Scoring System v3 con un punteggio pari a 9.8, ma la patch è stata inclusa solo di recente nelle maggiori distribuzioni GNU/Linux.

Il problema deriva dalla gestione del flag MSG_PEEK nella funzione recvmsg relativa al protocollo UDP, il cui ruolo è quello di permettere il prefetch di un messaggio in arrivo su un socket UDP senza consumare il buffer di lettura.
In particolare, quando l'utente fornisce una quantità di dati inferiore alla dimensione del socket buffer (SKB), il checksum del pacchetto UDP viene calcolato due volte; la seconda volta utilizzando una funzione insicura (skb_copy_and_csum_datagram_iovec) che potrebbe causare l'esecuzione di

Dealing with VLANs with IMUNES and OpenVSwitch


it has been a long time since my last post.
I'm writing this to make a brief recap on how to deal with VLANs in IMUNES on Linux, using the Open-vSwitch CLI tools.

The purpose is to give a reference point to students who are approaching the final project for the Computer Networking classroom @ Unimi.
As I've discussed during the class (see Lesson 3, Bridges and Switches), IMUNES doesn't come with built-in support for VLAN tags at switch level.
You can set up VLAN tags only on interfaces declared with iproute2, I think for a compatibility reason between the BSD version and the Linux version of the product.

However we should keep in mind that IMUNES makes use of Open vSwitch to manage bridges on Linux. That is to say that one can use Open vSwitch CLI tools to accomplish advanced tasks, such as assigning VLAN tags directly on the switch ports through Open vSwitch.

Another important thing we have to consider before proceeding, is the mapping between IMUNES UI and real bridges names.

What happens when the user runs the experiment?

IMUNES spawns a Docker container for each host or L3 device (router) declared in the topology.

Networking Laboratory - Lessons archive

Hi :)
These are the slides I've made with prof. Claudio Ardagna for the Networking laboratory class, which I've been supporting during this academic year at University of Milan.
The main tool we've used during the lab has been IMUNES, an open-source network topology simulator built on top of Docker and Open vSwitch.

Using this software we've been able to explore characteristics and implement functionalities of the whole network stack.

Slides are in italian language and cover only a part of the whole course.
They are open and free to use, but please if you use them as provided, keep the credits :)
If you need the PPTs, contact me via mail.

Enjoy them!


  1. Software defined networks and IMUNES
  2. Introduction to IMUNES
  3. Level 2 - Bridging and Switching
  4. Introduction to Level 3 - ARP Protocol
  5. Level 3 - IP Protocol
  6. Level 3 / Level 7 - DHCP
  7. Exporting a network topology with IMUNES
  8. Level 3 - Static routing
  9. Level 3 - Cisco syntax, dynamic routing and OSPF
  10. Level 3 - Firewalls and NAT
  11. Level 7 - Domain name system


If you find any error or inaccuracy in the content please report it to me, so that I can fix it.

IMUNES: how to export changes made to an experiment - Part 2


Today I've written again from scratch the two BASH scripts to export changes made in IMUNES, this time using Python.
I've built a UI with GTK3 using Glade, and I've organized the code in a more clean and safe way.
Docker management is done via the official library docker-py.


The software is available on GitHub:


  • Clone the repository and browse it
git clone  
cd ImunesExperimentExporter  
  • Install dependencies through Pip
pip install -r requirements.txt  
  • Install the software by calling
sudo python2 install  
  • Enjoy the software calling it with the command

You need to have Docker configured for listening on UNIX socket (at the path /var/run/docker.sock). Please note that in a normal environment this socket file is owned by root and docker group, so it could be needed to run imunes-export with root or docker group privileges.

Export a topology

You can choose to export a single container or the whole experiment.
The execution flow is the same as the last time.

  1. Draw a topology
  2. Run the experiment
  3. Make changes you want to make (e.g. configurations, your files, etc.)
  4. Use my software

IMUNES: how to export changes made to an experiment

These are two snippets I've written in BASH in the last few days to allow IMUNES users to export changes made to an experiment in runtime, on Linux.
The former allows users to export changes, the latter allows them to load changes back to Docker containers.
They will be improved day by day, so it's recommended to consult this page to get an updated version of them, especially if you encounter problems.

The execution flow to use these scripts properly is:

  1. Draw a topology
  2. Run the experiment
  3. Make changes you want to make (e.g. configurations, your files, etc.)
  4. Use the first script to export those changes to your computer's file system
  5. Stop the experiment
  6. Save the topology
  7. Close IMUNES

  1. Open IMUNES again
  2. Load the topology back
  3. Execute the experiment
  4. Use the second script to load your previously exported changes back
  5. Enjoy!


  • Your Linux distribution needs to have the zenity package installed
  • Both scripts need to be executed with root privileges or by a user that is assigned to the docker group. Remember that if you run them with root privileges, the files created by them will be owned by root, so you could encounter permission problems.
  • You can