RMLL 2014 Security Track Wrap-Up

RMLL 2014I’m just back from Montpellier where was organised the 2014’s edition of the RMLL (“Rencontres Modiales des Logiciels Libres”) or LSM in English (“Libre Software Meeting”). This is a huge event similar to the FOSDEM in Brussels where people who love free software exchange views, researches and make some networking. The event location changes every year and this edition was organised in the south of France… not a bad place! The event is huge and is organized across a whole week, attracting a few hundreds of people. Within the main event, other small events are organised and talks are divided in multiple topics like:

  • Society
  • Enterprises
  • Culture
  • Development
  • Sysadmin
  • Health
  • Education
  • Internet
  • Do-It-Yourself
And, of course, security! I attended the security talks presented on Monday and Tuesday. Here is my quick wrap-up.

I started the Monday with an exception: My first choice was not in the security track but looked very interesting to me: Christophe Hamerling performed some drone hacking. The presentation title was “Hackin the (AR-)Drone” and focussed on the well-known Parrot device. In fact, the drone was a good opportunity for Christophe to learn how to use the Node.js platform. After a small introduction, he explained that the protocol used by the drone to communicate with the remote controller was reverse-engineered and a framework was created based on Node.js to take control of it. The rest of the presentation was based on demos how to take control of the drone and get interesting data from his sensors:

  • To take off and land
  • To take a picture or record a movie with the builtin camera
  • To interact with Twitter (and send commands to a Twitter bot)


Another interesting project is called ardrone_autonomy. It allows you to script actions which will be performed by the drone. It can be compared to a Logo game from the 80’s. The materiel presented by Christophe is available here. It was a entertaining presentation to start the day but nothing related to really “hacking” the drone. It was more programming but the effect is present when you click on “Take off” in a web interface and the drones executes.
Then I moved for the rest of the day to the security track which was mainly dedicated to Netfilter and IDS/IPS during the first afternoon. Pablo Neira presented the successor of Iptables: Netfilter from a user perspective. What will change with Netfilter? Compared to Iptables, it has a nice API, do not have code duplication like Iptables, is expendable outside kernel space and allows more flexible configurations. Today, ~35% of the Iptables features have already been implemented in Netfilter. It is included in the Linux kernel since version 3.13 (October 2013) and remains under active development. It offers also a nice CLI interface and gets rid of the “—“ parameters. Multiple chains can contain tables without specific semantic and chains are fully configuration.
nftables Command Line
Netfilter has multiple selectors:
  • payload
  • ct
  • meta
  • log
  • not
Pablo gave many useful information about Netfiler which might soon replace our good old Iptables with all the fancy new features! The project is still under heavy development and Pablo asked to download the code, test it and report bugs. More information is available here.

To continue with Netfilter, Arduro Borrero presented his project called “nft-sync”. The idea is to have a good tool to properly (and safely) distributed Netfilter configuration across multiple firewalls (ex: a cluster of x nodes) or to manage multiple policies for multiple firewalls. The tool has already a public API for remote management. Its main features are:

  • A basic configuration file
  • Two running modes: command line or daemon
  • Different operations already implemented: Fetch, Pull, Sync
  • Data are exchanged in JSON/XML

nft-sync is still a proof-of-concept supported by Google as a GSoC project. More information is available here.

Eric Leblond made two presentations. The first one was an overview of the integration of Netfilter with an IPS. To follow on the same subject, Eric demonstrated how easy it is to configure Netfilter to talk with an IDS like Suricata.

Eric on Stage

The old way (with Iptables) was to use NFQUEUE and configure “nfq” in Suricata (forget Snort which does not implement this feature). On the other side, Netfilter can do this easily by defining a new chain dedicated to filtering. It’s easy as creating two chains with different priorities. After a short coffee break, Eric came back with his second presentation about a very important topic when you create and manage firewall policies: logging! Iptables had already some feature to log via Syslog but it’s not very sexy and remains difficult to parse. The next generation of solution to log Iptables events was via ulog & ulogd. The daemon has many ways to output events. The most common being into a SQL database and to a PCAP file. With ulogd2, new features were introduced like an improved DB support. ulogd2 can also log volumes of data (interesting if you need to perform some accounting) and can log NAT transformations. Eric also demonstrated how to sent Netfilter events into Kibana to produce nice dashboards.

Next talk was presented by Victor Julien, the lead developer of the Suricata project. Again, Netfilter was addressed and Victor reviewed how to integrate Netfilter with Suricata. This IDS has so many features that it’s impossible to list them. The complete list in available here.

Victor on Stage

Balazs Scheidler presented an open source software called Zorp. It’s an proxy firewall which is able to filter up to the application layer. Keep in mind that today:  “HTTP is new TCP”. We have to deploy tools to inspect the HTTP traffic and not only on port 80! An interesting feature, New Zorp features can be added using Python. Balazs gave as example an module to inspect the Facebook chat sessions.

Balazs on Stage

And, to close the first day, Victor Julien came back to present his Iptables based firewall manager called “Vuurmuur”. For the story, “Vuur” means “Fire” in Dutch and “Muur” means “Wall”. This project was started a long time ago when Victor decided to learn programming. The second goal was to provide to his colleagues who did not have a strong Iptables background, a nice tool (nurses based) to manage the firewalls by themselves. The tools is not upgraded often (the last release is from 2009) but Victor has still some ideas to add features. This closes the first day.

The second day started with Stéphane Bortzmeyer (from the AFNIC) who spoke about DNSSEC. He started with a small review of the DNS. It provides:

  • Stability (ex: when servers move between ISP’s but remain accessible)
  • Memorability (sexy domain names for marketing 😉
  • Security : really? No very true but DNSSEC improves it!
  • It’s a generic DB and does not only return IP addresses
  • It’s a critical system on the Internet

Stéphane on Stage

DNS suffers of many threats. Two first cannot be mitigated by DNSSEC:

  • Unauthorised change in a zone file (GIGO) – Very difficult to mitigate – use classic controls
  • DDoS

But the following are addressed by DNSSEC:

  • Traffic corruption
  • Cache poisoning
  • Unauthotized updates
  • Spoofing master (zone transfer corruption)

First (but old) improvement, TSIG (“Transaction SIGnature”) protects you against malicious zone transfers. It’s already commonly used. TSIG a shared secret, so it’s difficult to deploy massively. It cannot protect the “last mile” (distributing the shared secret to all clients is unmanageable). The DNSSEC basics are:

  • Each zone has a key (with a public and private part)
  • Resource records are signed
  • Authoritative name servers serve the signed data
  • Validating resolvers check the signature with the public part

Tip: DNSviz.net is useful to see the chain of trust. Example: http://dnsviz.net/d/dns.be/dnssec/. Of course, free software support DNSSEC:

  • OpenDNSSEC is a tool to manage keys
  • NSD, Knot, PowerDNS & BIND are name servers which serve signed zones. Note that powerDNS & Bind can do serving + automatic signatures
  • ZoneCheck to check zones

Based on Stéphane’s experience with DNSSEC, the main problem is not the “technical” deployment of DNSSEC. It can be achieved in a few minutes – there are tutorials everywhere on the Internet – but the procedures that must be implemented around DNSSEC. Example: Don’t forget your signature expiration. It is mandatory to have a good planning:

  • First of all, do you need it (do you have sensitive data to protect?)
  • Take care of stupid firewalls which limits DNSSEC (512 bytes packets)
  • Use NTP (time sync is a key)
  • Monitor! (check NTP, signature expiration, key protection!)
A good overview of DNSSEC by Stéphane!

The next talk was about the Haka language by Mehdi Talbi. Haka is an open source security oriented language. The context where Haka can be interesting: Today we need to develop network parsers to analyse new attacks and interact with network flows (log them, generate alerts or modify them on the fly).The idea behind Haka is also to allow people to write such filters without writing C code. Haka has the following security rules:

  • Check packet fields and data content
  • Match malicious patterns across multiple packets

The Haka Architecture

Haka works with LUA scripts. Here is an example of rule which replace images by lolcats in an HTTP stream:

  local image_ext = { '.png', '.jpg', '.gif' }
      hooks = { 'http-request' },
      eval = function (self, http)
          local request = http.request
          local path = request:split_uri()['path'] or ''
          for _,ext in pairs(image_ext) do
              if string.match(path, ext .. '$') then
                  -- Ready to lolcat the web? :)
                  -- Redirect request to server hosting a lolcat image
                  request.uri = "http://myserver/lolcat.jpg"

Another nice demo was injecting Javascript in HTML code. Nice demo: injectponies.lua http://panzi.github.io/Browser-Ponies/. This is a very interesting tool to play with if you already have a server capturing your network traffic (or on a proxy).

After a short coffee break, Eric Leblond came back on stage with a third topic: How to use IDS/IPS to effectively perform attack detection. Interesting features, file extraction, TLS handshake analysis (to prevent bad stories like Diginotar). Lot of logging: HTTP request, TLS certificate log, DNS logging and Lua scripting allow to write rules in a easier way. Suricata rules can become very complex. Suricata 2.0 has new features:

  • EVE logging (JSON output for events)
  • Improved VLAN handling
  • NSM runmode (detectionless)
  • Improved CUDA performance

Eric analysing passwords

The new feature that was reviewed by Eric is how to improve logging and reporting. By combining the new EVE logging feature with ELK (Elasticsearch, Logstash and Kibana), it is possible to build very sexy dashboards (as Eric said: “Defensive security can also be sexy!”). Eric demonstrated how easy it is to get interesting stats. His example was based OS detection. In the RFC’s, the start value of a TCP window is not specified. It means that each operating systems is free to use any value. By example, Windows 7 SP1 uses a TCP window of 8192 bytes. This information can be used to authenticate the different OS which are sending traffic to your network. Using Kibana, it’s easy to play the TCP windows and he detected some unusual accesses like Chines in his demo. This highlighted connection from China to the port 22 but always from the same port (6000). The scanner used was based on raw sockets and connections were not initiated by the OS itself. The next step was to write a honeypot in SSH to log all probes. Eric called this the “French hospitality”. Excellent example to demonstrate how to get most of your IDS and logs!

Christian Perez and Solange Gentil reviewed their practical experience with Snort in a real environment at the CEA Cadarache. I found this presentation very interesting because it described a real implementation of a free solution with real (read: business) constraints. Usually, talks presented during security conferences are based on proof-of-concepts, studies. In this case, it was based on real facts.

Solange on stage

The goal of the Snort deployment was multiple:

  • Detection
  • Analysis
  • Incident management

Once the architecture in place, they faced some recurrent threats:

  • Compromized hosts
  • Security policy violations
  • Inside threats

To improve the detection of suspicious traffic, Solange explained that Snort is feed with the following rule sets:

They also added IP reputation and geo-localisation. For internal IP addresses reconnaissance, they used the existing CMDB. This proves that your logs must be correlated with external sources to increase the detection accuracy! Solange and Christian’s talk demonstrated that, properly deployed, a Snort (read: an IDS) instance can be very useful. However:
  • Encryption makes many rules obsolete
  • They are many ways to bypass IDS
  • Automation and transfer are still a great challenge (help desk & mitigation)

A very nice practical return of experience!

After a sunny lunch break outside, Ninon Eyrolles talked about the obfuscation of code or “know your enemy!”. Usually obfuscation is used to “hide” some code. This aspect is at the opposite of the message broadcasted by the RMLL – the code must be free and open. But she demonstrated that understanding how obfuscation is used and how to detect it can be very helpful.

Ninon on stage

In fact, obfuscation is found at many levels: In malwares, in DRM implementation (protection of sensitive data) and is also doing cool stuff on encryption. To break something, you need to understand how it is made. Ninon gave more focus will be on two obfuscation techniques:

  • Control flow obfuscation
  • Data flow obfuscation

Ninon reviewed different techniques likes loop unrolling, inlining of functions, junk code insertion. And, for each technique, she explained the weaknesses and some detection techniques. This is not a key topic for me but the presentation was very clear and didactic!

The next slot was assigned to… myself. I made a presentation about malware analysis based on a free toolbox. It was not only the analyse of malicious code but also how to automate the scanning process and how to extract juicy information to correlate them with your other security solutions (IDS, firewalls, SIEM, etc). My slides are available here.

Lunar followed me with a presentation about Tor. But the presentation quickly switched to a Q&A session regarding Tor. The topic was very interesting and the room assigned to the security track crowded with many people sitting on the ground. A good proof that Tor remains a very hot topic. Some numbers about Tor:

  • 6000 relays worldwide
  • 3000-4000 people worldwide
There was very interesting questions and the conversations were really good. Some important information if you’re a Tor user (or plan to start your own exit node):
  • Don’t run a node personally (run it under an association)
  • Don’t run a node at your home, run it in a datacenter / on a VPS
  • Don’t use a browser other than TorBrowser. Regular browser have weaknesses which will disclosed sensitive information about you.

Lunar speaking about Tor

A classic issue when nodes and exit-nodes are deployed: they are hosted in big autonomous systems (as seen on the Tor Diversity map). This increases the chances to use multiple hops in the same network. If the starting and exit points are controlled by the same network, this is risky. Conclusions: new nodes must be deployed on new networks!

The last talk of the day was the one of Daniel Faucon who spoke about the instant messaging clients and their lack of privacy. Often, instant messaging users say “Why encrypt? Why privacy? I’ve nothing to hide!”. This is of course a complete fail! As said Daniel, for most of us, our primary threat is not the NSA but our ex-boy|girlfiriend, our employer, parents or neighbours! Another example, in some countries, the disclosure of a sexual orientation can be vey dangerous. Why is chat an interesting target? Because it is a main communication media between people and that generates a lot of qualitative information about you. And “qualitative” information means at a certain point “quantitative” information…

Daniel speaking about security IM

Daniel reviewed the history of cryptography to come to the conclusion that current tools are excellent from a security point of view but they suxx for average users. Think about PGP: it’s not easy to understand how it works for non-IT people. Daniel explained the basics of OTR (“Off-the Record Messaging”) and how it can improve our privacy. OTR advantages are:

  • It is fast and easy to use
  • Encryption is thrown away forever (or asap)
  • Light authentication of messages during the conversation
  • Signatures mean nothing after the conversation is closed
Based on this, OTR leads to “Plausible deniability” which can be helpful in case of a court trial but not always! Finally, Daniel reviewed some clients which are OTR compatible (or have an existing plug-in):
  • Instant messaging clients: Pidgin, Jitsi
  • IRC clients: irsii-otr, weechat-otr , chatsecure (IOS or Android)

But the main restriction of OTR is that it protect 1-2-1 conversations only. Multiparty-OTR is one of the solution. Crypto.cat software currently use the Multiparty Protocol for group conversations. If solutions exist, they’re not intensively used. Why? Like PGP, it remains complex. Skype & Facebook are so easy and one click away from you. Daniel’s conclusions are:

  • Usability must be considered as a important feature to help all users!
  • Never use a closed-source chat client
In the evening, a security track dinner was organized with all the speakers. Another good opportunity to meet people and have very interesting converstations.
Security track dinner

Unfortunately, I was not able to attend the third day. I flew back to Belgium this morning. You can watch the live stream and on-demand videos (soon) on video.rmll.info. Except a small glitch with the room reservations, the event was well organized, kudos to the security track team: @cbrocas, @doegox and @moutane.


  1. Hello Stéphane,
    Hmm… Sorry for this mistake (or misunderstanding). Are the slides online? It was on your conclusions slide. I’ll rectify asap.

  2. Very good summary, very useful.

    But I do not think I said “First of all, do you need it (do you have sensitive data to protect?)” Everyone desserves a secure name resolution, therefore DNSSEC.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.