Fork me on GitHub

Arena de Programação do FISL10 3

Interrompendo minha série sobre os mitos do FISL (não sei se dá para chamar de interromper algo que recém começou), mas seguindo a minha filosofia de blogar sobre algo que me perguntam frequentemente por email, resolvi falar sobre a Arena de Programação do FISL10. Retomo à série RSN.

Brevemente, a Arena de Programação começou há 3 anos com uma idéia simples: uma competição de programação no meio do FISL. A idéia, parcial e originalmente, foi dada pelo Presidente Lula. Exatamente… O pessoal havia, como de praxe, convidado o Presidente para o FISL (dessa vez a oitava edição). IMHO, um convite justo, já que a luta no front político desde a época do Sérgio Amadeu no ITI pelo fomento a utilização prioritária de Software Livre no governo havia sido adotada por ele pessoalmente. Esse convite já havia se repetido em anos anteriores e se repetiu nos seguintes até que ele finalmente veio esse ano... Mas isso é outra história, o que importa é que naquela ocasião o pessoal que levou o convite ouviu dele que seria interessante uma Olimpíada de Programação (outras Olimpíadas similares ele já havia fomentado, como a de Matemática).

Bem… uma Olimpíada é algo que estava fora de nossa alçada (e julgo que esteja ainda, embora me surpreenda cada vez mais com a capacidade do pessoal de fazer as coisas acontecerem – não duvidaria nada…), mas uma Arena em escala menor era possível, ainda mais que era o segundo ano em que estávamos na FIERGS, e espaço lá havia de sobra. Foi construida uma Arena bem no centro da área de convivência, e o resto vocês já sabem…

No FISL10, tínhamos proposto a realização da Arena edição 3. Já sabíamos, de antemão, que o DJB estaria presente, e tínhamos a idéia de propor como desafio tranformar em algo tangível a sua idéia de DNSCurve. Para isso, queríamos programadores que também entendessem de DNS e o básico de criptografia. O sub-comitê da Arena começou a maquinar uma forma de pré-selecionar essas pessoas e inventaram o seguinte desafio:

  • Uma frase criptografada com um método de tabela (na primeira Arena usamos ROT13) seria escondida em um eco server. Essa frase conteria o código de inscrição;
  • A tabela, ela própria, seria oculta em um registro TXT do DNS de arena.softwarelivre.org.
  • Dicas em um comentário HTML seriam postas públicas na página alusiva à Arena no site do FISL.

Então uma “caça ao tesouro” começou, e o sub-comitê ficou bastante excitado com os resultados iniciais. Duas pessoas quebraram o “código” e se inscreveram antes de mais publicidade ter sido dada à Arena. Em seguida um blog foi iniciado por um terceiro (que, pelo que entendi, nem chegou a participar da Arena), levando diversas pessoas a tentar quebrar o desafio…

Tínhamos 21 espaços na Arena, e 22 pessoas conseguiram quebrar o desafio a tempo. No entanto, apenas 11 compareceram no primeiro dia da Arena, tendo sido divididos em 3 grupos de 3 pessoas e 1 dupla. Com o “coaching” do próprio DJB, a Arena começou, dividida em duas partes não necessariamente separadas (implementar um servidor DNS suportando DNSCurve e um cache DNS idem). No segundo dia tivemos uma baixa e um dos trios acabou virando uma dupla.

A competição seguiu acirrada pelos 3 primeiros dias do FISL. No quarto dia os nossos heróis descansaram, aproveitando o restante do FISL enquando o DJB julgava seu trabalho. O grupo vencedor, que levou os Android G1 oferecidos pelo Google, era composto por:

  • Gustavo F. Padovan
  • João Paulo Rechi Vita
  • Rodrigo Exterckötter Tjäder

Eles receberam seu prêmio durante a apresentação dos vencedores, em uma sessão imediatamente anterior ao encerramento do FISL10, apresentada pelo próprio DJB, que preferiu não se posicionar quanto ao segundo lugar, uma vez que todos os trabalhos estavam muito bons. Os demais participantes da Arena foram:

  • Gabriel Quadros Silva
  • Roberto Miura Honji
  • Lauro Cesar de Oliveira
  • Éverton Ribeiro
  • Paulo Henrique Ahagon
  • Murilo Adriano (desistência)
  • Marcelo Saviski
  • Renan Teston Inácio

Parabéns a todos que participaram do desafio de inscrição, a todos que participaram da Arena, e aos vencedores! Nos vemos, novamente, no FISL11!

DNS mess and what I think about DNSSEC 5

I am following closely this new DNS mess. In fact, there’s nothing really new in that. DNS has been attacked lots of times over the years – as a result of not being designed with security in mind from the ground up -, just this new one is a combination of known attacks against known security flaws. The “quick fix” is not a real fix, and just incorporate old ideas into the most used DNS software, strengthening it to face the attack. The details leaked, and there’s already at least one public exploit (and who knows how many in the wild).

The new buzzword is DNSSEC.

I don’t like DNSSEC. I never did. The first time I heard of it, around year 2001, it was a centralization of a decentralized database: A proposed company (called Network Solutions) would serve as a central authority, signing every root DNS entry. It was a joke! Come on! DNS is suppose to be decentralized! Having a central company anywhere is just a huge step back in decentralization (not to mention a huge step back in security).

Time passed, and the DNSSEC specs evolved to a more decentralized way of thinking. The state it is now, and the implementations we saw so far are not good. No! I am not talking about security… I am talking about the KISS principle: DNSSEC turns something really simple to deploy into a full-time job, with frequent key roll-overs and re-signing everytime you change the zone – a huge mess! Yes, there are automated tools, but, come on! you still have to wait for TTL to expire before publishing this part or that part of the cryptographic machinery… And, if we are talking about real security, are we going to build some automated tool “fire-and-forget”-style and not follow it? If we are not looking at it as it goes, and it fails, we could end up with a completely wrong set-up or (even worse) a non-validating zone.

And I haven’t yet mentioned the increase in payload… I am not completely convinced that this alone would not lead to DoS attacks just by compromising the responsiveness of the servers (and DoS attacks are already available for quite some time – maybe the DNSSEC-medicine is worse than the disease…). The root (”.”) servers are not even DNSSEC-aware, and there’s a whole class of other stuff to work-around the fact that they may not be DNSSEC-aware for quite some time yet.

There has to be a simpler way!

I can imagine at least three ways to fix the problem until we can fix DNS in a KISS way… And they’re all KISS also:

  • Change Transaction ID field. This is the first Achiles heel of this crisis. Let’s increase the length of this field to 2048 bits, or even larger. Better yet, let’s make it variable, so every system administrator can set his servers’ own size. Yes, I know this leads to replacing ALL the DNS infrastructure, but isn’t that what we are doing right now, anyway?
  • Deactivate in-bailiwick injection. Over the years, DNS have been expanded to allow a lot of things other than translation of names into numbers (or to ease this translation). The second Achiles heel is the ability to inject the IP address for WWW.VICTIM.COM while consulting for 10294DKGJSDL.VICTIM.COM since both name-addresses are in the same bailiwick (in-bailiwick). Let’s take a step back, and deactivate all this… Before 1995, the same thing could happen with any addresses, including those “out of bailiwick”, and it was fixed to only allow those in-bailiwick… Let’s fix it again to not allow it at all!
  • Good, and old iptables. Couldn’t we just use iptables’ LIMITS to stop this attack and blacklist the attacker? We’ve been doing this for a lot of other things (SYN-floods, ICMP attacks, etc). Can’t we just do the same. Again: this is not a new thing… it relies on multiple attacks in a short period of time, just like other attacks we’ve seen and successfully blocked with these techniques…

Maybe some of those three solutions are flawed… Maybe none are flawed and can be deployed together… Maybe I am wrong and DNSSEC is the only way to go… But let’s not panic, let’s cool our minds and begin thinking it through. I still don’t think DNSSEC is the holy grail…

Now… I already spent more time than intended on this… let me go back signing some zones ;-)