Re: [sw_livre] Firewall em Linux

(SG) Manuela Moreira wrote:

>Bom dia,
>
>Necessito de instalar um Firewall em Linux mas nada percebo disto. Tenho
>alguma formação em Unix mas já lá vai muito tempo e julgo que há as suas
>diferenças..
>A minha preocupação é maior ainda com a segurança porque ouço dizer que no
>Linux vem tudo aberto e somos nós que temos que tratar da segurança quase
>instrução a instrução.
>Não me dão umas dicas? Como devo começar?
>
>Cunprimentos,
>Manuela Moreira
>Secretaria Geral - Comunicações
>Ministério das Actividades Económicas e do Trabalho
>
>
>_______________________________________________
>sw_livre mailing list
>sw_livre@softwarelivre.citiap.gov.pt
>http://www.softwarelivre.citiap.gov.pt:8080/mailman/listinfo/sw_livre
>
>
Cara Manuela,

 É verdade que no linux está tudo aberto mas também é verdade que tudo
se entende. Se não, vejamos:
Quando um pacote de rede chega a uma maquina Linux/Unix, o núcleo do
sistema operativo verifica se existe alguma aplicação à escuta na
"porta" mencionada no pacote. Se existir o pacote é enviado para essa
aplicação. Se não existir o pacote é apagado. Moral da história, como
tudo vai ter ao kernel, e os novos kernel são dos sistemas mais bem
testados que existem no mundo tudo é infinitamente mais seguro que
qualquer outro sistema. Isto se nenhuma outra aplicação interna estiver
a correr (daemon) e a escutar uma certa porta. Normalmente todos os
daemon são iniciados automaticamente se existir um link para esse
programa nos directórios /etc/rcS.d/... a /etc/rc6.d/...
É muito importante sublinhar que se nenhum deamon for posto a correr
todos os pacotes serão eliminados.
O primeiro deamon que normalmente se põe a correr é o daemon de ssh
(Secure Shell).
Este permite que, de uma forma codificada qualquer utilizador com um
username e password possa entrar dar comandos dentro do sistema. Vamos
ver este exemplo um pouco mais em detalhe. Se o daemon de ssh estiver
mal construído ou se a codificação não forem óptimas alguém pode enviar
um pacote "mal intencionado" para a porta 22 (ssh), o kernel entrega o
pacote à aplicação sshd e o pior pode acontecer. Isto claro, apenas se o
deamon estiver a correr.
Neste exemplo como em qualquer outro daemon com serviços de email, web
server, etc., temos dois tipos de segurança - a baseada na ignorância e
a baseada no conhecimento.
A baseada na ignorância é utilizada nos sistemas proprietários, e
basea-se no facto de embora a aplicação esteja mal desenvolvida, os
potenciais atacantes não conhecem o seu código fonte ( tipicamente em C
ou C++) pelo que não podem localizar no código os erros e explorar as
vulnerabilidades excepto por "trial and error". É a segurança do bluff.
Pensamos que estamos seguros porque a nossa porta tem uma capa fina a
esconder o facto de não ter fechadura. Esta segurança é tanto melhor
quanto mais ataques de "trial an error" foram realizados e corrigidos
pelo fabricante. Basta lembrarmos-nos da saga da (in)segurança do
Internet Explorer.
O outro tipo de segurança consegue-se explicando aos melhores "gatunos"
de todo o mundo como tudo está a funcionar até ao detalhe ( todo o
código fonte é absolutamente público) e convidando-os a tentar entrar.
Depois criam-se milhões de portas deste tipo em todo o mundo e vamos
comunicando uns aos outros se alguém entrou. Claro que no inicio todas
as vulnerabilidades vão ser aproveitadas pois os "gatunos" têm o mapa
completo. Contudo, passado um pouco de tempo obtemos um sistema
praticamente sem falhas pois, mesmo com todos os mapas detalhados,
nenhum gatuno consegue entrar.

Esta segurança é tanto melhor quanto mais importante e visível é o
"daemon"/serviço a correr pois nesse caso já foi de certeza analisado
até ao mais infímo pormenor. Daemons menos utilizados podem ainda não
ter merecido a atenção dos "gatunos".

Claro que, para estar seguro, temos ter todos os deamons bastante
actualizados. Esta é uma segurança muito activa. Para estar seguro é
necessário estar na crista da onda, pelo menos no que respeita a
"patches" de segurança.

Se, por outro lado uma aplicação interna ao nosso computador comunica
com o exterior, ela temporáriamente abre uma porta de retorno por onde
são enviados os pacotes de resposta. Se não tivermos confiança nessa
aplicação, pode ser possível embora extremamente difícil aproveitar
essa porta temporária para um ataque. Ora bem, no Linux/Unix temos duas
protecções: 1- devemos correr as aplicações sendo um utilizador que não
o root. O kernel não deixa neste caso que uma aplicação que não pertença
a root faça nada de muito grave. 2- Devemos correr aplicações OpenSource
das quais toda a comunidade tem o código fonte. Assim, é extremamente
visível se alguém que desenvolveu o mozilla, por exemplo, lá deixou um
código que quando recebe um certo pacote realiza uma acção não desejada
ou fornece o controlo ao exterior. Toda a comunidade podia ir ver o
código fonte e descobrir quem inseriu aquelas linhas. Numa aplicação
"Closed Source", ninguém, por vezes nem mesmo o fabricante sabem quantos
cavalos de troia lá estão inseridos.
 
Finalmente temos o sistema iptables que corre no kernel do sistema
operativo. O iptables não interpreta o contéudo dos pacotes e portanto
não é vulnerável na máquina em que está a correr mas sim reenvia-los
para outras máquinas. Pode também alterar ou não o endereço da máquina
de origem que vai no pacote. Moral da história: Se a nova maquina de
destino tem um daemon a correr nessa porta que não foi submetido ao
processo anterior podemos ter vulnerabilidades. O iptables é normalmente
configurando de forma unidireccional pelo que os pacotes apenas
representam pedidos de abertura de conecções para o exterior.

Desculpem o tamanho da resposta mas talvez ajude a desmistificar um pouco,
António Amorim
Received on Tue Mar 22 13:54:34 2005