Modelação de tráfego com iptables e tc

Alerta de largura de banda excessiva

Quando geres servidores, reparas que o tráfego de internet costuma seguir padrões previsíveis. Tal como o trânsito real nas estradas, há horas regulares de grande movimento e de sossego.

O gráfico de largura de banda do AMS-IX mostra um padrão previsível: repara no padrão ondulado

O padrão previsível permite detetar anomalias automaticamente. Tal como um engarrafamento numa autoestrada a uma hora invulgar pode ser o resultado de um acidente, oscilações inesperadas no tráfego de internet podem indicar um incidente no ciberespaço.

Gráfico de largura de banda com um pico invulgar a indicar que algo está errado: não precisas de ser o Sherlock Holmes para o encontrar

Isolar a origem

A primeira coisa a fazer é encontrar a origem do problema. Faz isso analisando a anomalia:

Determina se o tráfego extra é de entrada ou de saída (envio ou transferência?)
Determina os endereços IP de origem e de destino associados (que servidor é afetado? Para onde vai o tráfego, ou de onde vem?)
Determina o tipo de tráfego (e-mail, web ou outra coisa?)

Para isso deves inspecionar os gráficos de tráfego, que costumam indicar entrada/saída distintas. Depois tenta encontrar os endereços IP afetados. Pode ser preciso olhar para mais gráficos (de servidores individuais) e estatísticas dentro de switches, routers e servidores. A seguir, olha para a utilização do CPU e para os ficheiros de registo para determinar que aplicação é afetada, como o correio ou a web. Quanto maior a anomalia, mais fácil é encontrá-la.

Podes ser tentado a matar a anomalia assim que a encontras, parando de imediato o tráfego associado. Mas deves mesmo mantê-la viva (pelo menos um pouco mais) para aprenderes o máximo possível com ela.

Usar a ferramenta iftop para ver a utilização de largura de banda por endereço IP ligado

Usa uma ferramenta como o iftop para ver uma visão geral em tempo real da utilização de largura de banda por endereço IP ligado. É muito útil para perceber o que se passa, sobretudo em combinação com os ficheiros de registo (que ligam o endereço IP a contas individuais).

Uma causa invulgar

O servidor que produzia a utilização excessiva de largura de banda era um servidor de correio. Muitas vezes são alvo de hackers que os querem transformar em servidores de retransmissão de spam. Isto pode acontecer de várias formas, normalmente porque os spammers apanham credenciais de acesso válidas. Resulta em muito tráfego de saída, pois os spammers enviam imensos e-mails. Se uma campanha de spam acontece no teu servidor, provavelmente vês isso nos registos, porque as mensagens de spam costumam ser devolvidas, e as filas de correio enchem-se depressa. Fica uma confusão em pouco tempo, mas neste servidor não havia confusão nenhuma, apenas muita utilização invulgar de largura de banda.

O correio (e o spam) envia-se com o protocolo SMTP, mas o tráfego na porta SMTP deste servidor era normalíssimo. Isto era muito invulgar, pois significava que o tráfego excessivo vinha de outra coisa. Mas de quê? Depois de analisar vários ficheiros de registo no servidor de correio, determinei que o protocolo infrator era o IMAP. De alguma forma, um cliente ligado ao servidor de correio por IMAP estava a causar quantidades excessivas de tráfego de rede. O IMAP é um protocolo usado para ler e-mail, não para o enviar, o que torna as anomalias relacionadas com o IMAP muito raras.

Analisando o registo do servidor de correio, encontrei o utilizador específico que causava o tráfego. Contactei o cliente para perguntar se tinha reparado em algo estranho do lado dele. Como seria de esperar, tinha notado que o computador andava um pouco lento ultimamente.

Ciclo de sincronização do Microsoft Outlook

Depois de alguma tentativa e erro por telefone, apurámos que algo fazia o Microsoft Outlook sincronizar as pastas IMAP em ciclo. Isto fazia o computador dele transferir todo o conteúdo da caixa de correio uma e outra vez! Como a caixa de correio tinha mais de 40 gigabytes, isto causava o tráfego substancial. Aparentemente é causado por um erro no Microsoft Outlook, para o qual, infelizmente, não há solução fácil.

Erros no Microsoft Outlook fazem-no sincronizar as pastas IMAP sem parar, um problema sentido por muita gente (vê o número de visualizações!)

Mitigar com modelação de tráfego

Enfrentei a decisão difícil de bloquear o cliente (normal, legítimo, pagante) ou deixar o tráfego excessivo continuar (com custos sérios para o fornecedor de rede). Bloquear utilizadores legítimos que gerem o seu negócio por e-mail é uma péssima ideia, mas deixar o tráfego excessivo continuar também é mau. Felizmente, encontrei uma forma alternativa de reduzir o tráfego excessivo sem deixar de dar ao cliente acesso ao seu correio (com a sua fiável, mas defeituosa, app Outlook).

Modelação de tráfego

Como técnica de gestão de largura de banda, podes usar a modelação de tráfego (traffic shaping) para atrasar alguns (ou todos) os pacotes de dados e fazê-los cumprir um perfil de tráfego desejado. Quando a aplicas, estás, literalmente, a moldar os gráficos de tráfego, daí o nome.

Esta técnica não é isenta de polémica, pois é o oposto do tão aclamado princípio da "neutralidade da rede". Com a modelação de tráfego, podes bloquear ou abrandar de propósito (ou cobrar mais dinheiro por) tipos específicos de tráfego. Por princípio sou contra tudo o que prejudique a neutralidade da rede, mas nesta situação em particular não tinha alternativa viável. Precisava de abrandar a sério o tráfego de e-mail deste cliente, reduzindo a largura de banda e continuando a dar acesso à conta dele.

Implementar a modelação de tráfego

Para modelar o tráfego, tens de fazer duas coisas:

marcar o tráfego: só queres afetar determinado tráfego de rede, neste caso o acesso IMAP de um dado cliente. O restante tráfego não deve ser afetado. Isto faz-se marcando os pacotes que correspondem a determinadas características, como o IP do cliente ou os números das portas
aplicar a política de modelação: com ferramentas de controlo de tráfego como o "tc", aplicas então a política de modelação ao tráfego marcado. Há várias formas de o fazer, mas uma comum é trabalhar com os chamados "Hierarchy Token Buckets" ou HTB.

Hierarchy Token Buckets (HTB)

Em princípio, um token bucket é semelhante a limitar o número de passageiros numa viagem de comboio distribuindo apenas um número fixo de fichas disponíveis. Quando os passageiros (ou pacotes de dados) entram no comboio (ou na rede), pegam numa ficha. Quando saem (ou chegam ao destino), a ficha é devolvida. Com o princípio do token bucket podes controlar a quantidade de tráfego simultâneo num sistema.

Usar fichas para controlar o tráfego: só passageiros (ou pacotes de dados) com uma ficha válida são admitidos. As fichas são devolvidas quando o tráfego chega ao destino.

O tráfego tem de esperar que haja fichas disponíveis quando o número máximo de fichas já foi distribuído, impondo o máximo de tráfego simultâneo

Podes implementar este princípio com as ferramentas de rede "tc" (de traffic control) em combinação com o "iptables". Podes usar um script para definir as regras de marcação e aplicação. Encontras vários exemplos online; eu usei este do Julien Vehent.

Exemplo de script de modelação de tráfego

Conclusão

Às vezes as anomalias de rede não são o que esperas, por isso deves sempre dedicar tempo a investigá-las! Bloquear tráfego às cegas é grosseiro; por vezes é preciso refinar os métodos para mitigar problemas.

Aplicar técnicas de filtragem pouco ortodoxas não é algo de que goste, mas às vezes são o único meio para atingir o fim. Saber o que estás a fazer e porquê é muito importante!