Configurando o Firestarter

O Firestarter é um firewall gráfico para Linux, que é ao mesmo tempo bastante poderoso e fácil de usar. Ele é adequado para uso em desktops, onde é necessária uma forma simples de monitorar tentativas de conexão e abrir portas. Ele tornou-se rapidamente uma opção bastante popular e passou a ser incluído nas principais distribuições.

Você pode instalá-lo usando o gerenciador de pacotes (opção recomendada) ou baixar os pacotes disponíveis no http://www.fs-security.com/download.php. No Ubuntu e em outras distribuições derivadas do Debian, você pode instalá-lo usando o apt-get, como em:

Uma última opção é baixar o pacote com o código-fonte e compilá-lo manualmente. A instalação neste caso é feita descompactando o arquivo e rodando os comandos “./configure”, “make” e “make install”. A dificuldade é que você precisa ter os compiladores e a biblioteca de desenvolvimento do GTK instalados.

Ao abrir o Firestarter pela primeira vez, é aberto um assistente que pede algumas informações básicas sobre a configuração da rede e oferece opções para compartilhar a conexão e ativar o firewall sob demanda, ao conectar via modem ou ADSL PPPoE.

O compartilhamento de conexão cria um compartilhamento simples, via NAT, equivalente a usar as três regras do IPtables para compartilhar a conexão que mostrei em tutoriais anteriores. Para compartilhar a conexão é preciso que o seu micro possua duas placas de rede, uma para a rede local e a outra para a Internet.

Ao compartilhar a conexão, é necessário apenas marcar a opção “Habilitar o compartilhamento de conexão Internet” e indicar qual é a placa ligada à rede local:

Estas configurações podem ser alteradas posteriormente no menu “Editar > Preferências”. O Firestarter pode ser usado também para configurar o servidor DHCP, caso ele esteja instalado; se a opção de habilitar o servidor DHCP aparecer desativada na sua configuração, verifique se o pacote com o servidor DHCP (dhcp3-server, dhcp-server ou dhcp, dependendo da distribuição) está instalado. O Firestarter apenas altera a configuração, ele não faz a instalação do servidor DHCP para você:

Como o Firestarter precisa manipular as regras do IPtables e configurar outros componentes do sistema, ele só pode ser executado como root. Em muitas distribuições, é adicionado um ícone no menu que executa o Firestarter através do gksu ou kdesu, solicitando a senha de root durante a abertura.

Uma vez aberto, o Firestarter bloqueia por padrão todas as portas e loga todas as tentativas de conexão, uma configuração bastante segura. A partir daí, você pode ir criando uma lista de exceções, permitindo conexões em determinadas portas e a partir de determinados endereços.

Ainda na janela de configurações, verifique se a opção “Método de rejeição de pacotes preferido” está configurada como “Descartar silenciosamente”, em que é usada a política “DROP” do IPtables, ao invés de “REJECT”, onde o emissor recebe resposta.

A opção “Tráfego de broadcast” se refere a todos os pacotes direcionados à rede, como, por exemplo, os pacotes usados por servidores Windows (e Samba) para mapear os compartilhamentos disponíveis na rede. Deixe sempre a opção “Block broadcasts from external network” habilitada, para que sejam bloqueados os pacotes de broadcast provenientes da Internet.

Caso esteja usando uma rede wireless, acessando através de uma rede de terceiros (ou utilizando qualquer tipo de rede que considere insegura), marque também a opção “Block broadcasts from internal network”, para bloquear também os pacotes provenientes da rede local:

Um dos recursos mais interessantes, e o principal diferencial com relação a outros projetos, é que o Firestarter transforma os logs de tentativas de acesso gerados pelo IPtables em avisos dentro da aba “eventos”. Quando uma nova tentativa de acesso é registrada, o ícone ao lado do relógio fica vermelho e você tem a opção de aceitar ou recusar a conexão. Na ilustração, temos uma tentativa de acesso ao servidor SSH, que está habilitado na porta 22 a partir do host 192.168.1.2:

A opção “Permitir serviço de entrada para a origem” faz com que, daí em diante, o host 192.168.1.2 possa acessar o SSH (apenas na porta 22), sem disparar novamente o alarme, enquanto a opção “Permitir conexões a partir da origem” faz com que o 192.168.1.2 possa acessar qualquer serviço, em qualquer porta. Esta segunda opção é interessante para micros da rede local.

Finalmente, a opção “Permitir serviço de entrada para todos” abre a porta do SSH para todo mundo, incluindo micros da Internet. Esta é uma opção que deve ser usada com mais cautela.

Todas as regras adicionadas entram em vigor imediatamente e ficam acessíveis para modificação ou consulta na aba “Política”. Você pode ir também direto ao ponto, abrindo as portas utilizadas por algum serviço em especial antes que o firewall bloqueie a conexão. Na interface principal, acesse a aba “Política”, clique com o botão direito sobre o quadro “Permitir serviço”, “Adicionar Regra”.

Já estão disponíveis regras prontas para vários serviços. Lembre-se de que é necessário abrir portas apenas quando você está rodando um servidor Samba, Apache, SSH, etc.; não é preciso abrir portas para acessar estes mesmos serviços como cliente. A única exceção importante para esta regra de ouro é o NFS, onde é preciso manter a porta 111 aberta (no cliente) para conseguir montar os compartilhamentos.

Note que além da opção para abrir para todo mundo, você pode abrir apenas para um endereço IP específico ou para uma faixa de IPs, como em “192.168.1.0”

Caso o compartilhamento da conexão esteja ativo, aparecerá mais uma seção dentro da aba “Política”, a “Serviço de encaminhamento”, que permite redirecionar portas de entrada para micros da rede local.

A configuração é similar à abertura de portas, mas agora, em vez de especificar quais endereços terão acesso à porta aberta, você especifica qual micro da rede local receberá as conexões direcionadas a ela:

Você pode acompanhar as conexões em uso através do campo “Conexões ativas”, na tela principal. Note que a lista inclui todas as conexões, tanto as conexões como cliente, contatando outros micros da rede ou Internet quanto as conexões como servidor, recebendo uma conexão a partir de fora.

Outra observação é que muitos programas abrem diversas conexões simultâneas, o Gaim (ou outro cliente de ICQ/MSN), por exemplo, abre uma conexão com o servidor principal (quando você fica online) e mais uma conexão para cada janela de conversa aberta. Uma única instância do Bittorrent, por exemplo, pode chegar a abrir mais de 20 conexões, já que baixa e serve o arquivo para vários hosts simultaneamente. Preste atenção nas conexões em que o destino é seu próprio endereço IP, pois elas indicam conexões a servidores ativos na sua máquina.

Caso o compartilhamento de conexão esteja ativo, a lista mostra todas as conexões, de todos os micros da rede local (ou seja, uma lista possivelmente bem grande). Isso pode ser usado para detectar micros que estão rodando programas que consomem muita banda, como programas P2P em geral, e tomar as providências necessárias, avisando o usuário ou bloqueando as portas ou endereços IP das estações.

Para isso, acesse a aba “Política”. Mude a opção no botão “Edição” para “Política de tráfego de saída”. As opções agora permitem bloquear tráfego de dentro para fora, impedindo que determinados programas-clientes funcionem, ou que certos servidores ou sites sejam acessados.

Neste caso, existem duas abordagens. Você pode bloquear a porta usada pelo cliente, ou pode bloquear o acesso ao servidor a que ele se conecta. Por exemplo, o MSN envia mensagens através da porta 1863 e se conecta ao servidor messenger.hotmail.com. Bloqueando qualquer um dos dois, o cliente já deixa de funcionar. Mas, para garantir, você bloqueia ambos. Existe ainda um cliente disponível via navegador, através da página http://webmessenger.msn.com, que você pode pode bloquear também.

O ICQ se conecta ao servidor login.icq.com, através da porta 5190. Assim como no caso do MSN, existe uma versão via navegador, disponível no site http://go.icq.com. Você pode bloquear as três coisas. Se os usuários utilizarem clientes via web, como o meebo.com, você pode também adicioná-los à lista, eliminando assim as brechas sucessivamente.

Na mesma tela, é possível bloquear também sites específicos, adicionando domínio por domínio à lista. A idéia aqui é bloquear páginas específicas nas quais os usuários estejam gastando muito tempo, ou páginas de conteúdo impróprio. Lembre-se de que:

1- No caso de páginas de conteúdo impróprio, é mais prático usar um filtro de conteúdo (como um servidor Squid com o DansGuardian) do que ficar tentando bloquear endereço por endereço no firewall, já que existem muitos.

2- Bloquear um domínio ou um endereço IP aqui vai bloquear o acesso de todos os protocolos (POP3, SMTP, SSH, FTP, etc.), não apenas http, ou seja, significa realmente cortar relações. Caso você bloqueie o acesso ao IP de um servidor que hospeda vários sites, vai bloquear o acesso a todos eles.

Veja que aqui estou usando a opção “Tolerante por padrão”, na qual o firewall por padrão permite todo o tráfego de saída e você especifica manualmente o que bloquear. Você pode utilizar também o modo “Restrito por padrão”, onde o firewall bloqueia tudo e você precisa ir abrindo uma a uma as portas que serão utilizadas. O mínimo neste caso é abrir as portas 53/UDP (DNS), 80/TCP (http) e 443/TCP (https) para permitir o acesso à web básico e, a partir daí, ir abrindo um a um os demais protocolos necessários.

Uma vez que o firewall é ativado, as regras ficam ativas mesmo que você feche a interface principal. O Firestarter fica residente na forma do serviço de sistema “firestarter”, que é executado de forma independente da interface. Você pode usar o comando “iptables -L”, que lista as regras de firewall ativas para comprovar isso. Ao fechar a interface gráfica, você perde apenas a possibilidade de monitorar as tentativas de acesso e aceitar conexões

Para realmente parar o firewall, você precisa reabrir a interface e clicar no “Parar firewall” ou usar o comando “/etc/init.d/firestarter stop”. Ao contrário da maioria dos firewalls para Windows, o firewall em si é independente da interface.

Para que o firewall seja inicializado automaticamente durante o boot, é importante que o sistema esteja configurado para inicializar o serviço “firestarter” durante o boot. No Mandriva, você pode habilitá-lo no menu de serviços, dentro do Painel de Controle. No Fedora, e em outras distribuições derivadas do Red Hat, use o comando “chkconfig firestarter on” e, nas distribuições derivadas do Debian, use o comando “update-rc.d -f firestarter defaults“.

Uma ressalva é que, ao instalar a partir do código fonte, é preciso copiar manualmente o script “/etc/init.d/firestarter” para que ele trabalhe como um serviço de sistema. Dentro da árvore com o código-fonte, você encontra scripts para várias distribuições.

Você pode também configurar a interface do Firestarter para ficar residente como um ícone do lado do relógio ao ser fechado no “Editar > Preferências > Interface > Minimizar para a bandeja ao fechar a janela”.

Mais um problema comum é a necessidade de fornecer a senha de root cada vez que a interface do Firestarter é aberta, um detalhe bastante chato. Você pode eliminar essa necessidade utilizando o sudo para permitir que o seu usuário possa abrir o Firestarter como root, sem precisar fornecer a senha. Para isso, instale o pacote “sudo” (usando o gerenciador de pacotes da distribuição que estiver utilizando) e adicione as seguintes linhas no final do arquivo “/etc/sudoers“:

… substituindo o “usuário” pelo login desejado. Note que coloquei duas linhas, pois em algumas distribuições o binário do Firestarter é instalado dentro da pasta “/usr/bin” e, em outras (Debian, por exemplo), na pasta “/usr/sbin”. Na verdade, você vai precisar de apenas uma delas.

Feito isso, você pode passar a inicializar o Firestarter usando o comando “sudo firestarter” ou “sudo firestarter -start-hidden”, se preferir que ele já inicie minimizado ao lado do relógio.

Para que ele seja aberto automaticamente junto com o KDE, crie um arquivo de texto chamado “firestarter.desktop”, na pasta “.kde/Autostart/” dentro da sua pasta home, contendo o seguinte:

Todos os ícones de aplicativos colocados dentro desta pasta são executados durante a abertura do KDE. Você pode arrastar um ícone do menu para ela, usando o Konqueror ou criando um arquivo de texto manualmente. Note que os ícones colocados dentro desta pasta contém uma sintaxe especial e terminam com a extensão “.desktop”.

Executando com um usuário separado

O firewall protege contra worms e invasões, ataques “de fora para dentro”, mas não protege contra vírus e trojans executados localmente.

No primeiro tipo de ataque, o invasor procura uma porta aberta, tenta identificar o servidor ou programa que está ativo na porta (o SSH ou Apache, por exemplo), pesquisa por alguma vulnerabilidade conhecida ou erro de configuração e, caso encontre alguma coisa, lança um ataque, tentando utilizar a falha para obter acesso ao sistema. Com o firewall ativo, o ataque é frustrado logo no início, já que com todas as portas fechadas, simplesmente não existe por onde entrar, a menos que exista alguma falha de segurança no próprio IPtables, o que seria bastante improvável.

Imagine que um desktop que acessa a web apenas como cliente é uma casa, enquanto que um servidor é uma loja de porta aberta. Você pode fechar e reforçar todas as portas, transformando sua casa em um bunker (habilitar o firewall, fechando todas as portas), onde ninguém terá como entrar, a menos que consiga convencer você a abrir a porta para ele. Em um servidor a questão é mais complicada já que, assim como em uma loja, é preciso deixar a porta bem aberta para que os clientes possam entrar e sair.

A segurança, nesse caso, precisa ser feita em vários níveis. Em primeiro vem o firewall, que bloqueia todas as portas que não são usadas, mantendo abertas apenas as portas realmente utilizadas. Em segundo lugar vem a questão das atualizações de segurança. Ninguém invade um servidor simplesmente porque o SSH está habilitado, invade caso esteja em uso uma versão desatualizada, com alguma vulnerabilidade conhecida, ou caso exista alguma conta de usuário ativa, com uma senha fácil. Mantendo o servidor atualizado e seguindo regras básicas de segurança, o risco é pequeno.

Na hora de escolher uma distribuição para ser usada em um servidor, um dos quesitos mais importantes a analisar é justamente a questão das atualizações de segurança: em quanto tempo os pacotes são atualizados ao ser descoberta uma vulnerabilidade e por quanto tempo são disponibilizadas atualizações para a versão em uso.

A maior parte das distribuições comerciais oferece atualizações de segurança por 12 ou 18 meses depois de lançada uma nova versão. Nesse quesito, as distribuições baseadas no Debian levam uma certa vantagem, pois no Debian as atualizações são oferecidas de forma contínua. Sempre que uma nova versão é lançada, você pode atualizar os pacotes utilizando o apt-get e, assim, continuar instalando as atualizações indefinidamente.

O segundo tipo de ataque, que engloba vírus, trojans e afins, exige interação do usuário. Um vírus nunca se instala sozinho (caso contrário não seria um vírus, mas sim um worm), se instala porque alguém executou o arquivo que chegou por e-mail ou por um programa P2P, por exemplo.

No Windows, esta tarefa ficaria por conta do antivírus, antispyware & cia. Entretanto, como ainda não temos uma quantidade expressiva destas pragas no Linux, apenas o firewall em geral já é suficiente. Digo por enquanto, pois conforme o uso do sistema em desktops cresça, é natural que o número de vírus e pragas em geral para a plataforma também cresça, obrigando-nos a tomar mais cuidados.

Caso eventualmente os vírus e trojans tornem-se um problema no Linux, com certeza surgirão várias opções de antivírus, mas, mesmo antes que isso aconteça, existe um conjunto de cuidados simples que podem manter seu micro seguro desde já.

O Linux é reconhecidamente um sistema multiusuário, onde as permissões de arquivos e executáveis impedem que um usuário danifique arquivos ou configurações de outro, ou modifique as configurações do sistema. Embora isso torne as coisas mais complicadas em diversas situações, também cria uma barreira de segurança adicional bastante interessante.

Ao invés de rodar todos os programas e executar todo tipo de arquivo com seu usuário principal, crie um segundo login (ou até mais de um) e o utilize para executar arquivos suspeitos ou programas que possam ter problemas de segurança, como, por exemplo, clientes de IRC e navegadores.

Para isso, abra um terminal e use o comando “su” para logar-se usando o segundo usuário, como em “su joao“. Depois de fornecer a senha, todos os programas executados dentro do terminal serão executados pelo outro usuário. Se por acaso você executar qualquer programa malicioso, apenas o usuário separado é afetado, sem comprometer seus arquivos pessoais, muito menos os arquivos do sistema. Em caso de problemas, basta deletá-lo e criar outro.

Em distribuições baseadas no Debian, o sistema vem configurado para não permitir que outros usuários executem programas gráficos dentro de uma sessão gráfica já aberta. Ao tentar rodar qualquer programa gráfico, você recebe uma mensagem como:

Isso é solucionado por um utilitário chamado “sux“, que substitui o su, transferindo também as credenciais do X. Basta instalar o pacote “sux” (usando o apt-get, ou outro gerenciador de pacotes disponível) e usá-lo para trocar o usuário, como em: “sux joao”.