Idefix technology (English)

De Idefix
Sauter à la navigation Sauter à la recherche


The basic question : how to filter Internet connections ?

Until the years 2000-2010, most sites were using http and Internet filtering could be done quite easily with a transparent proxy. Squid was doing a very good job for this. But when web sites started to use ssl, on https connections, the situation changed dramatically. A transparent proxy is unable to filter encrypted packets, since the only available information is an IP address, the exact destination is unknown. To filter https connections it is necessary to use a non transparent proxy, which means modifying the parameters of all computers on the LAN, selecting the proxy not only for the browser, but also for the antivirus, Windows update, and so on. A huge difficult task for maintenance teams.

The question was then : how to filter the first connection, which is the DNS query. On *this* connection, the domain name is readable. After a first version using Squid, Idefix changed direction and the version 2 implemented a filter process not on 80 and 443 ports but on the DNS port (53). Unbound offered us a fantastic tool with the integrated feature of adding a Python script in the middle of the process. The whole filtering process, in Idefix, is handled by two Python programs, and, with a total of less than 500 lines of code, and 18kb for the two files.


Setup the network[modifier]

We need two Ethernet ports.
Eth0 : nothing to do, it should be in dhcp
Eth1 will be an authoritative dhcp server.

  • Disable Network Manager control on this port
    • Managed = false in networkmanager.conf
  • Eth1 definition in /etc/network/interfaces.d
  • Install isc-dhcp-server
    • Configure it in dhcpd.conf

Setup the router and firewall[modifier]

This is done in nftables header.

  • A classical configuration creates the router.
  • Policy drop on input, creates the firewall.
  • Routing the port 53 towards 53053 creates the first step of the filter, because all DNS queries will be routed to Unbound which is configured to listen on this port.

Setup the filter[modifier]

We use Unbound, a DNS resolver, which has the property of allowing the execution of a python script in the middle of the process. This script will make decisions based on the IP address of the sender and the domain required. If the domain is not allowed for this user, the request is dropped.

Unbound is installed with a classical configuration, and two important settings :

  • Port = 53053 : this will ask Unbound to listen to this port
  • In the end of the script, the definition of the python script ( and his place in the program work-flow : validator – python script – iterator.

The configuration is sent to Idefix by a configuration program in a json file which contains the config dictionary. This dictionary is then modified to be usable by the python script which Unbound runs on any DNS query. If the script returns False, a NXDOMAIN is returned to the browser. If the scripts returns True, Unbound forwards the query to the DNS server defined in Idefix. This can be a second DNS filter like OpenDNS, SafeDNS or others, which will provide a category based filtering.

The filter code is found on /usr/lib/idefix/

Setup Idefix[modifier]

Control of the onboard leds.[modifier]

This is done by modifying the values in /sys/class/leds/. This is done in the autoexec.bash script.

Additional services[modifier]


Htop is installed by default on Armbian. To create a html file from it, install aha and then :

   echo q | htop | aha --black --line-fix > htop.html

For those wondering: piping q to htop quits it immediately. The solution was found here :


After installing Munin, by default access is given only from localhost. To give access to all, we replace

   Require local


   Require all granted. 

See documentation here : (French)

Setup Supervix[modifier]

The companion : Confix[modifier]



Idefix has been originally designed for the single board computer Rock64 because it has a fast ethernet port and an additional port available with a daughter board. It can be purchased on the web site.

Later, development was continued on the Asus Tinker Board and the Raspberry Pi 4. The second ethernet port is provided by an USB3 USB-Ethernet adapter.


Rock64 can use eMMC cards or microSD cards. We do not recommend the cards sold on the pine64 store. There has been some problems with them. An additional difficulty is that if you have to change the card, you must disassemble the unit. Removing a card is easy, but inserting the new one between the mother board and the add-on card is *very* difficult.

If microSD is chosen, we strongly recommend high endurance cards. We have tested for months the Sandisk High endurance card (the white one), it proved to have an excellent wear leveling system. Two other cards tested died much earlier.

32 GB is more than sufficient since the system occupies less than 3GB.

If you choose to use an eMMC card, don’t forget to purchase the USB adapter sold by pine64, so that you can load the software on it.