• Olá Visitante, se gosta do forum e pretende contribuir com um donativo para auxiliar nos encargos financeiros inerentes ao alojamento desta plataforma, pode encontrar mais informações sobre os várias formas disponíveis para o fazer no seguinte tópico: leia mais... O seu contributo é importante! Obrigado.
Portal Chamar Táxi

Segurança no Servidor

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Outros módulos interessantes






Existem diversos módulos PAM em uma distribuição Linux. Nem todos são usados, muitos são desconhecidos. Serão mostrados aqui alguns dos mais interessantes, do ponto de vista de segurança. Todos estes módulos estão bem descritos na documentação; veja em /usr/share/doc/pam-doc-versão mais detalhes sobre todos os módulos.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
pam_deny, pam_warn




Estes dois módulos são úteis para se adotar o que é chamado de fail-safe. Como já foi visto, cada programa que suporta PAM deve ter seu respectivo arquivo de configuração no diretório /etc/pam.d. Se o arquivo não existir, o PAM vai abrir o arquivo other. É interessante que este arquivo esteja da seguinte forma:

# default configuration: /etc/pam.d/other#auth required /usr/lib/security/pam_warn.soauth required /usr/lib/security/pam_deny.soaccount required /usr/lib/security/pam_deny.sopassword required /usr/lib/security/pam_warn.sopassword required /usr/lib/security/pam_deny.sosession required /usr/lib/security/pam_deny.so


O módulo pam_deny simplesmente vai sempre retornar erro. O problema é que ele não faz registros, e é aí que entra o pam_warn, cujo único objetivo é colocar uma mensagem no log do sistema. Um exemplo típico de log é ilustrado abaixo:

mar 19 10:53:51 kepler PAM-warn[8365]: service: su \ [on terminal: <unknown>]mar 19 10:53:51 kepler PAM-warn[8365]: user: (uid=681) -> root \ [remote: ?nobody@?nowhere]


Para gerar este log, foi removido o arquivo /etc/pam.d/su e, como usuário comum, deve-se tentar executar o comando su:

$ susu: senha incorreta


Se o arquivo other não tivesse o pam_warn, nada seria registrado nos logs do sistema.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
pam_access




O módulo pam_access pode ser usado para controlar quais usuários podem fazer login de qual local (terminal, remoto, domínio, etc.). Alguns servidores, como o openssh, já possuem um controle parecido embutido, mas também podem usufruir deste módulo. O arquivo de configuração do módulo pam_access é /etc/security/access.conf e contém alguns exemplos. A sintaxe é bastante simples. Por exemplo, a linha abaixo permite o login do usuário usuario1 (ou de usuários do grupo grupo1) apenas a partir dos terminais tty3 e tty4. O resto (inclusive logins remotos) fica negado:

- : usuario1 : ALL EXCEPT tty3 tty4


Note que somente alterar o arquivo /etc/security/access.conf não é o suficiente, isto é, o módulo pam_access precisa ser usado. Este módulo entra na categoria account e deve ser usado da seguinte forma:

account required /lib/security/pam_access.so


Mesmo que o serviço esteja explicitamente permitindo o login de um dado usuário, se pam_access estiver sendo usado e este mesmo usuário estiver bloqueado no access.conf, o login não será permitido
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
pam_limits




Este módulo é muito importante quando se tem usuários com shell em um servidor. Basicamente, ele configura limites para os recursos do sistema disponíveis para o usuário: uso de CPU, memória e outros que serão vistos a seguir. Note que estes limites são aplicados por processo, e não por usuário[2]. Este módulo entra apenas na categoria session e seu arquivo de configuração, /etc/security/limits.conf, contém vários detalhes. As entradas do arquivo de configuração do módulo pam_limits são da seguinte forma:

<domínio> <tipo> <item> <valor>


domínio:
Pode ser um nome de usuário, um nome de grupo (usando a sintaxe @grupo) ou um asterisco (*), indicando qualquer domínio.

tipo:
Pode ter somente dois valores: hard e soft. Limites do tipo hard são aqueles definidos pelo superusuário e impostos pelo kernel do Linux. O usuário não pode aumentar estes limites. Por outro lado, limites do tipo soft são aqueles que o usuário pode alterar, desde que não ultrapasse o que foi definido como um limite hard. Pode-se pensar neste último tipo de limites como sendo valores padrão para o usuário, ou seja, ele começa com estes valores.

item:
pode ser um dos seguintes:

core: tamanho máximo para arquivos core (KB).

data: tamanho máximo do segmento de dados de um processo na memória (KB).

fsize: tamanho máximo para arquivos que forem criados.

memlock: tamanho máximo de memória que um processo pode bloquear na memória física (KB).

nofile: quantidade máxima de arquivos abertos de cada vez.

rss: tamanho máximo de memória que um processo pode manter na memória física (KB).

stack: tamanho máximo da pilha (KB).

cpu: tempo máximo de uso de CPU (em minutos).

nproc: quantidade máxima de processos disponíveis para um único usuário.

as: limite para o espaço de endereçamento.

maxlogins: quantidade máxima de logins para este usuário.

priority: a prioridade com que os processos deste usuário serão executados.

valor:
Aqui deve ser colocado o valor para o item da coluna anterior.

É importante notar que se existirem limites para um usuário e para o seu grupo, os limites para o usuário terão preferência sobre os limites especificados para o seu grupo. E, mais uma vez, não basta alterar o arquivo de configuração se o módulo não for usado. Este é um módulo da categoria session, e deve ser utilizado da seguinte forma:

session required /lib/security/pam_limits.so


O módulo aceita dois parâmetros:

debug: aumenta a quantidade de mensagens que vão para o log do sistema;

conf=/caminho/para/arquivo.conf: indica um arquivo de configuração alternativo.

A seguir serão mostrados alguns exemplos. Número máximo de logins simultâneos para o grupo grupo1:

@grupo1 - maxlogins 1


Ultrapassando este limite, o usuário receberá uma mensagem na tela informando que excedeu o número máximo de logins e o log mostrará:

Mar 19 16:39:52 kepler pam_limits[14659]:Too many logins (max 1) \ for usuarioMar 19 16:39:54 kepler login[14659]: Permission denied


Se o PAM estiver sendo utilizado, isto vale também para logins remotos. Por exemplo, vale direto para o telnet, pois ele usa o programa login. Para fazer valer para SSH também, basta acrescentar o módulo pam_limits ao /etc/pam.d/sshd.

# telnet localhostTrying 127.0.0.1...Connected to localhost.Escape character is '^]'.Conectiva Linux 9Kernel 2.4.20-26373cllogin: usuario Password: $ telnet localhostTrying 127.0.0.1...Connected to localhost.Escape character is '^]'.Conectiva Linux 9Kernel 2.4.20-26373cllogin: usuarioPassword: Too many logins for 'usuario'Permission deniedConnection closed by foreign host.


Número máximo de processos para o grupo grupo2:

@grupo2 - nproc 3


Exemplo:

kepler login: usuarioPassword:$ bash$ bash$ bashbash: fork: Recurso temporariamente indisponível$ lsbash: fork: Recurso temporariamente indisponível$ exit$ lsDesktop GNUstep$


Este recurso de se limitar o número de processos é bastante interessante, pois evita um fork bomb se usado em conjunto com os outros parâmetros, como tempo máximo de uso de CPU por processo e com os parâmetros relacionados ao uso de memória e também limitando o número de logins simultâneos.

Note que alguns processos possuem seu próprio controle do uso de recursos, como o Sendmail ou mesmo o Apache, e se recusam a criar mais sub-processos em conseqüência de certas condições de carga da máquina
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
pam_time




O módulo pam_time pode ser usado para controlar o acesso a um serviço baseado no horário e dia da semana. A sintaxe para o uso do módulo é:

account required /lib/security/pam_time.so


O seu arquivo de configuração padrão é /etc/security/time.conf e as entradas são no formato:

serviço;terminal;usuários;horários


serviço: o nome do serviço, como, por exemplo, login ou sshd.

terminal: uma lista de terminais.

usuários: lista de usuários. Grupos não são suportados.

horários: lista de horários no formato DiaHorário. Para indicar os dias, deve-se usar a abreviação do dia da semana em inglês, além de outras abreviações úteis; veja a Tabela 7-2.

Tabela 7-2. Horários de Restrição de Login

Dia
Valor a ser usado na lista de horários

Segunda-feira
Mo

Terça-feira
Tu

Quarta-feira
We

Quinta-feira
Th

Sexta-feira
Fr

Sábado
Sa

Domingo
Su

Dias úteis
Wk

Fim-de-semana
Wd

Todos os dias
Al


Uma "lista", da forma como pode ser usada aqui, é uma seqüência de nomes e opcionalmente alguns caracteres especiais: ! (negação), * (curinga), & (AND) e | (OR).

Para especificar os horários, deve-se sempre utilizar o primeiro valor referente ao dia da semana e logo após a faixa de horários; por exemplo, Mo1800-0900 indica apenas a segunda-feira das 18h às 9 horas do dia seguinte, e Wk0900-1800 indica dias úteis (segunda a sexta) das 09 às 18 horas.

Para somente permitir o login no console nos dias úteis das 8 até às 18 horas, mas permitindo o login de root em qualquer horário, use:

login ; tty* ; !root ; Wk0800-1800


Uma observação importante: o processo de verificação do horário é feito apenas no início da sessão. Ou seja, não existe nenhum mecanismo que force a saída do usuário após o término do horário permitido de login. Por exemplo, aproveitando a regra acima, se um usuário se logar às 17h59 e não fizer logout, ele continuará na máquina mesmo após às 18 horas. Se ele sair, no entanto,não conseguirá entrar de novo pelo menos até às 8 horas do dia seguinte. Para contornar este problema, pode-se usar a variável de ambiente TMOUT[3] do bash. Esta variável especifica o tempo de inatividade máximo de uma sessão. Passando esse tempo, o logout é forçado.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Desabilitando Serviços Desnecessários





Os serviços normalmente habilitados no seu Conectiva Linux dependem do perfil utilizado na instalação do sistema. Portanto, após instalar o sistema você deve verificar quais deles realmente precisam estar habilitados. Existem, basicamente, dois tipos de serviços: aqueles que rodam no modo standalone e aqueles que rodam através do xinetd.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Serviços Standalone



Serviços que rodam no modo standalone são geralmente executados durante a inicialização do sistema, através dos chamados scripts de inicialização. O Apache e o LDAP são exemplos desses serviços.

Uma das ferramentas que podem ser utilizadas para configurar os serviços a serem executados é o Linuxconf. Para reiniciar, parar ou acionar serviços dirija-se ao menu Controle -> Painel de Controle -> Controle de atividades e serviços e seleciona o serviço desejado.

Outra ferramenta que pode ser utilizada é o ntsysv. Para instalá-lo, basta utilizar o apt-get (não esqueça de atualizar o arquivo de repositórios antes de instalar o pacote):

# apt-get install ntsysv


ntsysv

Para a configuração dos serviços a serem executados, basta selecioná-los na janela do ntsysv. Para executá-lo, digite:

# /usr/sbin/ntsysv


A Figura 7-2 ilustra a tela do programa ntsysv. Através desta tela você pode (e deve) desabilitar todos os serviços que não são utilizados. Para obter uma descrição de um serviço, selecione-o e pressione a tecla de função F1. Note que outros tipos de serviços são iniciados automaticamente, e não apenas serviços de rede. O gpm, por exemplo, é um serviço que adiciona suporte a mouse para aplicações que rodam no modo texto. Tome o cuidado de desabilitar apenas os serviços que não devem ser utilizados na máquina. Por exemplo, não desabilite o serviço httpd se for necessário rodar um servidor web na máquina.



ntsysv.jpg




Figura 7-2. Configuração da Inicialização de Serviços

O ntsysv configura apenas o nível de execução atual. Se você deseja configurar outros níveis de execução, estes níveis podem ser especificados na linha de comando, através da opção -&hairsp;-levels. É possível configurar vários níveis de execução simultaneamente. Executando o comando ntsysv -&hairsp;-levels 345, por exemplo, seriam configurados os níveis 3, 4 e 5 simultaneamente. Neste caso, se um serviço for marcado como habilitado, ele será habilitado em todos os níveis de execução especificados. De maneira análoga, ao desabilitar um serviço, o mesmo será desabilitado em todos os níveis de execução especificados.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Serviços Executados Através do xinetd





O xinetd (Extended Internet Services Daemon) é um daemon[4] geralmente executado na inicialização do sistema e que espera por conexões em alguns sockets internet específicos. Quando uma conexão é estabelecida em algum destes sockets, ele verifica a qual serviço o socket corresponde e invoca o programa capaz de servir a requisição em questão. Resumidamente, ele invoca daemons sob demanda, reduzindo a carga da máquina. Obviamente, este tempo necessário para invocar um daemon sob demanda pode ser prejudicial em serviços muito utilizados e é por isto que muitos serviços não podem ser executados através do inetd.

Nota: O xinetd trabalha de modo análogo ao inetd, possuindo somente arquivos de configuração diferentes. O inetd ainda continua na distribuição, podendo ser encontrado em um dos outros CDs do Conectiva Linux.

A configuração do xinetd reside no arquivo /etc/xinetd.conf e no diretório /etc/xinetd.d, embora o arquivo /etc/services também seja utilizado para mapear nomes de serviços para suas respectivas portas e protocolos. Estes arquivos podem ser alterados através de um editor de textos, ou então através do Linuxconf.

A configuração dos serviços e portas para o xinetd no Linuxconf é efetuada através da configuração de Configuração -> Rede -> Tarefas de servidor -> Serviços Internet. Esta configuração compreende a administração do arquivo /etc/services (opção Serviços de rede para Internet). Através desta opção, é possível adicionar, modificar ou remover o mapeamento do nome de um serviço para sua respectiva porta e protocolo. A Figura 7-3 ilustra a configuração do serviço chamado pop-3.


seguranca-servid-configur.jpg


Figura 7-3. Configuração de Serviços pelo Linuxconf

O arquivo /etc/xinetd.conf possui a configuração que será aplicada aos serviços contidos no diretório /etc/xinetd.d, e não é necessária nenhuma mudança em especial. Para informações mais detalhadas sobre as opções deste arquivo, dirija-se ao capítulo sobre o xinetd do Guia Entendendo o Conectiva Linux.

Um exemplo de serviço (echo) pode ser visto abaixo:

# default: off# description: An echo server. This is the tcp # version.service echo{ type = INTERNAL id = echo-stream socket_type = stream protocol = tcp user = root wait = no disable = yes}


Pode-se notar que este serviço está desabilitado (disable = yes), e portanto, para desabilitar qualquer serviço, basta modificar esta linha e reinicializar o xinetd:

# service xinetd restart


Como regra geral, mantenha desabilitados os serviços:

echo;

discard;

daytime;

chargen;

shell;

login;

exec;

talk (e similares);

tftp;

bootps;

finger (e similares);

systat;

netstat;

time.

Estes serviços dificilmente são necessários em sua máquina e possíveis invasores costumam utilizá-los como amostra do que está habilitado na máquina que pretendem invadir. Além destes, desabilite todos aqueles que não serão utilizados. Por exemplo, se não for necessário um servidor FTP na máquina, desabilite-o e, preferencialmente, desinstale do sistema o pacote correspondente.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Utilizando TCP_Wrappers




O pacote tcp_wrappers é utilizado para controlar o acesso a serviços. O xinetd já está configurado no Conectiva Linux para o uso do tcp_wrappers em todos os daemons possíveis e recomendados.

Os aplicativos necessários à utilização de tcp_wrappers já vêm instalados por padrão no Conectiva Linux. Você pode verificar procurando, na lista de pacotes instalados do Synaptic, pelo pacote tcp_wrappers.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando tcp_wrappers




A configuração dos serviços com tcp_wrappers deve ser efetuada através dos arquivos /etc/hosts.allow e /etc/hosts.deny. Em /etc/hosts.deny são configuradas as regras para negar serviços a determinados clientes, ao mesmo tempo em que no arquivo /etc/hosts.allow configuram-se regras para permitir que determinados clientes tenham acesso a serviços.

Existem dezenas de possibilidades de configuração para o tcp_wrappers e você pode estudá-las em extensão através das páginas de manual hosts_access e hosts_options. Portanto, serão ilustrados apenas alguns casos interessantes do uso desta ferramenta.

As regras de controle de acesso, existentes nestes dois arquivos, têm o seguinte formato:

lista_de_daemons : lista_de_clientes [ : comando ]

lista_de_daemons
Lista de um ou mais nomes de daemons como especificados no /etc/inetd.conf, ou curingas.

lista_de_clientes
Lista de um ou mais endereços ou nomes de máquinas, padrões ou curingas utilizados para especificar quais clientes podem e quais não podem acessar o serviço.

comando (opcional)
É possível executar um comando sempre que uma regra casa com um padrão e é utilizada. Veja exemplos a seguir.

Como citado anteriormente, curingas podem ser utilizados tanto na lista de daemons quanto na lista de clientes. Entre os existentes, pode-se destacar os seguintes:

ALL
Significa todos os serviços ou todos os clientes, dependendo apenas do campo em que se encontra.

LOCAL
Este curinga casa com qualquer nome de máquina que não contenha um caractere ponto ".", isto é, uma máquina local.

PARANOID
Casa com qualquer nome de máquina que não case com seu endereço. Isto geralmente ocorre quando algum servidor DNS está mal configurado ou quando alguma máquina está tentando se passar por outra.

Na lista de clientes podem ser utilizados nomes ou endereços de máquinas, ou então padrões que especificam um conjunto de máquinas. Se a cadeia de caracteres que identifica um cliente inicia com um ponto ".", um nome de máquina irá casar com este padrão sempre que o final desse nome casar com o padrão especificado. Por exemplo, se fosse utilizada a cadeia de caracteres ".minhaorganizacao", o nome de máquina galileu.minhaorganizacao casaria com o padrão.

Similarmente, se a cadeia de caracteres termina com um ponto ".", um endereço de máquina irá casar com o padrão quando seus campos numéricos iniciais casarem com a cadeia de caracteres especificada. Para exemplificar, se fosse utilizada a cadeia de caracteres "192.168.220.", todas as máquinas que tenham um endereço IP que inicie com estes 3 conjuntos de números irão casar com o padrão (192.168.220.0 ao 192.168.220.255).

Além destes métodos, é possível identificar um cliente através do IP/máscara de rede. Você pode especificar, por exemplo, "192.168.220.0/255.255.255.128", e qualquer máquina com endereço IP entre 192.168.220.0 e 192.168.220.127 casaria com o padrão.

Uma boa política é fechar completamente o acesso de todos os serviços a quaisquer clientes, através do arquivo /etc/hosts.deny, e seletivamente liberar o acesso aos serviços necessários através do arquivo /etc/hosts.allow. No Exemplo 7-1, está descrita uma configuração que libera o acesso a FTP apenas ao domínio minhaorganizacao, o acesso ao servidor POP3 a qualquer máquina, todos os serviços para localhost e nega-se os demais serviços para qualquer máquina que seja.

Exemplo 7-1. Exemplo de Configuração do tcp_wrappers

Segue abaixo o arquivo /etc/hosts.deny:

ALL:ALL


Arquivo /etc/hosts.allow:

ALL: localhostin.ftpd: .minhaorganizacaoipop3d: ALL


No Exemplo 7-2, considere o mesmo arquivo /etc/hosts.deny do exemplo anterior:

Exemplo 7-2. Configuração do tcp_wrappers menos restritiva

Arquivo /etc/hosts.allow:

ALL: localhostin.ftpd: .minhaorganizacao 200.234.123.0/255.255.255.0 200.248.ipop3d: ALL EXCEPT hackerboys.org


Neste último caso, máquinas da rede "200.234.123.0/255.255.255.0" e máquinas em que o endereço IP inicie por "200.248." também podem acessar o serviço FTP. Note que foi utilizado um operador novo para o serviço ipop3d: EXCEPT. Isto permitiu que o acesso a este serviço fosse liberado para todos, exceto para máquinas da rede "hackerboys.org".

O operador EXCEPT pode ser utilizado tanto na lista de clientes quanto na lista de serviços. Por exemplo, a linha:

ALL EXCEPT in.ftpd: ALL

no arquivo /etc/hosts.allow permite o acesso a todos os serviços, exceto o FTP, para qualquer máquina.

Todos os acessos, bem-sucedidos ou não, são registrados através do syslog. No Conectiva Linux estas informações são registradas no arquivo /var/log/secure. É recomendado que este arquivo seja periodicamente analisado à procura de tentativas de invasão.

Vários outros exemplos de configuração estão descritos nas páginas de manual citadas anteriormente (hosts_access e hosts_options).

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Testando a Configuração









Negue certos serviços para uma máquina de sua rede (como por exemplo o serviço telnet) e após reinicializar o xinetd, procure fazer acessos da máquina onde o serviço foi negado.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Verificando a Integridade do Sistema




Uma das primeiras ações de um invasor costuma ser substituir arquivos e programas do sistema com o intuito de mascarar sua visita atual e, principalmente, facilitar as visitas futuras. Portanto, se houver a possibilidade de verificar a integridade de arquivos do sistema, haverá uma grande possibilidade de detectar uma invasão. E o melhor é que este recurso permite que se saiba quais arquivos foram modificados, possibilitando que o administrador decida entre reinstalar o sistema ou apenas substituir o arquivos alterados pelos originais.

Após perceber que a máquina foi invadida, o administrador costuma analisar o sistema utilizando programas como ps, ls, netstat e who. Ocorre que estes programas são os primeiros a serem substituídos, ocultando, assim, a invasão e o invasor propriamente dito. Mesmo que se tenha a informação de data e tamanho dos arquivos originais, estas informações, sozinhas, não podem ser utilizadas como parâmetro, pois podem ser facilmente modificadas. Contudo, se além destas informações estiver disponível algo como o checksum MD5 dos arquivos, torna-se bem mais simples encontrar arquivos indevidamente modificados.

O AIDE (Advanced Intrusion Detection Environment) é um programa que tem justamente a finalidade de verificar a integridade dos arquivos do sistema. Ele constrói uma base de dados com várias informações dos arquivos especificados em seu arquivo de configuração. Esta base de dados pode conter vários atributos dos arquivos, como:

permissões;

número do inode;

dono;

grupo;

tamanho;

data e hora de criação, último acesso e última modificação.

Além disso, o AIDE também pode gerar e armazenar nesta base de dados o checksum criptográfico dos arquivos, utilizando um, ou uma combinação dos seguintes algoritmos: md5, sha1, rmd160 e tiger.

O procedimento recomendado é que você crie esta base de dados em um sistema recém-instalado, antes de conectá-lo a uma rede. Esta base de dados será a fotografia do sistema em seu estado normal e o parâmetro a ser utilizado para medir alterações no sistema de arquivos. Obviamente, sempre que você modificar o seu sistema, como por exemplo através da instalação, atualização ou remoção de programas, uma nova base de dados deve ser gerada. Esta nova base de dados é que deve ser utilizada como parâmetro. A base de dados deve conter informações sobre binários, bibliotecas e arquivos de cabeçalhos importantes do sistema, já que estes não costumam ser alterados durante o uso normal do sistema. Informações sobre arquivos de log, filas de correio eletrônico e de impressão, diretórios temporários e de usuários não devem ser armazenados na base de dados, já que são arquivos e diretórios freqüentemente alterados
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Instalando o AIDE




Para instalar o AIDE, utilize o apt-get, digitando o seguinte comando em um terminal:

# apt-get install aide

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configuração do AIDE




A configuração do AIDE reside no arquivo /etc/aide.conf. Este arquivo tem três tipos de linhas:

linhas de configuração: utilizadas para definir parâmetros de configuração do AIDE.

linhas de seleção: utilizadas para indicar quais arquivos terão suas informações adicionados à base de dados.

linhas de macro: utilizadas para definir variáveis no arquivo de configuração.

Apenas as linhas de seleção são essenciais ao funcionamento do AIDE. Existem, por sua vez, três tipos de linhas de seleção. Estas linhas são interpretadas como expressões regulares. Linhas que começam com uma barra "/" indicam que os arquivos que casarem com o padrão terão suas informações adicionadas ao banco de dados. Se a linha iniciar com um ponto de exclamação "!", ocorre o contrário: os arquivos que casam com o padrão são desconsiderados. Linhas iniciadas por um sinal de igualdade "=" informam ao AIDE que somente arquivos que sejam exatamente iguais ao padrão devem ser considerados.

Através das linhas de configuração é possível definir alguns parâmetros de funcionamento do AIDE. Estas linhas têm o formato parâmetro=valor. Os parâmetros de configuração estão descritos a seguir:

database
A URL do arquivo de banco de dados de onde as informações são lidas. Pode haver somente uma linha destas. Se houver mais de uma, apenas a primeira será considerada. O valor padrão é ./aide.db.

database_out
A URL do arquivo de banco de dados onde são escritas as informações. Assim como database, deve haver apenas uma linha destas. No caso de haver várias, somente a primeira ocorrência será considerada. O valor padrão é ./aide.db.new.

report_url
A URL onde a saída do comando é escrita. Se existirem várias instâncias deste parâmetro, a saída será escrita em todas as URLs. Se você não definir este parâmetro, a saída será enviada para a saída padrão (stdout).

verbose
Define o nível de mensagens que é enviado à saída. Este valor pode estar na faixa entre 0 e 255 (inclusive) e somente a primeira ocorrência deste parâmetro será considerada. É possível sobrescrever este valor através das opções -&hairsp;-version ou -V na linha de comando.

gzip_dbout
Informa se o banco de dados deve ser compactado ou não. Valores válidos para esta opção são yes, true, no e false.

Definições de grupos
Se o parâmetro não for nenhum dos anteriores então ele é considerado uma definição de grupo. Embora existam alguns grupos predefinidos que informam ao AIDE quais as informações do arquivo que devem ser armazenadas na base de dados, você pode criar suas próprias definições. A Tabela 7-3 mostra os grupos predefinidos.

Tabela 7-3. Grupos Predefinidos

p permissões
i inode
n número de links
u dono
g grupo
s tamanho
m data e hora da última modificação
a data e hora do último acesso
c data e hora da criação do arquivo
S verifica o aumento do tamanho do arquivo
md5 checksum md5
sha1 checksum sha1
rmd160 checksum rmd160
tiger checksum tiger
R p+i+n+u+g+s+m+c+md5
L p+i+n+u+g
E grupo vazio
> arquivo de log (aumenta o tamanho) - p+u+g+i+n+S

Você poderia definir um grupo que verifica apenas o dono e o grupo do arquivo, da seguinte maneira:

trivial=u+g

As linhas de macro podem ser utilizadas para definir variáveis e tomar decisões baseadas no valor destas. Informações detalhadas podem ser encontradas na página de manual do arquivo de configuração (man aide.conf).

O termo URL, utilizado na configuração dos parâmetros database, database_out e report_url, pode assumir um dos seguintes valores:

stdout: a saída é enviada para a saída padrão.

stderr: a saída é enviada para a saída padrão de erros.

stdin: a entrada é lida da entrada padrão.

file:/arquivo: a entrada é lida de arquivo ou a saída é escrita em arquivo.

fd:número: a entrada é lida do filedescriptor número ou a saída é escrita no filedescriptor número.

Note que URLs de entrada não podem ser utilizadas como saídas e vice-versa.

O Exemplo 7-3 ilustra uma configuração básica para o AIDE.

Exemplo 7-3. Arquivo de Configuração do AIDE

# Localização da base de dadosdatabase=file:/var/aide/aide.db# Local onde é criada uma base de dados novadatabase_out=file:/var/aide/aide.db.new# Arquivo onde será salva a saída do programareport_url=/var/aide/report.aide# Grupo para verificação de dono, grupo e permissões trivial=u+g+p/bin R/sbin R/boot R/etc R# Verifica apenas dono, grupo e permissões/etc/passwd trivial/etc/shadow trivial# Ignora o diretório /etc/X11!/etc/X11/lib R# Incluindo /var/var R# Ignora /var/log, /var/spool e /var/lock!/var/log/.*!/var/spool/.*!/var/lock/.*# Ignora o arquivo /var/run/utmp!/var/run/utmp$


O ideal é ignorar diretórios que são modificados com muita freqüência, a não ser que você goste de logs gigantescos. É um procedimento recomendado excluir diretórios temporários, filas de impressão, diretórios de logs e quaisquer outras áreas freqüentemente modificadas. Por outro lado, é recomendado que sejam incluídos todos os binários, bibliotecas e arquivos de cabeçalhos do sistema. Muitas vezes é interessante incluir diretórios que você não costuma observar, como o /dev/ e o /usr/man.

Atenção
Se sua idéia é referir-se a um único arquivo, você deve colocar um $ no final da expressão regular. Com isto, o padrão casará apenas com o nome exato do arquivo, desconsiderando arquivos que tenham o início do nome similar.


O pacote do AIDE que acompanha o Conectiva Linux tem um arquivo de configuração padrão funcional, mas nada o impede de modificá-lo para refletir suas necessidades.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Utilização do AIDE



Como o arquivo de configuração padrão deverá servir para a maioria dos casos, para gerar o banco de dados basta executar os comandos:

# /usr/bin/aide -i# mv /var/aide/aide.db.new /var/aide/aide.db


Após esta operação, você deve executar o comando:

# /usr/bin/aide-md5 [dispositivo de boot]


O parâmetro [dispositivo de boot] é opcional, e corresponde ao dispositivo de armazenamento utilizado para inicialização do sistema (/dev/hda, por exemplo).

O aide-md5 foi desenvolvido pela Conectiva e supre a falta de assinatura do banco de dados do AIDE. Ele informa os somatórios MD5 de alguns componentes críticos ao funcionamento do AIDE, inclusive do próprio banco de dados recém-gerado. Você deve tomar nota desses somatórios para verificação posterior.

Se o dispositivo de boot for informado ao aide-md5, o MD5 do setor de boot também será calculado, portanto é interessante informar esse parâmetro.

Testando a Configuração
Para verificar a integridade do sistema, execute o próprio AIDE, desta forma:

# /usr/bin/aide -C


Os arquivos que sofreram qualquer mudança, seja no tamanho, conteúdo, permissões ou data de criação, serão listados.

É provável que, na maioria das vezes que o AIDE apontar diferenças em arquivos, elas tenham sido provocadas por atos legítimos, por exemplo, atualização de pacotes ou intervenção do administrador do sistema. Nesses casos, o administrador deve, após uma conferência, reconstruir o banco de dados.

Para verificar a integridade do próprio AIDE, deve-se novamente utilizar o programa aide-md5, mas desta vez, de uma mídia removível, como, por exemplo, de um disquete:

# /mnt/floppy/aide-md5 /dev/hda


Se algum dos códigos MD5 não bater com aqueles gerados anteriormente, o(s) respectivo(s) componente(s) pode(m) estar comprometido(s), e isto é um problema muito sério.

Obviamente que, se você alterou as configurações do AIDE, regerou o banco de dados ou atualizou o kernel, os códigos serão diferentes. Logo após efetuar quaisquer destas alterações, você deve executar novamente o aide-md5 e anotar os códigos.

Atenção
É altamente recomendável copiar o aide-md5 para um meio removível, protegido contra gravação, e uma vez que o sistema tenha entrado em produção, deve-se executá-lo sempre a partir daquele meio, eventualmente removendo o aide-md5 original do disco rígido. Pois, se você fizer uso do aide-md5 do disco rígido, e este for comprometido, o invasor pode forjar somatórios MD5 falsamente perfeitos.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Bind-Chroot



O bind-chroot é uma versão do bind padrão modificada para executá-lo de modo "enjaulado"[5] dentro de um diretório, de maneira que ele não tenha acesso aos diretórios do sistema. Essa característica garante que, caso o bind-chroot seja atacado e forneça acesso à máquina, o invasor não terá acesso aos diretórios externos àquele utilizado pelo bind-chroot[6].

Características do Bind-chroot
A seguir serão vistas algumas das vantagens de se "enjaular" o bind num diretório específico:

Caso um invasor consiga, durante um ataque, acesso à sua máquina, ele não poderá navegar na estrutura de diretórios acima do diretório no qual o bind foi "enjaulado".

Dentro do diretório onde o bind estiver "enjaulado" existirão apenas os arquivos necessários para a utilização do bind, não deixando brechas para a execução de, por exemplo, um shell (/bin/sh) caso sua máquina seja atacada.

Para utilizar o bind-chroot é preciso criar uma nova estrutura de diretórios semelhante à estrutura do diretório raiz (/) e duplicar alguns arquivos[7] existentes no seu disco rígido para que ele possa executar "enjaulado". A instalação do pacote bind-chroot já cria todos os diretórios e arquivos necessários para a utilização dele.

Nota: Um detalhe importante é que, caso haja uma atualização dos arquivos das bibliotecas[8] que o bind-chroot utiliza, o administrador do sistema deverá lembrar de atualizar os arquivos dentro do diretório onde ele está "enjaulado".

Pré-requisitos
Para utilizar o bind-chroot, você irá precisar ter o bind instalado e configurado.

Nota: Um detalhe que muitas vezes passa despercebido é que quando você instala o bind-chroot você deve alterar o arquivo /etc/sysconfig/named, modificando para yes o parâmetro CHROOT.

Instalação
Para instalar o bind-chroot, execute o Synaptic e selecione o seguinte pacote para a instalação:

bind-chroot

É possível também instalar o bind-chroot utilizando o apt-get:

# apt-get install bind-chroot

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configuração do Bind-chroot



A configuração do bind-chroot é idêntica à configuração do bind, já vista no Capítulo 1. A única diferença entre as configurações do bind e do bind-chroot é a localização do arquivo de configuração. O arquivo de configuração do bind-chroot está localizado em /var/named/etc/named.conf em vez de estar no /etc/named.conf, que é o local padrão do arquivo de configuração do bind.

Observe que toda a estrutura de arquivos do bind-chroot é idêntica à utilizada pelo bind, porém relativa à /var/named/, que é o diretório raiz para o bind-chroot.

Testando a Configuração
Para testar se o bind-chroot está executando "enjaulado", no terminal digite:

# ps auxwww | grep named


O comando acima deverá mostrar uma saída semelhante a esta:

named 1805 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1806 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1807 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1808 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namednamed 1809 0.0 2.7 11652 3460 ? S Mar05 0:00 named -u named -t \ /var/namedroot 2002 0.0 0.4 1364 592 ? S Mar05 0:00 syslogd -m 0 -a \ /var/named/dev/log


Observe nas linhas acima a opção -t /var/named na linha de execução do bind; essa opção indica que o bind será executado "enjaulado" no diretório /var/named/. Outra maneira de verificar se o bind está rodando "enjaulado" é listar o conteúdo do diretório /proc/pid/, onde pid é o número do processo do bind que está executando. Tomando como exemplo o processo 1805, veja a saída do comando a seguir:

# l /proc/1805 total 0 dr-xr-xr-x 3 named named 0 Mar 6 15:27 ./ dr-xr-xr-x 100 root root 0 Mar 5 10:55 ../ -r-&hairsp;-r-&hairsp;-r-&hairsp;- 1 root root 0 Mar 6 15:27 cmdlinelrwxrwxrwx 1 root root 0 Mar 6 15:27 cwd -> /var/named/var/named/ -r-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;- 1 root root 0 Mar 6 15:27 environlrwxrwxrwx 1 root root 0 Mar 6 15:27 exe -> /usr/sbin/named* dr-x-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;- 2 root root 0 Mar 6 15:27 fd/ -r-&hairsp;-r-&hairsp;-r-&hairsp;- 1 root root 0 Mar 6 15:27 maps -rw-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;-&hairsp;- 1 root root 0 Mar 6 15:27 memlrwxrwxrwx 1 root root 0 Mar 6 15:27 root -> /var/named/ -r-&hairsp;-r-&hairsp;-r-&hairsp;- 1 root root 0 Mar 6 15:27 stat -r-&hairsp;-r-&hairsp;-r-&hairsp;- 1 root root 0 Mar 6 15:27 statm -r-&hairsp;-r-&hairsp;-r-&hairsp;- 1 root root 0 Mar 6 15:27 status


Observe a quarta linha de baixo para cima, onde está indicada a opção root. Note que esse arquivo é um link para /var/named/, indicando que o diretório raiz desse processo é /var/named/. Dessa maneira, verifica-se que o bind está executando "enjaulado".

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Firewall Através de Filtro de Pacotes




Um firewall é um sistema que isola redes distintas e permite que se controle o tráfego entre elas. Um exemplo típico onde a utilização de um firewall é recomendada é na conexão de uma rede local à Internet. Embora o conceito de firewall seja bastante amplo e possa envolver servidores proxy, analisadores de logs e filtros de pacotes, entre outras características, nesta seção será visto somente o filtro de pacotes fornecido pelo kernel do Linux.

O kernel do Linux conta com um filtro de pacotes bastante funcional, que permite que sua máquina descarte ou aceite pacotes IP, baseando-se na origem, no destino e na interface pela qual o pacote foi recebido. A origem e o destino de um pacote são caracterizados por um endereço IP, um número de porta e pelo protocolo.

Todo o tráfego através de uma rede é enviado no formato de pacotes. O início de cada pacote informa para onde ele está indo, de onde veio e o tipo do pacote, entre outros detalhes. A parte inicial deste pacote é chamada cabeçalho. O restante do pacote, contendo a informação propriamente dita, costuma ser chamado de corpo do pacote.

Um filtro de pacotes analisa o cabeçalho dos pacotes que passam pela máquina e decide o que fazer com o pacote inteiro. Possíveis ações a serem tomadas em relação ao pacote são:

aceitar: o pacote pode seguir até seu destino.

rejeitar: o pacote será descartado, como se a máquina jamais o tivesse recebido.

bloquear: o pacote será descartado, mas a origem do pacote será informada de que esta ação foi tomada.

O filtro de pacotes do kernel é controlado por regras de firewall, as quais podem ser divididas em quatro categorias: a cadeia de entrada (input chain), a cadeia de saída (output chain), a cadeia de reenvio (forward chain) e cadeias definidas pelo usuário (user defined chain). Para cada uma destas cadeias é mantida uma tabela de regras separada.

Uma regra de firewall especifica os critérios de análise de um pacote e o seu alvo (target). Se o pacote não casa com o padrão especificado pela regra, a regra seguinte da cadeia é analisada. Se desta vez o pacote casar com o padrão, a regra seguinte é definida pelo alvo, que pode ser o nome de uma cadeia definida pelo usuário, ou um dos seguintes valores especiais:

ACCEPT
Significa que o filtro de pacotes deve deixar o pacote passar.

DROP
Significa que o filtro de pacotes deve impedir que o pacote siga adiante.

REJECT
Assim como DROP, significa que o pacote não deve seguir adiante, mas uma mensagem ICMP é enviada ao sistema originador do pacote, avisando-o de que o pacote foi rejeitado. Note que DENY e REJECT têm o mesmo significado para pacotes ICMP.

MASQUERADE
Este alvo somente é válido para a cadeia de reenvio e para cadeias definidas pelo usuário, e somente pode ser utilizado quando o kernel é compilado com suporte a IP Masquerade. Neste caso, pacotes serão mascarados como se eles tivessem sido originados pela máquina local.

REDIRECT
Este alvo somente é válido para a cadeia de entrada e para cadeias definidas pelo usuário e somente pode ser utilizado se o kernel foi compilado com a opção de Transparent proxy. Com isto, pacotes serão redirecionados para um socket local, mesmo que eles tenham sido enviados para uma máquina remota (veja o Capítulo 6 para mais detalhes). Obviamente isto só faz sentido se a máquina local é utilizada como gateway para outras máquinas. Se a porta especificada para redirecionamento é "0", que é o valor padrão, a porta de destino dos pacotes será utilizada como porta de redirecionamento. Se for especificada uma outra porta qualquer, esta será utilizada, independentemente daquela especificada nos pacotes.

RETURN
Se a regra contendo o alvo RETURN foi chamada por uma outra regra, a regra seguinte da cadeia que a chamou é analisada. Caso ela não tenha sido chamada por outra regra, a política padrão da cadeia é utilizada para definir o destino do pacote.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando o firewall utilizando Iptables



Nesta seção será visto como configurar o firewall utilizando o netfilter. Como o Linuxconf ainda não suporta o Iptables, deve-se efetuar as configurações manualmente digitando os comandos diretamente num terminal. Nesta seção será permitido que as máquinas internas acessem diretamente a Internet. O servidor Web será uma máquina interna com um número IP reservado. Veja a Figura 7-4.


firewall_iptables.jpg


Figura 7-4. Firewall com iptables




Os recursos disponibilizados pelo netfilter são manipulados através do comando iptables. Como a criação de regras através do netfilter é dinâmica, assim como o ipchains, seu conteúdo é perdido quando a máquina é reinicializada. Quando utiliza-se o Linuxconf para efetuar essas configurações, as regras são salvas num arquivo interno. Esse é um dos motivos pelos quais deve-se criar um script de inicialização para que, após configuradas as regras de utilização, elas sejam executadas a cada inicialização.

Antes da criação de scripts e definição de quais serão as regras a serem utilizadas, será mostrada um pouco da sintaxe utilizada pelo comando iptables no tratamento de ganchos pré-existentes[9]. A sintaxe mais utilizada do comando iptables é a seguinte:

# iptables [X] [cadeia] [índice ou especificação_da_regra] [opções]


onde [X] pode ser:

-A: adicionar uma nova regra a uma cadeia.

-I: inserir uma nova regra numa posição em uma cadeia.

-R: substitui uma regra em uma posição da cadeia.

-D: apaga uma regra em uma posição da cadeia.

-D: apaga a primeira regra que casa com uma cadeia.

Basicamente, serão utilizadas as opções para adicionar (-A) e apagar (-D). As outras (-I para inserir e -R para substituir) são simplesmente extensões desses conceitos. Cada regra especifica um conjunto de condições que o pacote precisa satisfazer, e dependendo do que ele satisfizer, ele será direcionado para um destino ou para outro.

Atenção
É possível que, ao adicionar uma regra errada, sua máquina pare de funcionar corretamente. Neste caso, utilize o comando iptables -F, para que todas as regras do filtro de pacotes sejam desativadas. Porém, caso a política padrão esteja como DROP ou REJECT você precisará utilizar o comando iptables -P INPUT ACCEPT e a seguir iptables -P OUTPUT ACCEPT para redefinir a política padrão utilizada. Caso queira saber quais regras estão ativas, você pode usar o comando iptables -L .


Pré-requisitos
Para poder utilizar o comando iptables você deverá ter o pacote iptables instalado no seu sistema e também o módulo ip_tables.o carregado.

Para carregar o módulo ip_tables execute o seguinte comando:

# modprobe ip_tables


Instalação
Para instalar o iptables, selecione o seguinte pacote através do Synaptic:

iptables

É possível instalar o iptables utilizando o apt-get, digitando o seguinte comando em um terminal:

# apt-get install iptables



 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Configurando as regras para o firewall




Como foi visto anteriormente (Capítulo 6), a política padrão da cadeia de entrada deveria ser definida como DROP, negando qualquer acesso à rede. A sintaxe utilizada pelo iptables para efetuar essa ação é:

# iptables -t filter -P INPUT DROP


Deve-se permitir o acesso a um servidor web que escuta na porta 80 de uma máquina interna que possui o IP 192.168.1.200; porém, antes deve-se permitir todo e qualquer tráfego na interface lo (que é a interface de loopback), para que a comunicação inter-processos possa funcionar. É necessário, então, executar o seguinte comando:

# iptables -t filter -A INPUT -j ACCEPT -i lo


Antes ainda do tráfego ser liberado para o servidor Web, precisa-se fazer com que o firewall permita que os pacotes pertencentes às conexões já estabelecidas e os pacotes relacionados a essas conexões possam passar pelo firewall. Para isso, são necessários os seguintes comandos:

# iptables -t filter -A FORWARD -j ACCEPT -m state --stateESTABLISHED, RELATED# iptables -t filter -A INPUT -j ACCEPT -m state --stateESTABLISHED, RELATED


Agora que realmente será liberado o acesso à porta 80 do servidor Web, utilizando o comando:

# iptables -t filter -A FORWARD -j ACCEPT -m state NEW -p tcp \ -&hairsp;-dport http


Caso deseje liberar ainda mais um tipo de acesso, pode-se liberar o acesso à requisições[10] IDENT, utilizadas pelo protocolo de autenticação (auth), o qual pode ser utilizado por servidores SMTP e alguns servidores FTP. Para esse acesso ser liberado, basta executar o comando:

# iptables -t filter -A FORWARD -j ACCEPT -m state NEW -p tcp \-&hairsp;-dport auth


Agora, basta criar uma regra que irá rejeitar todos os pacotes que não casarem com as regras anteriores:

# iptables -t filter -A FORWARD -j REJECT


Após configurar o firewall, falta apenas configurar o mascaramento na interface de saída:

# iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0


Neste exemplo, está sendo configurado o mascaramento dos pacotes com destino ao servidor web. Todos os pacotes que vierem da interface ppp0 que tiverem com o protocolo tcp e forem destinados à porta 80 são destinados para a máquina interna:

# iptables -t nat -A PREROUTING -j DNAT -&hairsp;-to-dest 192.168.1.200 \-i ppp0 -p tcp -&hairsp;-dport 80


A configuração do firewall foi finalizada. Porém, lembre-se de que estas regras desaparecerão assim que a máquina for reinicializada. Para evitar que isso ocorra, deve-se criar um script que irá executar junto com a inicialização da máquina, garantindo que as regras estejam funcionando.

Crie no diretório /etc/init.d/ um arquivo chamado iptables com o seguinte conteúdo:

#! /bin/sh# description: Inicialização do iptables## chkconfig: 2345 80 30# processname: iptables# pidfile: /var/run/iptabless.pid. /etc/rc.d/init.d/functions. /etc/sysconfig/networkif [ ${NETWORKING} = "no" ]then exit 0ficase "$1" in start) gprintf "Iniciando o serviço de %s: " "IPtables" echo echo 1 > /proc/sys/net/ipv4/ip_forward /usr/sbin/iptables -t filter -P INPUT DROP /usr/sbin/iptables -t filter -A INPUT -j ACCEPT -i lo /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state \ -&hairsp;-state ESTABLISHED,RELATED /usr/sbin/iptables -t filter -A INPUT -j ACCEPT -m state \ -&hairsp;-state ESTABLISHED,RELATED /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state \ NEW -p tcp -&hairsp;-dport http /usr/sbin/iptables -t filter -A FORWARD -j ACCEPT -m state\ NEW -p tcp -&hairsp;-dport auth /usr/sbin/iptables -t filter -A FORWARD -j REJECT /usr/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 /usr/sbin/iptables -t nat -A PREROUTING -j DNAT \ -&hairsp;-to-dest 192.168.1.200 -i ppp0 -p tcp -&hairsp;-dport 80 ;; stop) gprintf "Parando o serviço de %s: " "IPtables" echo /usr/sbin/iptables -F ;; *) gprintf "Uso: iptables (start|stop)" echo ;;esacexit 0


Este script, além de inserir as regras necessárias para o firewall, carrega também os módulos do kernel necessários para este serviço.

Como você pode notar, esse script é muito semelhante ao utilizado anteriormente no Capítulo 6; a sugestão é unificar os dois scripts em um só para um melhor gerenciamento das regras utilizadas, considerando que, a única diferença nos dois scripts mencionados são as regras utilizadas.

 
Topo