Comentários sobre o livro "At Large"

Colaboração: Rubens Queiroz de Almeida

O tema de hoje é uma resenha do livro "At large" que me foi enviada por um colaborador que prefere permanecer anônimo. E segurança realmente é algo que precisamos nos preocupar e muito. A leitura destes livros é algo interessante porque nos fornece uma visão da maneira como pensam invasores de sistemas e também conhecimento para melhor nos prepararmos para este tipo de eventualidade.

---

A imagem de um cracker criada pela mídia nacional e internacional oscila entre o adolescente genio e o especialista high tech capazes de invadir sistemas utilizando truques e tecnicas avancadas, não? Quem não conhece Pengo, Phiber Optik, Mitnick, Poulsen, etc ? Pode não ser assim. Em "At Large" dois jornalistas narram a historia de Phantom Dialer, um rapaz com sérios problemas de saúde, possível retardamento mental e que durante o início da decada de 90 invadiu praticamente todas as redes que desejou. Alem das usuais candidatas naturais como a NASA, PhantomD passou em revista redes de empresas como Intel, Thinking Machines, Sun todas protegidas pelos mais modernos firewalls da epoca. Qual a tecnica empregada por ele? A tecnica da persistencia absoluta e infinita.

PhantomD era capaz de ficar 4, 6, 12 horas on line tentando adivinhar a senha de uma conta por tentativa e erro. Trivial? Sim, mas extremamente eficiente. E depois que ele obtinha acesso interativo a uma máquina de uma rede a chance dele não conseguir obter acesso root eram minimas. Que o diga o projeto Athena do MIT onde era desenvolvido o Kerberos, que o diga BBN, mantenedora, entao, do backbone norteamericano e onde PhantomD instalou nada mais, nada menos, que um sniffer. Ele fez tudo sozinho? não, PhantomD não tinha conhecimento tecnico adequado para a maioria dos seus ataques, o talento dele era varrer de forma obsessiva todas as possibilidades até obter acessor a uma rede e depois ele ia buscar auxilio junto a outros dois crackers: Grok e jsz.

A etica cracker baseia-se na troca de informacoes, não? Pois entao. Desde o lancamento do Solaris que Grok estava tendo dificuldades para adaptar seus "trojans" ao novo sistema da Sun. PhantomD não deixou por menos, para ajudar o amigo invadiu a Sun e roubou os fontes do Solaris para ele.

Uma frustração de PhantomD foi descobrir que os supercomputadores da NASA não rodavam o Cracker4 muito mais rapido que uma estação de trabalho. Foi preciso que jsz (sim, o mesmo jsz que auxiliava Mitnick) fizesse um port do Cracker4 para computadores paralelos. E la foi PhantomD, ironicamente, invadir a Intel para rodar o Cracker4 paralelo com o arquivo de senhas da concorrente Thinking Machines.

Quem não ouviu falar dos pacotes de seguranca desenvolvidos pela Texas A&M University? Adivinhe que trio de crackers "motivou" a sua criação.

Numa epoca como a atual onde seguranca transformou-se em um grande negocio, onde vende-se a ideia que existem pacotes/caixa-pretas que permitem a construção de firewalls inviolaveis a leitura de @large é extremamente necessaria. Ela mostra que o fator humano, do lado do cracker e do lado da rede atacada ainda é o ponto mais forte e mais fraco duma rede e que a suposta genialidade pode ser muito bem substituida pela persistencia obsessiva na exploração dos furos historicos em redes: senhas fracas, erros de configuração, usuarios que utilizam a mesma senha em todas as contas, administradores que não atualizam seus sistemas, etc. Leitura obrigatoria para administradores de redes

---

 At Large : The Strange Case of the World's Biggest Internet Invasion David H. Freedman, Charles C. Mann ISBN: 0684824647, Agosto de 1997 

---

Pode ser adquirido na www.amazon.com (US$16.80)

Fonte: http://www.dicas-l.com.br/print/19971103.html

Usando o Kismet

Colaboração: Carlos E. Morimoto

O Kismet é uma ferramenta poderosa, que pode ser usado tanto para checar a segurança de sua própria rede wireless, quanto para checar a presença de outras redes próximas e assim descobrir os canais que estão mais congestionados (configurando sua rede para usar um que esteja livre) ou até mesmo invadir redes. O Kismet em sí não impõe restrições ao que você pode fazer. Assim como qualquer outra ferramenta, ele pode ser usado de forma produtiva ou destrutiva, de acordo com a índole de quem usa.

A página do projeto é a: http://www.kismetwireless.net/.

A principal característica do Kismet é que ele é uma ferramenta passiva. Ao ser ativado, ele coloca a placa wireless em modo de monitoramento (rfmon) e passa a escutar todos os sinais que cheguem até sua antena. Mesmo pontos de acesso configurados para não divulgar o ESSID ou com a encriptação ativa são detectados.

Como ele não transmite pacotes, apenas escuta as transmissões, todo o processo é feito sem prejudicar as redes vizinhas e de forma praticamente indetectável. A principal limitação é que, enquanto está em modo de monitoramento, a placa não pode ser usada para outros fins. Para conectar-se a uma rede, você precisa primeiro parar a varredura.

Esta questão da detecção dos pontos de acesso com o ESSID desativado é interessante. Não é possível detectá-los diretamente, pois eles não respondem a pacotes de broadcast (por isso eles não são detectados por programas como o Netstumbler), mas o Kismet é capaz de detectá-los quando um cliente qualquer se associa a eles, pois o ESSID da rede é transmitido de forma não encriptada durante o processo de associação do cliente.

A partir daí, o Kismet passa a capturar todos os pacotes transmitidos. Caso a rede esteja encriptada, é possível descobrir a chave de encriptação usando o aircrack (que veremos a seguir), permitindo tanto escutar as conexões, quanto ingressar na rede.

Como o Kismet é uma das ferramentas mais usadas pelos crackers, é sempre interessante usá-lo para verificar a segurança da sua própria rede. Tente agir como algum vizinho obstinado agiria, capturando os pacotes ao longo de alguns dias. Verifique a distância de onde consegue pegar o sinal de sua rede e quais informações consegue descobrir. Depois, procure meios de reforçar a segurança da rede e anular o ataque.

Por ser uma ferramenta popular, ele está disponível na maioria as distribuições. Algumas, como o Knoppix (a partir da versão 3.7), já o trazem instalado por padrão.

Nas distribuições derivadas do Debian, você pode instalá-lo via apt-get:

 # apt-get install kismet 

 

Antes de ser usar, é preciso configurar o arquivo "/etc/kismet/kismet.conf", especificando a placa wireless e o driver usado por ela, substituindo a linha:

 source=none,none,addme 

 

Por algo como:

 source=madwifi_ag,ath0,atheros 

 

... onde o "madwifi_ag" é o driver usado pela placa (que você pode verificar usando o comando lspci). Na documentação do Kismet o driver é chamado de "capture source", pois é a partir dele que o Kismet obtém os pacotes recebidos.

o "ath0" é a interface (que você vê através do comando ifconfig) e o "atheros" é um apelido para a placa (que você escolhe), com o qual ela será identificada dentro da tela de varredura.

Isto é necessário, pois o Kismet precisa de acesso de baixo nível ao hardware. Isto faz com que a compatibilidade esteja longe de ser perfeita. Diversas placas não funcionam em conjunto com o Kismet, com destaque para as placas que não possuem drivers nativos e precisam ser configurados através do ndiswrapper. Se você pretende usar o Kismet, o ideal é pesquisar antes de comprar a placa. Naturalmente, para que possa ser usada no Kismet, a placa precisa ter sido detectada pelo sistema, com a ativação dos módulos de Kernel necessários. Por isso, prefira sempre usar uma distribuição recente, que traga um conjunto atualizado de drivers. O Kurumin e o Kanotix estão entre os melhores neste caso, pois trazem muitos drivers que não vem pré instalados em muitas distribuições.

Você pode ver uma lista detalhada dos drivers de placas wireless disponíveis e como instalar manualmente cada um deles no meu livro Linux Ferramentas Técnicas.

Veja uma pequena lista dos drivers e placas suportados no Kismet 2006-04-R1:

• acx100: O chipset ACX100 foi utilizado em placas de diversos fabricantes, entre eles a DLink, sendo depois substituído pelo ACX111. O ACX100 original é bem suportado pelo Kismet, o problema é que ele trabalha a 11 megabits, de forma que não é possível testar redes 802.11g.

   

• admtek: O ADM8211 é um chipset de baixo custo, encontrado em muitas placas baratas. Ele é suportado no Kismet, mas possui alguns problemas. O principal é que ele envia pacotes de broadcast quando em modo monitor, fazendo com que sua varredura seja detectável em toda a área de alcance do sinal. Qualquer administrador esperto vai perceber que você está capturando pacotes.

   

• bcm43xx: As placas com chipset Broadcom podiam até recentemente ser usadas apenas no ndiswrapper. Recentemente, surgiu um driver nativo (http://bcm43xx.berlios.de) que passou a ser suportado no Kismet. O driver vem incluído por padrão a partir do Kernel 2.6.17, mas a compatibilidade no Kismet ainda está em estágio experimental.

   

• ipw2100, ipw2200, ipw2915 e ipw3945: Estes são os drivers para as placas Intel, encontrados nos notebooks Intel Centrino. O Kismet suporta toda a turma, mas você precisa indicar o driver correto para a sua placa entre os quatro.

O ipw2000 é o chipset mais antigo, que opera a 11 megabits; o ipw2200 é a segunda versão, que suporta tanto o 8011.b, quanto o 802.11g; o ipw2915 é quase idêntico ao ipw2200, mas suporta também o 802.11a, enquanto o ipw3945 é uma versão atualizada, que é encontrada nos notebooks com processadores Core Solo e Core Duo.

madwifi_a, madwifi_b, madwifi_g, madwifi_ab e madwifi_ag: Estes drivers representam diferentes modos de operação suportados pelo driver madwifi (http://sourceforge.net/projects/madwifi/), usado nas placas com chipset Atheros. Suportam tanto o driver madwifi antigo, quanto o madwifi-ng.

Usando os drivers madwifi_a, madwifi_b ou madwifi_g, a placa captura pacotes apenas dentro do padrão selecionado (o madwifi_a captura apenas pacotes de redes 802.11a, e assim por diante). O madwifi_g é o mais usado, pois captura simultaneamente os pacotes de redes 802.11b e 802.11g. O madwifi_ag, por sua vez, chaveia entre os modos "a" e "g", permitido capturar pacotes de redes que operam em qualquer um dos três padrões, mas num ritmo mais lento, devido ao chaveamento.

rt2400 e rt2500: Estes dois drivers dão suporte às placas com chipset Ralink, outro exemplo de chipset de baixo custo que está se tornando bastante comum. Apesar de não serem exatamente "placas de alta qualidade", as Ralink possuem um bom suporte no Linux, graças em parte aos esforços do próprio fabricante, que abriu as especificações e fornece placas de teste para os desenvolvedores. Isto contrasta com a atitude hostil de alguns fabricantes, como a Broadcom e a Texas (que fabrica os chipsets ACX).

rt8180: Este é o driver que oferece suporte às placas Realtek 8180. Muita gente usa estas placas em conjunto com o ndiswrapper, mas elas possuem um driver nativo, disponível no http://rtl8180-sa2400.sourceforge.net/. Naturalmente, o Kismet só funciona caso seja usado o driver nativo.

prism54g: Este driver dá suporte às placas com o chipset Prism54, encontradas tanto em versão PCI ou PCMCIA, quanto em versão USB. Estas placas são caras e por isso relativamente incomuns no Brasil, mas são muito procuradas entre os grupos que fazem wardriving, pois as placas PCMCIA são geralmente de boa qualidade e quase sempre possuem conectores para antenas externas, um pré-requisito para usar uma antena de alto ganho e assim conseguir detectar redes distantes.

orinoco: Os drivers para as placas com chipset Orinoco (como as antigas Orinoco Gold e Orinoco Silver) precisam de um conjunto de patches para funcionar em conjunto com o Kismet, por isso acabam não sendo placas recomendáveis. Você pode ver detalhes sobre a instalação dos patches no http://www.kismetwireless.net/HOWTO-26_Orinoco_Rfmon.txt.

Depois de definir o driver, a interface e o nome no "/etc/kismet/kismet.conf", você pode abrir o Kismet chamando-o como root:

 # kismet 

 

Inicialmente, o Kismet mostra as redes sem uma ordem definida, atualizando a lista conforma vai descobrindo novas informações. Pressione a tecla "s" para abrir o menu de organização, onde você pode definir a forma como a lista é organizada, de acordo com a qualidade do canal, volume de dados capturados, nome, etc. Uma opção comum (dentro do menu sort) é a "c", que organiza a lista baseado no canal usado por cada rede.

Por padrão, o Kismet chaveia entre todos os canais, tentando detectar todas as redes disponíveis. Neste modo, ele captura apenas uma pequena parte do tráfego de cada rede, assim como você só assiste parte de cada programa ao ficar zapiando entre vários canais da TV.

Selecione a rede que quer testar usando as setas e pressione "shift + L" (L maiúsculo) para travá-lo no canal da rede especificada. A partir daí ele passa a concentrar a atenção numa única rede, capturando todos os pacotes transmitidos:

Você pode também ver informações detalhadas sobre cada rede selecionando-a na lista e pressionando enter. Pressione "q" para sair do menu de detalhes e voltar à tela principal.

Outro recurso interessante é que o Kismet avisa sobre "clientes suspeitos", micros que enviam pacotes de conexão para os pontos de acesso, mas nunca se conectam a nenhuma rede, indício de que provavelmente são pessoas fazendo wardriving ou tentando invadir redes. Este é o comportamento de programas como o Netstumbler (do Windows). Micros rodando o Kismet não disparam este alerta, pois fazem o scan de forma passiva:

 ALERT: Suspicious client 00:12:F0:99:71:D1 - probing networks but never participating. 

 

O Kismet gera um dump contendo todos os pacotes capturados, que vai por padrão para a pasta "/var/log/kismet/". A idéia é que você possa examinar o tráfego capturado posteriormente usando o Ethereal. O problema é que, ao sniffar uma rede movimentada, o dump pode se transformar rapidamente num arquivo com vários GB, exibindo que você reserve bastante espaço no HD.

Um dos maiores perigos numa rede wireless é que qualquer pessoa pode capturar o tráfego da sua rede e depois examiná-lo calmamente em busca de senhas e outros dados confidenciais transmitidos de forma não encriptada. O uso do WEP ou outro sistema de encriptação minimiza este risco, pois antes de chegar aos dados, é necessário quebrar a encriptação.

Evite usar chaves WEP de 64 bits, pois ele pode ser quebrado via força bruta caso seja possível capturar uma quantidade razoável de pacotes da rede. As chaves de 128 bits são um pouco mais seguras, embora também estejam longe de ser inquebráveis. Em termos se segurança, o WPA está à frente, mas usá-lo traz problemas de compatibilidade com algumas placas e drivers.

Sempre que possível, use o SSH, SSL ou outro sistema de encriptação na hora de acessar outras máquinas da rede ou baixar seus e-mails.

No Guia "Acesso Remoto: SSH, FreeNX e VNC", vemos como é é possível criar um túnel seguro entre seu micro e o gateway da rede, usando o SSH, permitindo assim encriptar todo o tráfego. Ele está disponível no:

---

Gostou da dica? Venha fazer um curso com o autor:

Curso: Redes e servidores Linux

Com Carlos E. Morimoto

Em São Paulo, de 29/05 a 03/06 (intensivo, com aulas à tarde)

Este é um curso sobre a configuração de servidores Linux. Nele você aprende a configurar cada serviço diretamente nos arquivos de configuração ou utilizando ferramentas genéricas, sem se prender a uma única distribuição. Os exemplos dados durante o curso usam como base o Debian e Fedora, com dicas de peculiaridades do Mandriva, Slackware, Kurumin e Ubuntu.

Este é um curso intensivo, onde você passa menos tempo vendo teoria e opções pouco usadas e mais tempo aprendendo a resolver problemas do dia a dia. O formato das aulas permite que sejam abordados uma grande quantidade de temas numa única semana, oferecendo uma visão global dos recursos disponíveis e onde eles podem ser aplicados. Ao invés de fazer um curso sobre o Squid, outro sobre o Samba, outro sobre o Apache, etc., você aprende muitas coisas de uma única vez, economizando tempo e dinheiro.

Nesta turma do dia 29/05, combinou do curso de redes e o curso para iniciantes serem ministrados na mesma semana: o curso para iniciantes de segunda a sexta, das 8:00 às 11:00, e o curso de redes das 12:30 às 18:00. Fazendo o curso de redes, você tem acesso também às aulas para iniciantes e pode fazer os dois cursos simultaneamente (pagando apenas um), e assim aproveitar para tirar todas as dúvidas.

Veja mais detalhes sobre a programação de cursos, temas abordados, preços e formas de pagamento no:

http://guiadohardware.net/cursos/

Todas as aulas do curso de redes são ministradas pelo próprio Carlos Morimoto, o que garante o nível do curso. Nada de aulas inaugurais e mutretas do gênero :)

Fonte: http://www.dicas-l.com.br/print/20060509.html

fortune-mod - Information Security

Colaboração: Jairo Willian Pereira

Depois de uma pesquisa na rede atras de modulos fortune que focassem Information Security (iSec), para nosso descontentamento e alegria, descobrimos que ainda existia uma lacuna na area de seguranca para os atuais modulos fortune disponiveis.

fortune-mod-isec nasceu de uma conversa informal, da necessidade entre amigos e estusiatas num curso de Seguranca da Informacao em receber "informacao decente" de forma fragmentada e diaria.

O projeto visa a publicacao de tiras/dicas voltadas ao mundo da Seguranca de Informacao. Essas "tiras" foram compiladas a partir de informacoes coletadas na Internet, livros, normas, padroes e a experiencia pessoal de seus colaboradores.

Objetiva ajudar professionais de seguranca, CSOs (Chief Security Officers), entusiastas, auditores & interessados em conhecer um compreensivel conjunto de controles & boas-praticas voltadas a seguranca da informacao com base em normas internacionais.

O lancamento tenta angariar novos colaboradores, sendo que fortune-mod-isec poderá cobrir num futuro:

• Politicas de Seguranca;
• Sistemas de Controle de Acesso;
• Gerenciamento de Operações & Computacao;
• Desenvolvimento Seguro de Sistemas & Manutencao;
• Segurança Fisica & Ambiental;
• Conformidade;
• Seguranca Pessoal;
• Segurança Organizacional;
• Controle e Classificacao de Ativos;
• Plano de Continuidade de Negocios (BCP & BIA);

O projeto foi disponibilizado a comunidade para atrair novos colaboradores. Convidamos aos assinantes deste veiculo de comunicacao, que conhecam e colaborem atraves do link do nosso projeto:

http://sourceforge.net/projects/fortune-mod-sec/

Estaremos em breve publicando um canal de contato, e disponibilizando ferramentas para que possam juntos facilitar o intercambio entre os diversos colaboradores. Up the Security Guys! :)

 $ fortune isec Optimum operational system is that one that you know. Hacking & Hardening your system! 

---

Rede comunitária de pesquisa ganha nova estrutura de banda larga

Parceria em torno da Rede Comunitária de Educação e Pesquisa (Redecomep) prevê instalação de nova conexão de banda larga em fibra óptica

 

Por COMPUTERWORLD*

26 de janeiro de 2007 - 18h05

O Instituto Nacional de Tecnologia da Informação (ITI) assinou protocolo de intenções com a Rede Nacional de Ensino e Pesquisa (RNP), com a Universidade de Brasília (UnB) e outras 13 entidades, com o objetivo de instalar e manter a Rede Comunitária de Educação e Pesquisa (Redecomep) em Brasília.

Segundo coordenador do Centro de Difusão de Tecnologia e Conhecimento (CDTC), Djalma Valois, uma das conseqüências positivas do protocolo é que o Instituto contará, a partir de abril, com nova conexão de banda larga em fibra óptica. Esse tipo de conexão é oferecida aos integrantes da Rede. Isso significa que existirá mais de um gigabyte de link para a prestação do serviço de educação a distância, afirmou Valois.

As Redes Comunitárias (Redecomeps) estão espalhadas em 26 cidades do País. O projeto foi lançado em dezembro de 2004 para criar uma infra-estrutura nacional óptica de alta capacidade para comunicação, computação e conhecimento.

A meta é ativar conexões multigigabytes entre todos os estados do País até 2007. A nova rede trará mais integração e tornará possível um atendimento, em maior escala e melhor qualidade, a pesquisa de ponta em várias áreas.

Fonte: http://www.dicas-l.com.br/print/20070216.html

Configuração honeyd

Colaboração: Pedro Augusto

No artigo "Introdução aos honeypots" (disponível aqui: http://www.pedroaugusto.eti.br/?q=node/7), expliquei uma boa quantidade de teoria em relação aos honeypots (como aplicação, tipos, história...) porém sem focar em qualquer ferramenta para implementação do honeypot. Aqui, irei focar na implantação de um honeypot utilizando OpenBSD e HoneyD. Vamos criar alguns hosts Windows e Linux.

1. O Honeyd

O Honeyd é um daemon desenvolvido por Niels Provos para ser utilizado tanto em Windows quanto *nix.

Ele funciona criando "hosts virtuais" os quais podem ser configurados para emular vários serviços diferentes como e-mail, SSH, Telnet, DNS, backdoors como o MyDoom, etc. Além de emular serviços, o Honeyd também pode enganar scanners de rede fingindo ser outro sistema operacional. Por exemplo, você consegue emular um roteador Cisco, um Windows XP, Windows 2000, Windows Server 2003, Cisco IOS, OS/400, entre vários outros. Ele consegue isso utilizando o banco de dados de fingerprints do NMap (http://www.insecure.org/nmap). Para que você possa emular vários sistemas operacionais com maior veracidade, o Honeyd também permite que você utilize vários endereços IP e associe cada "host virtual" com um endereço IP diferente.

A melhor característica do Honeyd é ser software livre licensiado sob a GPL, ou seja, use à vontade para qualquer finalidade. Ele também é utilizado bastante pelo Honeynet.BR Project (entidade brasileira de pesquisa de honeypots).

Se você quiser conhecer mais sobre o projeto, visite o website oficial http://www.honeyd.org. Aproveite e dê uma ajuda ao desenvolvedor!

2. Instalação do Honeyd

A instalação do Honeyd é bem simples. Se você estiver usando algum BSD, utilize o ports para instalar e poupe um pouco de tempo não precisando resolver as dependências na mão.

Se você vai compilar o Honeyd, o procedimento também não é muito complicado, mas é um pouco demorado. Faça o seguinte:

• Acesse o site do Honeyd e baixe os sources mais recentes: http://www.citi.umich.edu/u/provos/honeyd/honeyd-1.5b.tar.gz
• O Honeyd precisa de algumas bibliotecas para ser compilado com sucesso. Você precisa do Python, do Perl, da libevent (http://www.monkey.org/~provos/libevent/), da libdnet (http://libdnet.sourceforge.net/) e da libpcap (http://www.tcpdump.org/). A instalação dessas dependências é extremamente simples (em quase todas se resumindo a ./configure, make, make install), por isso não vou entrar em detalhes aqui.
• Instale o arpd (http://www.citi.umich.edu/u/provos/honeyd/arpd-0.2.tar.gz)
• Agora já é possível compilar o Honeyd.

3. Configuração

O ambiente que eu usei para fazer a configuração do meu honeypot foi usando um OpenBSD com o Honeyd instalado através dos ports, assim a localização dos arquivos mostrada aqui é a localização padrão no OpenBSD. Se você estiver usando algum outro sistema, utilize o find ou o locate para procurar pelo nome dos diretórios mostrados aqui.

O arquivo de configuração principal é o /etc/honeyd.conf. Nele você irá definir as máquinas que serão emuladas, quais serão os IP's, os serviços, etc. O arquivo nmap.prints tem os fingerprints de todos os sistemas operacionais que podem ser emulados pelo Honeyd (sempre mantenha esse arquivo atualizado com a última versão disponibilizada pelo time do NMap para garantir que seu honeypot continuará enganando o NMap e outros scanners). No OpenBSD, o nmap.prints fica localizado em /usr/local/share/honeyd/nmap.prints. O Honeyd usa scripts (Perl e Shell script) para emular os serviços que você quer no seu honeypot. Esses scripts ficam localizados em /usr/local/share/honeyd/scripts. Você também pode desenvolver ou baixar esses scripts de outros sites na Internet, um exemplo é o site http://www.honeyd.org/contrib.php. Existem também várias ferramentas muito úteis para o Honeyd, como essas: http://www.honeyd.org/tools.php.

Agora que você já tem um conhecimento básico para "se virar" utilizando o Honeyd, vamos partir para a configuração.

Aqui, vou te mostrar como criar uma máquina Windows XP Professional SP1 e um Linux 2.4.16. Com essas máquinas você já vai conseguir capturar coisas interessantes.

Abra o arquivo /etc/honeyd.conf para criarmos os hosts. Ele já vem com alguns modelos de host, comente todas as linhas desses exemplos mas não comente o profile "default".

Vamos criar uma máquina Windows XP Professional SP1 que estará infectada com o backdoor MyDoom. Para isso, adicione as linhas abaixo no seu honeyd.conf:

 create windowsxp-mydoom set windowsxp-mydoom personality "Microsoft Windows XP Professional SP1" set windowsxp-mydoom uptime 2314219 set windowsxp-mydoom default tcp action reset set windowsxp-mydoom default udp action reset set windowsxp-mydoom default icmp action open set windowsxp-mydoom uid 32767 gid 32767 add windowsxp-mydoom tcp port 1080 "perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log" add windowsxp-mydoom tcp port 3127 "perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log" add windowsxp-mydoom tcp port 3128 "perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log" add windowsxp-mydoom tcp port 10080 "perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log" bind 192.168.0.1 

Pronto, a máquina já está criada e associada ao IP 192.168.0.1. Segue uma explicação dos parâmetros:

• create windowsxp-mydoom: define que criaremos o host windowsxp-mydoom
• set windowsxp-mydoom personality "Microsoft Windows XP Professional SP1": define a personalidade a ser usada para esse host
• set windowsxp-mydoom uptime 2314219: define qual vai ser o uptime da máquina
• set windowsxp-mydoom default tcp action reset & set windowsxp-mydoom default udp action reset & set windowsxp-mydoom default icmp action open: definem a ação padrão das portas TCP, UDP e ICMP.
• set windowsxp-mydoom uid 32767 gid 32767: define qual será o UID e o GID a ser usado para esse script
• add windowsxp-mydoom tcp port 1080 "scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log": é aqui que definimos que o Honeyd deverá simular o MyDoom na porta 1080 (o mesmo acontece nas outras 3 linhas). 1080 é a porta que vai escutar por tráfego, "scripts/mydoom.pl..." define que script ficará sendo executado naquela porta. No caso desse script (mydoom.pl), é interessante que se defina o log que ele vai gerar com o tráfego que recebe. Para isso utilizamos a opção -l e o caminho para o log (o caminho obviamente já deve existir).
• bind 192.168.0.1: define que esta máquina atenderá as requisições de IP que forem destinadas a 192.168.0.1

Como você pode ver, é extremamente fácil definir os hosts no Honeyd. Como outro exeplo, vou criar um servidor de email Linux utilizando kernel 2.4:

 create linux set linux personality "Linux 2.4.16 - 2.4.18" set linux default tcp action reset set linux default udp action reset set linux uptime 3284460 add linux tcp port 110 "sh scripts/pop3.sh" add linux tcp port 25 "sh scripts/smtp.sh" add linux tcp port 22 "sh scripts/test.sh $ipsrc $dport" bind 192.168.0.2 linux 

No geral, esta configuração é muito parecida com a máquina Windows. O que difere bastante são os scripts utilizados para emular serviços:

• pop3.sh: emula um serviço POP3 na porta 110
• smtp.sh: emula um serviço de SMTP na porta 25
• teste.sh $ipsrc $dport: emula o SSH, logando o IP de origem (de quem se conectou ao script) e em qual porta.

Para qualquer outra máquina que você quiser criar, é só seguir essa mesma lógica que demonstrei nos exemplos. Só preste bastante atenção para não configurar por engano o IIS numa máquina Linux, isso faria o atacante desconfiar (faria qualquer um desconfiar :)). Para você verificar quais sistemas operacionais você vai poder emular usando o Honeyd, é só executar o seguinte comando:

 # grep "^Fingerprint" nmap.prints | less 

 

A lista é bem grande, por isso fica melhor para você escolher se redirecionar a saída desse comando para um arquivo.

4. Configurando o firewall

A configuração do firewall no honeypot é importante pois se você não configurar sua máquina para aceitar conexões para os IP's que definiu para os hosts virtuais (lembre-se que esses endereços devem ser reais na sua rede e não podem ser usados por nenhuma outra máquina), seu Honeyd não funcionará.

Garantir a segurança do honeypot é muito importante, por isso preste bastante atenção no que está fazendo aqui.

5. Inicializando o Honeyd

Antes de inicializar o Honeyd e partir para a ação, tenha certeza de que você vai ter algum tráfego sendo redirecionado para o seu honeypot. Para fazer isso, você pode usar o arpd para o seu honeypot responder pelos endereços desocupados da sua rede (o que pode fazer um servidor DHCP travar). Do modo que mostrei na configuração acima, só será logado o tráfego que realmente for direcionado para o honeypot.

Para você utilizar o ARPd, você só precisa especificar a rede que ele vai ouvir. Quando ele ouvir alguma requisição ARP passando pela rede, ele irá checar se alguém tem o IP, se ninguém tiver, ele responderá como se fosse o IP requisitado. Para iniciar o ARPd:

 # arpd < rede a ser monitorada > 

 

Por exemplo,

 # arpd 192.168.0.0/24 

 

Quando você usa o ARPd, o profile de host que irá responder é o "default" (lembre-se, para usar o ARPd você não pode usar a cláusula "bind" para o host que você criar no honeyd.conf). Esse profile já vem criado no honeyd.conf quando você instala o Honeyd. Se você criar outras profiles e definir um IP para elas utilizando a cláusula "bind" no honeyd.conf, o Honeyd irá responder com o profile default para todos os IP's da rede menos para o IP que você configurou para o host utilizando o "bind". Simples não?

Com tudo o que foi explicado e resolvido, podemos iniciar o Honeyd:

 # honeyd -p nmap.prints -f /etc/honeyd.conf 192.168.0.0/24 

 

Assim, os seus hosts virtuais que têm IP definido, responderão normalmente e o profile default que não tem um IP definido, responderá por todos os endereços que não são utilizados na sua rede.

6. Ferramentas complementares

O Honeyd tem algumas ferramentas complementares que aumentam a funcionalidade dele. Um bom exemplo desse tipo de ferramenta é o Honeydsum.

Ele é um analisador de Logs desenvolvido pelo time brasileiro da Honeynet-Alliance. Com ele você pode filtrar os logs do Honeyd procurando por endereços IP, portas, protocolos ou redes além de poder relacionar os eventos logados em vários honeypots diferentes. Veja mais aqui: http://www.honeynet.org.br/tools/.

O Honeycomb também é outra ferramenta extremamente útil. Com ela você consegue gerar assinaturas para software de detecção de intrusão como o Snort. É especialmente útil para criar assinaturas de worms. Foi este software que criou as assinaturas para o Slammer e Code Red. Você pode encontrá-lo neste link http://www.cl.cam.ac.uk/~cpk25/honeycomb/.

Dois sites com ferramentas para o Honeyd são http://www.honeyd.org/tools.php e http://www.honeynet.org.br/tools/. Com certeza você encontrará mais ferramentas em outros sites da Internet, é só procurar no Google.

7. Conclusão

O Honeyd não é uma ferramenta complexa, mas deve ser implantada na rede da forma correta para que consiga ajudar de forma efetiva o administrador a monitorar tráfego malicioso e tomar providências. Claro que o Honeyd sozinho não vai ser de grande ajuda. Você precisa utilizar outras ferramentas para complementar o trabalho dele. Um exemplo é o Snort, um detector de intrusos. Utilizando os 2 em conjunto, você irá ter uma solução para monitoramento de tráfego extremamente eficiente sem gastar quase nada.

Se você tiver alguma sugestão ou dúvida em relação a este artigo, mande um email para <pedro (a) pedroaugusto eti br>.

Fonte: http://www.dicas-l.com.br/print/20070322.html

Roteamento avançado - Linux - utilizando IPROUTE e IPTABLES - Load Balance

Colaboração: Fabricio Ferreira - GUZZY

Certo tempo atrás, escrevi um script usando IPROUTE2 e IPTABLES que desenvolvi na ocasião, já que havia a necessidade de utilizar 2 links de Internet distintos. Desta vez, reescrevi com muito mais detalhes mostrando exatamente como funciona cada passo.

Lembrando que, este script foi desenvolvido no SLACKWARE, mas acredito que funcione em qualquer outra distribuição LINUX com Kernel 2.4.x e superiores, com algumas poucas modificações.

Quanto aos links, vamos chamá-los de LINK1 e LINK2...

Imagine que você queira que determinado protocolo use o LINK1 e outro protocolo use o LINK2.

Um exemplo fácil seria dizer que mensagens de E-mail SMTP e POP (portas 110 e 25) utilizam o LINK1, enquanto o tráfego de internet (portas 80, 21, 53, 443...) utiliza o LINK2. Isto permitiria que usuários fizessem downloads pesados sem comprometer o tráfego de mensagens, ou ainda, enviar e receber mensagens de E-mail grandes sem interferir na velocidade dos usuários que navegam na Internet.

Um outro exemplo para quem tem Vlans em suas redes seria dizer que a REDE 192.160.0.X utiliza o Link1, enquanto a REDE 192.170.0.X utiliza o LINK2.

Basicamente, o processo funciona marcando pacotes que entram e saem do FIREWALL onde o script será implementado com o Comando IPTABLES usando Mark, um artifício que faz com que o Firewall monte uma tabela dinâmica de todos os pacotes que passam por ele. Imagine que você tenha um Firewall com 4 Interfaces, assim vamos chamá-las de: ETH0, ETH1, ETH2 e ETH3, onde ETH0 está conectada à sua LAN interna, a ETH1 conectada em uma DMZ, e as interfaces ETH3 e ETH4 conectadas a 2 Links distintos.

Se um pacote entrou pela interface ETH0 e saiu pela interface ETH3, é necessário que ele retorne para o mesmo lugar de onde veio. Eis o motivo de marcar os pacotes; caso contrário, eles se utilizarão do DEFAULT GATEWAY do Firewall, que pode não ser o mesmo que você deseja.

Entendendo isto, podemos seguir adiante com nosso script.

Abaixo descrevo detalhadamente como fazer cada configuração no Script para que você tenha sucesso na implementação.

Entendam que os IP´s aqui utilizados são fictícios, bem como seus Defaut Gateways. Você deverá trocá-los pelos IP´S da sua rede conforme a necessidade!

Eis um exemplo de um script pronto em um Firewall com 3 Interfaces apenas.

A primeira - ETH0, é a interface conectada à rede interna. A Interface ETH1 é a interface ligada ao LINK1, e por último, a interface ETH2, ligada ao LINK2.

Vejamos:

 ############################################################################## # Nesta parte denominamos variáveis para as interfaces como segue. # Denominamos que o nome LAN seja referente à Interface ETH0 que no nosso # script é a da rede interna. Verifique no seu Firewall qual é a interface # correta. IF_LAN='eth0' # Aqui denominamos as variáveis dos LINKS 1 e 2, e os chamamos de LINK1 e LINK2 # É claro que você poderá chamá-los do que quiser. Exemplo: ADSL1 e ADSL2, # mas não esqueça de alterar as variáveis no restante do script. IF_LINK1='eth1' IF_LINK2='eth2' # Aqui colocamos os Gateways dos Links de Internet. # Geralmente, os Default Gateways dos Links são os IP´S dos roteadores de # Internet. GW_LINK1='200.70.0.1' GW_LINK2='200.80.0.1' # Nesta parte, utilizamos o comando IPTABLES para mascarar os IP s, ou seja, # fazemos um NAT (Network Address Translation) para que os pacotes que venham da # Interface ETH0 com IP s da rede interna, ou mesmo pacotes gerados dentro do # próprio Firewall, possam sair para a Internet com endereços trocados, usando # os IP s das interfaces ligadas aos Links de Internet. # O MASQUERADE ao final do comando faz exatamente isto. # Caso contrário, utilizaria ACCEPT, mas aí os pacotes sairiam para a Internet # com IP s da rede interna e jamais retornariam ao Firewall. iptables -t nat -A POSTROUTING -o $IF_LINK1 -j MASQUERADE iptables -t nat -A POSTROUTING -o $IF_LINK2 -j MASQUERADE # Aqui começamos a marcar os pacotes diferenciando-os pela porta utilizada. # Observe que escolhemos os pacotes com destino às portas 80 (HTTP) 443 (HTTPS) # 25 (SMTP) 110 (POP) # Todo pacote que passar pelo Firewall com estas particularidades receberão # uma marca , uma espécie de carimbo. Pacotes destinados à porta 80 # recebem carimbo de número 2, pacotes com destino à porta 25 # recebem carimbo número 3. # Desta forma, podemos diferenciá-los para que mais à frente no script tenhamos # controle do que saiu/entrou e por onde saiu/entrou. iptables -t mangle -A PREROUTING -i $IF_LAN -p tcp --dport 80 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -i $IF_LAN -p tcp --dport 443 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -i $IF_LAN -p tcp --dport 25 -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -i $IF_LAN -p tcp --dport 110 -j MARK --set-mark 3 # A diferença entre o PREROUTING e o OUTPUT é que, PREROUTING abrange os # pacotes que foram originados fora do FIREWALL, por exemplo Interface ETH0 # ($IF_LAN), enquanto OUTPUT são os pacotes originados no Firewall, ou seja, na # própria console. iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 2 iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 2 iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 3 iptables -t mangle -A OUTPUT -p tcp --dport 110 -j MARK --set-mark 3 # Aqui montamos as tabelas dinâmicas a partir das marcas (carimbos) que fizemos # lá em cima no nosso script. # Pacotes que foram marcados com 2 vão para a tabela table 20 e os marcados # com 3, vão para a tabela table 21 , com a mesma prioridade. Perceba o PRIO 20 # após os comandos. ip rule add fwmark 2 table 20 prio 20 ip rule add fwmark 3 table 21 prio 20 # se quisermos condicionar esta marcação de outra forma, podemos utilizar o # comando das seguintes formas: # Este condiciona que todos os pacotes que vierem da rede 192.160.0.0 vão para # a tabela 20. # O comando está comentado. Caso queira utilizá-lo, apenas retire o sinal de "#" # da frente. # ip rule add from 192.160.0.0/24 table 20 # Este outro condiciona os pacotes da rede 192.170.0.0 a irem para a tabela 21 # O comando está comentado. Caso queira utilizá-lo, apenas retire o sinal de # "#" da frente do comando. # ip rule add from 192.170.0.0/24 table 21 # Agora sim daremos rumo aos pacotes que foram marcados e cadastrados na tabela # dinâmica. # Veja que os pacotes que foram enviados para a tabela 20 têm como DEFAULT # GATEWAY o LINK1. Sendo assim, os pacotes serão enviados para o LINK1 na # Interface ETH1 com o IP 200.70.0.1. # Já os pacotes da tabela 21 serão enviados para o LINK2 na Interface ETH1, com # o IP 200.80.0.1 ip route add default via $GW_LINK1 dev $IF_LINK1 table 20 ip route add default via $GW_LINK2 dev $IF_LINK2 table 21 # Este último comando limpa a tabela, caso ela já tenha sido utilizada # anteriormente, ou apenas para termos certeza de que quando você resetar as # regras todas, o Firewall não guarde nenhum tipo de informação na # memória (cache). Daí o nome FLUSH CACHE. ip route flush cache 

Você pode utilizar parte do script, se necessário. Por exemplo, se quiser apenas rotear pacotes pela origem, utilize:

 ip rule add from 192.160.0.0/24 table 20 

 

ou

 ip rule add from 192.160.0.0/24 table 21 

 

Conforme o Link que deseja utilizar. Onde 192.160.0.0/24 é a origem. Neste exemplo, a rede em questão tem a máscara 255.255.255.0 (/24)

Desta forma, não há necessidade de marcar pacotes e você poderá deletar as linhas do script.

 Fabrício Ferreira GUZZY Especialista em Segurança Digital MCP Microsoft Certified Professional Linux Specialist 

Fonte: http://www.dicas-l.com.br/print/20070327.html

Dicas sobre Procedimentos Básicos em Redes

Colaboração: Renato Rudnicki

Muitas vezes ao trocarmos de empresa, pegamos redes onde não há nenhuma documentação a respeito, e as vezes, nem mesmo há uma equipe real para se dedicar a administração da rede e usuários. Quando já temos alguma experiência no assunto, até que não é um problema tão grave. Abaixo, descrevo alguns procedimentos básicos, que considero importantes para serem avaliados ao entrar em uma nova empresa, como responsável pela rede.

Procedimentos Básicos em Redes

1. O que ja está instalado, está funcionando perfeitamente? Muitas vezes, há No-Breakers instalados, mas quando ocorre uma queda de energia eles não "seguram" como deveriam. Outro exemplo, é ter um antivírus instalado no computador, mas ele não estar atualizado.

    

2. Redução de Custos Há algum procedimento que está gerando muitos gastos (backup, troca de peças)? Tem alguma maneira de reduzir esses custos, ou melhor ainda, melhorar a produtividade, reduzindo o custo ?

    

3. Padronização e Parcerias Os softwares instalados seguem um padrão (ex: 3 tipos de antivírus diferentes). Caso aconteça de comprar um hardware, tem alguma empresa que tem parceria ou até mesmo exclusividade, ou que já se sabe onde comprar ? Isto pode ajudar na redução de custos, e melhor confiabilidade no equipamento e no suporte.

    

4. Melhorar atendimento a usuários Quanto tempo esta se está levando para para atender chamadas de usuários. Está se conseguindo resolver os problemas ? São anotadas dúvidas, erros, sugestões e chamadas ? Você se imaginando como usuário, se considera satisfeito com o suporte que receberia de sua equipe ?

    

5. Documentação Há documentação descrevendo que softwares devem ser instalados em rede, erros documentados, quais os padrões e configurações de softwares, computadores, Patch Panel, configurações de roteadores e servidores?

    

6. Softwares Há softwares piratas na empresa ? há possibilidade de homologar. Existem softwares livres compatíveis ?

    

7. Backups São feitos backups ? De quanto em quanto tempo ? Os backups são eficientes e armazenados ? O local onde são armazenados os backups são confiáveis ?

    

8. Hardware Existe hardware de backup ? O que fazer se algum computador ou switch pifar ? È preciso fazer um upgrade no hardware da empresa ?

    

9. Repositórios Existe um repositório de dados e softwares ? Quando se precisa instalar algum software, sabe-se onde buscá-lo, ou tem procurar em CD's e pela rede ? Se um computador pifar, os usuários tem seus dados gravados na rede ? O espaço em rede é suficiente ?

Fonte: http://www.dicas-l.com.br/print/20061120.html

O que é o ICOX?

Colaboração: Carlos Nepomuceno

É um software livre para gerenciar comunidades virtuais, que pretende ajudar os profissionais de informação, comunicação e conhecimento na implantação de projetos. Visa, portanto, a troca de experiências de pessoas, permitindo, assim, o desenvolvimento de uma inteligência coletiva capaz de potencializar as novas ferramentas interativas da sociedade do conhecimento.

Quem pode usá-lo?

Qualquer pessoa física ou jurídica, privada ou pública, desde que baixe gratuitamente o software. Os códigos-fonte estão disponíveis na Internet [http://www.icox.org.br/download/] e podem ser copiados e instalados gratuitamente em qualquer servidor que rode os componentes Apache+MySQL+PHP juntos.

Objetivos do ICOX

• Viabilizar que o Brasil tenha um software livre para gerenciamento de comunidades virtuais gratuito;
• Com ele, a sociedade poderá criar as suas comunidades inteligentes potencializando, assim, ainda mais o uso da rede;
• A potencialização da rede vai agregar pessoas e projetos, gerando novos e atuais arranjos produtivos, em escala regional, nacional e internacional. Esses viabilizarão a curto, médio e longo prazo, o crescimento econômico das cidade, dos estados e do país.

Além disto, tornará possível a reciclagem de profissionais de informação, comunicação e de conhecimento, que poderão praticar em uma ferramenta real.

Características técnicas

Os códigos do sistema foram desenvolvidos na linguagem (PHP: Hypertext Preprocessor) e os dados são armazenados no banco de dados MySQL. O ICOX é multiplataforma, ou seja, roda em qualquer ambiente: Linux, Unix, Windows, Mac FreeBSD. Basta que o sistema operacional rode os componentes Apache+MySQL+PHP juntos.

Módulos do ICOX

• Usuário - dados relevantes do usuário e espaço para que ele se expresse e se posicione na rede.
• Comunidade - dados relevantes da comunidade para que ela se expresse e se posicione na rede.

Premissas do ICOX

• Acessível aos portadores de deficiência;
• Acesso por equipamento móveis.

Patrocínio:

Faperj - Fundação de Amparo à Pesquisa do Rio de Janeiro

Apoio:

• Infoglobo
• Crie-UFRJ
• Vale do Rio Doce
• TBG

   

Fonte: http://www.dicas-l.com.br/print/20061212.html

Permitindo a usuários Windows-ADS a logar em uma máquina Linux

Colaboração: Henrique Cicuto Machado

Os procedimentos abaixo descritos forem testados e estão atualmente em operação em máquinas rodando a distribuição Linux Fedora Core 3 em uma rede Active Directory Windows 2000.

No final do documento existem algumas observações extras sobre algumas seções.

Introdução

Apesar da grande maioria das empresas que adotaram, em qualquer aspecto, o uso do Linux atualmente se utilizarem de servidores Linux e estações Windows (senão uma rede completamente Linux), existem aquelas (a minha, por exemplo) que resolveram adotar máquinas Linux dentro de uma rede Windows.

Esse foi meu primeiro grande projeto trabalhando com Linux, e digo que ter que fazer isso sozinho não foi nada fácil. Então resolvi escrever esse pequeno tutorial sobre como implementar esse tipo de solução. Espero que possa ajudar alguém.

Instalação

A instalação é bem simples, sendo necessários apenas os seguintes pacotes:

1. Suíte SAMBA (samba, samba-common, samba-client)
2. PAM (Pluggable Authentication Modules)
3. Kerberos (krb5-libs e krb5-workstation)

Configuração

Agora vamos iniciar a configuração dos arquivos. Segue abaixo uma breve legenda para os exemplos:

• DC01 = É o meu controlador de domínio da rede Windows. IP: 192.168.0.2
• WS01 = É a minha estação de trabalho Linux
• KDOMAIN.SP = É o meu domínio Windows
• Admin = É o meu usuário Administrador da rede Windows

1) Kerberos (krb5.conf): Altere as seções 'realms' e 'domain_realms' para ficarem similares as abaixo.

 [realms] KDOMAIN.SP = { kdc = 192.168.0.2 default_domain = kdomain.sp } [domain_realms] .kdomain.sp = KDOMAIN.SP kdomain.sp = KDOMAIN.SP 

 

Cheque a configuração obtendo um ticket do Kerberos. Execute numa linha de comando:

 kinit Admin@KDOMAIN.SP Password for Admin@KDOMAIN.SP: 

 

Entre com a senha e pressione Enter. Se não aparecer nenhuma mensagem quer dizer que funcionou. Cheque o ticket com o comando 'klist'. A saída deve ser algo mais ou menos como abaixo:

 Ticket cache: FILE:/tmp/krb5cc_10000_YwFfS0 Default principal: Admin@KDOMAIN.SP Valid starting Expires Service principal 08/23/05 09:30:00 08/23/05 19:30:04 krbtgt/KDOMAIN.SP@KDOMAIN.SP renew until 08/24/05 09:30:00 Kerberos 4 ticket cache: /tmp/tkt10000 klist: You have no tickets cached 

 

2) SAMBA (smb.conf): A configuração do SAMBA pode variar muito de rede para rede, mas as opções necessárias estão listadas aqui.

 [global] netbios name = WS01 server string = WS01 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 realm = KDOMAIN.SP workgroup = KDOMAIN security = ads password server = * encrypt passwords = yes winbind separator = + winbind use default domain = yes winbind use default domain = yes winbind enum users = yes winbind enum groups = yes idmap uid = 10000-60000 idmap gid = 10000-60000 template shell = /bin/bash template homedir = /home/%U 

 

Agora execute o comando 'net' para adicionar a máquina Linux como parte da rede Windows:

net ads join

A saída do comando será algo como assim:

 [2005/08/23 09:51:33, 0] libads/ldap.c:ads_add_machine_acct(1405) Using short domain name -- KDOMAIN Joined 'WS01' to realm 'KDOMAIN.SP' 

 

Agora suba os daemons do SAMBA (smbd e nmbd) e do Winbind (winbindd). Cheque a comunicação do Winbind através dos comandos 'wbinfo -u', 'wbinfo -g' e 'wbinfo -t'. O primeiro deverá listar os usuários do Windows, o segundo os grupos e o terceiro deverá devolver a mensagem 'checking the trust secret via RPC calls succeeded'.

3) PAM: No diretório do pam, nós iremos alterar o system-auth. Uma observação importante aqui: No Fedora, esse arquivo afeta o login pelos terminais texto e pelo KDM. Apesar de ter tentando, eu admito que não consegui fazer essa alteração para fazê-la funcionar no GDM ou no XDM. Abaixo é uma cópia do meu system-auth. Outra observação importante: Quando eu fui configurar esse arquivo, percebi que havia sido criado, automaticamente, um system-auth-winbind. Caso ele exista, basta renomeá-lo para system-auth.

 auth sufficient /lib/security/pam_winbind.so auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/pam_winbind.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5shadow password sufficient /lib/security/pam_winbind.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so 

 

4) Nsswitch (/etc/nsswitch.conf): Apenas acrescente nas linhas 'passwd', 'shadow' e 'group' a entrada para o winbind:

 passwd: files winbind shadow: files winbind group: files winbind 

 

Agora é só correr para o abraço. Tente efetuar o login com seu usuário da rede Windows.

Observações:

1. Caso opte por compilar os pacotes a partir do source, não esqueça de ativar, no SAMBA, os suportes a 'ldap, 'ads', 'pam', 'krb5' e 'winbind' (smbmount também é recomendável).

    

2. É possível que, ao tentar obter o ticket do Kerberos ou ao adicionar a máquina no domínio, surja um erro sobre 'Clock skew too great'. Isso se refere a diferença muito grande de horário entre o Controlador de Dominio e a estação Linux. Acerte o relógio e o calendário caso isso ocorra.

    

3. Por favor, quaisquer dúvidas ou criticas me falem. Meu e-mail é <henrique cicuto (a) gmail com>.

    

Fonte: http://www.dicas-l.com.br/print/20051117.html

/var/yp/securenets (correção)

Colaboração: Rubens Queiroz de Almeida

Desculpem-me, mas na dica de hoje eu cometi um (pequeno) erro. Na sintaxe do arquivo /var/yp/securenets, o endereço da máscara de rede vem primeiro e em seguida vem o endereço da rede.

Tomei a liberdade de enviar a dica novamente para voces, com as devidas correções e acrescentei um pedaço do FAQ do AIX que trata do assunto.

O engano me foi apontado por "Carlos A. F. Brefe" <<brefe (a) bdt org br>>, a quem gostaria de agradecer.

Obrigado a todos,

Rubens

---

Não é novidade para ninguém que os serviços NIS oferecem sérios perigos à segurança de um sistema. Uma destas razões é que qualquer pessoa na Internet pode puxar qualquer mapa do NIS que desejar.

Um mapa bastante visado é o mapa de usuários (passwd). Mesmo que o seu sistema possua shadow passwords, ou seja, as passwords são gravadas em um arquivo diferente do /etc/passwd, o mapa do NIS combina os dois arquivos, tornando a expor as senhas.

 % cat /etc/passwd | grep queiroz queiroz:!:1020:1000:Rubens Queiroz de Almeida:/home/queiroz:/bin/ksh. 

Já o comando

 % ypcat passwd|grep queiroz queiroz:XzvA/VzEP0yB.:1020:1000:Rubens Queiroz - SUPSOF:/home/queiroz:/bin/ksh 

Ou seja, a segurança criada pelas shadow passwords é anulada pelo NIS.

Uma maneira de se reduzir os riscos é especificar quais máquinas podem realizar a transferência dos mapas de NIS. Isto pode ser feito criando-se um arquivo denominado "securenets" e localizado no diretório /var/yp do servidor NIS.

Este arquivo contém linhas do tipo

/var/yp/securenets

 255.255.255.0 200.200.20.0 255.255.255.0 200.200.21.0 

Cada linha consiste do endereço de uma máscara de rede (netmask) seguida do endereço da rede.Uma vez criado este arquivo apenas computadores que se enquadrem nestas restrições poderão fazer transmissão de mapas NIS do servidor (master ou slave) em questão.

A seguir anexo uma parte do FAQ do AIX que descreve as securenets e esclarece alguns pontos interessantes tais como maneiras de se identificar de onde partem tentativas de transferência (possivelmente ilegais) de mapas.

---

 Subject: 1.614: NIS security Ole.H.Nielsen@fysik.dtu.dk (Ole Holm Nielsen) SUMMARY: AIX 3.2.4 and above includes support for a more secure setup of the ypserv NIS daemon. You can prevent any random host on the entire Internet from reading your NIS maps, as is possible with the default AIX setup. The details: ------------ After starting the ypserv daemon, I noticed in the syslog the following line: Jan 17 12:01:18 zeise syslog: /usr/etc/ypserv: no /var/yp/securenets file This indicates that ypserv is looking for the mentioned configuration file, but did not find <I>, and hence will deliver the NIS maps to anyone on the net who can guess the NIS domainname. I installed the /var/yp/securenets file and restarted ypserv, and <I> works ! Any illegal attempt to read NIS maps will result in the following getting logged to syslog (example): Jan 18 13:37:27 zeise syslog: ypserv: access denied for 129.142.6.79 How to enable this NIS security option: Install the /var/yp/securenets file, for example: # /var/yp/securenets file # # The format of this file is one of more lines of # netmask netaddr # Both netmask and netaddr must be dotted quads. # # Note that for a machine with two Ethernet interfaces (i.e. a gateway # machine), the IP addresses of both have to be in /var/yp/securenets. # # for example: #255.255.255.0 128.185.124.00 # Loopback interface 255.255.255.255 127.0.0.1 Uncommenting the last line would limit access to hosts on the 128.185.124.* net, only. The loopback interface must be included, as shown above. To log violations, have a /etc/syslog.conf file containing the proper events. We use this line: *.err;kern.debug;auth.notice;user.none /var/adm/messages Caveat emptor: This works for us, and you will have to verify <I> at your own installation. Don't complain to us if you have troubles. I do not know what PTF level our AIX 3.2.4 is at. Our ypserv daemon looks like this: zeise> strings /usr/lib/netsvc/yp/ypserv | head -2 @(#)16 1.12 com/cmd/usr.etc/yp/ypserv.c, cmdnfs, nfs325, 9334325a 5/4/93 19:44:41 If your AIX doesn't have securenets support, ask your support centre for the PTF which includes APAR IX32328. That seems to have included the securenets support. 

Fonte: http://www.dicas-l.com.br/print/19970814.html

Instalando o Slackware via NFS ou FTP

Colaboração: Ricardo Iramar dos Santos

Esta documentação tem o objetivo descrever os passos relativo da instalação do Slackware via NFS ou FTP. É indicado que você saiba fazer a instalação padrão do Slackware diretamente do CD. Para maiores informações sobre como instalar o Slackware detalhadamente visite Piter Punk's HomePage.

Quando escrevi esta documentação o Slackware estava na versão 9.1.0. O procedimento para versões anteriores e o current é o mesmo e provavelmente será identico para versões posteriores.

Na realidade desta documentação poderia ser escrito duas outras (NFS e FTP), porém como as mesmas possuem muitas coisas em comum resolvi colocar tudo em uma única documentação.

A instalação do Slackware via NFS ou FTP não tem muita dificuldade, o que existe é uma pegadinha que até hoje não vi escrito em nenhuma documentação.

Curioso para saber sobre a pegadinha? Leia a documentação por completo para não cair nela :^D

Pré-requisitos

• Disco do boot, utilize o mais adequado para o seu hardware.
• Disco 1 de instalação.
• Quatro disquetes de 3 1/2**.
• CD 1 de instalação do Slackware ou um mirror da árvore oficial do Slackware.

Pré-requisitos para instalação via NFS

• Disco 2 de instalação.
• Disco de rede.

Pré-requisitos para instalação via FTP

• Disco 2 de instalação.
• Disco de rede.

Preparando o Terreno

Primeiro vamos gerar os disquetes, utilize o comando abaixo para gerar o disco de boot:

 ricardo@smith:~$ cat bare.i > /dev/fd0 

 

Repita o comando acima para os demais disquetes conforme o seu método de instalação (NFS ou FTP).

Nesta documentação a máquina chamada smith será o servidor de onde as estações poderam instalar o Slackware via NFS ou FTP.

Para a origem da instalação temos três opções: diretamente do CD, mirror local ou mirror remoto (somente FTP). Se for usar diretamente do CD é necessário primeiro montá-lo, insira o cd no driver de CD-ROM e digite o seguinte comando como root:

 ricardo@smith:~# mount /mnt/cdrom 

 

Você pode copiar o conteúdo do CD para o HD local gerando um mirror local ou baixar de qualquer mirror oficial do Slackware como o http://slackware.at. Deste mirror você pode baixar via http, ftp ou rsync.

Preparando o Terreno para instalação via NFS

Execute o comando abaixo para inserir uma linha no arquivo /etc/exports:

 ricardo@smith:~# echo **/mnt/cdrom/slackware *(ro,insecure,all_squash)** >> /etc/exports 

 

Caso esteja usando um mirror local substitua no comando acima o diretório /mnt/cdrom/slackware pelo diretório /mirrordir/slackware-9.1/slackware do mirror local.

ATENÇÃO: Esta é a famosa pegadinha, se o diretório exportado pelo NFS não contiver os diretório de softwares series (A, AP, D, E, ... X, XAP e Y) a instalação não irá funcionar e o pior, não emitirá nenhum erro.

Com esta linha no exports qualquer usuário da rede poderá montar este diretório como somente leitura. Reinicie o NFS para atualizar com a nova configuração:

 ricardo@smith:~# /etc/rc.d/rc.nfsd restart 

 

Preparando o Terreno para instalação via FTP

Remova a linha ftp do arquivo /etc/ftpusers para ativar o servidor anonymous do Proftpd. Agora edite o arquivo /etc/proftpd.conf alterando a seguinte linha de <Anonymous ~ftp> para <Anonymous /mnt/cdrom>. Caso esteja usando um mirror local substitua o diretório /mnt/cdrom pelo diretório /mirrordir/slackware-9.1 do mirror local.

No caso do FTP não tem pegadinha, porque no momento da instalação é necessário digitar o diretório que contém os diretórios de softwares series.

Reinicie o servidor FTP para valer as novas configurações com o seguinte comando:

 ricardo@smith:~# /etc/rc.d/rc.inetd restart 

 

Instalando

Inicie o computador onde deseja instalar com o disco de boot (bare.i). Aguarde até que apareça o prompt boot:, esse prompt serve para passar parâmetros para o kernel do linux na inicialização. Se você não sabe que parâmetro passar ou não precise passar nenhum tecle ENTER.

Aguarde enquanto o kernel do linux é carregado. Quando aparecer VFS: Insert root floppy disk to be loaded to RAM disk and press ENTER remova o disco de boot e insira o primeiro disco de instalação (install.1) e tecle ENTER. Mais uma vez, aguarde enquanto o primeiro disco de instalação do Slackware é carregado em memória RAM.

Quando aparecer Insert install.2 floppy disk to be loaded into RAM disk and press ENTER remova o primeiro disco de instalação e insira o segundo (NFS: install.2 ou FTP: install-ftp.2) teclando ENTER em seguida.

Ao aparecer Enter 1 to select a keyboard map: se estiver utilizando um teclado US International (sem cedilha) tecle ENTER caso contrário tecle 1 e em seguida ENTER.

Escolha o mapa conforme o seu teclado, se não souber qual escolher e seu teclado possuir cedilha escolha a opção qwerty/br-abnt2.map e tecle ENTER. Na janela de título KEYBOARD TEST tecle 1 em ENTER em seguida.

Provavelmente irá aparecer a tela de login com slackware login: no final. Tecle root sem as aspas é claro e tecle ENTER. Apesar de simples este passo é MUITO importante, se você teclar algo diferente de root (minúsculo) terá graves problemas mais para frente.

 root@slackware:/# 

 

Esse é o prompt de instalação do Slackware. Agora você já pode particionar o seu disco da forma que achar melhor usando cfdisk ou fdisk. Não vou explicar isso aqui pois não é a intenção desta documentação.

Após ter particionado o seu disco remova o segundo disco de instalação e insira o disco de rede (NFS: network.dsk ou FTP: network-ftp.dsk). No prompt digite network e telcle ENTER. Ele irá pedir para inserir o disco de rede, como você já inseriu simplesmente tecle ENTER novamente. Agora estamos no prompt network> do disco de rede.

Este é um procedimento específico para a instalação via FTP, caso esteja instalando via NFS pule para o próximo parágrafo. Para futuramente montar a partição via ftpfs precisamos subir agora o módulo do ftpfs teclando F e ENTER.

Em muito dos casos (provavelmente o seu também) um simples ENTER irá detectar a sua placa de rede e subir o seu respectivo módulo, caso contrário mude para outro console carregue o módulo manualmente com o comando modprobe.

Se o módulo da placa de rede for carregado com sucesso tecle ENTER para desmountar o disco de rede e voltar ao prompt de instalação. Você pode usar o comando lsmod para ver se o módulo realmente foi carregado.

Este é um procedimento específico para a instalação via FTP, caso esteja instalando via NFS pule para o próximo parágrafo. Perceba que ao executar lsmod o módulo ftpfs também é listado, caso não apareça você deve carregar o disco de rede novamente para carregar conforme descrito acima.

No prompt digite o comando setup e tecle ENTER.

 root@slackware:/# setup 

 

Realmente a brincadeira só começa agora, mas como a intenção desta documentação não é explicar passo a passo toda a instalação do Slackware vamos pular direto para o passo SOURCE Select source media supondo que você já tenha efetuado os passos obrigatórios anteriores.

Se estiver instalando via NFS selecione a opção 3 Install from NFS (Network File System) e tecle ENTER. Caso contrário selecione a opção 4 Install from an FTP server e tecle ENTER.

Na próxima tela entre com um IP (ex. 192.168.1.21) para configurar a maquina na qual o Slackware esta sendo instalado.

Entre com a máscara de rede (netmask), o setup assume por padrão a máscara 255.255.255.0 a qual iremos adotar nesta documentação como exemplo.

Essa tela é exclusiva da instalação por ftp, caso esteja instalando via NFS pule para o próximo parágrafo. Responda Yes se você possuir um gateway em sua rede, caso contrário responda No e pule o próximo parágrafo. Caso o FTP Server de onde você irá instalar estiver na internet você é obrigado a configurar um gateway.

Agora é a vez do gateway (ex. 192.168.1.254), se o seu servidor onde se encotra os softwares series estiver em outra rede você deve configurar com um gateway que consiga rotear para a rede dele.

No caso de instalação via NFS este é o passo mais importante, o IP do NFS Server (ex. 192.168.1.2). Na próxima tela indique o diretório do NFS Server que contém os diretórios de softwares series conforme comentado anteriormente (ex. se estiver usando CD indique /mnt/cdrom/slackware, caso contrário o diretório correspondente no mirror.).

Este é um procedimento específico para a instalação via FTP, caso esteja instalando via NFS pule para o próximo parágrafo. Agora você precisa configurar o IP (ex. 192.168.1.2) do FTP Server e o diretório onde estão os softwares series. Se você configurou o diretório root do usuário anonymous como sendo /mnt/cdrom como indicado acima, você deve entrar com os seguintes dados anonymous:senha@192.168.1.2/slackware. Caso esteja utilizando um mirror altere o diretório após o IP do FTP Server apontando para o diretório onde se encontra os softwares series.

Em seguida o setup irá configurar sua placa de rede com os dados fornecidos anteriormente e configurar o gateway se você possuir algum.

Se estiver instalando via NFS o setup irá rodar também o rpc.portmap para poder montar o NFS e em seguida montar o NFS. E por último o setup irá listar a tabela de partições montadas para você verificar se o NFS foi montado corretamente. Caso o NFS tenha montado corretamente tecle n e ENTER para continuar com a instalação ou y para revisar suas configurações de rede.

Caso contrário, instalação via FTP, o setup irá listar a tabela de partições montadas para você verificar se a partição foi montada corretamente utilizando o ftpfs. Caso a partição tenha sido montado corretamente utilizando o ftpfs tecle n e ENTER para continuar com a instalação ou y para revisar suas configurações de rede.

A próxima tela deve aparecer os softwares series para que você selecione os que deseja instalar, se não aparecer provavelmente você errou em algum passo acima.

No caso de ter errado algo você pode selecionar Cancel teclando TAB e ENTER para cancelar a instalação e em seguida voltar a selecionar a opção SOURCE Select source media para reiniciar as configurações.

Se tudo estiver correto até aqui, agora é só seguir com o procedimento padrão de instalação do Slackware como se fosse diretamente de um CD.

Conclusão

O mito que a instalação via rede do Slackware é complicada foi completamente desvendada.

Em testes práticos tive menos problemas com a instalação via FTP do que via NFS. O interessante do NFS é fornecer acesso ao diretório patches para futuras atualizações do sistema em rede otimizando o espaço em disco em diversas máquinas.

Referências

• Getslack
• Slackware
• Slackftp
• Página de Piter Punk
• Google

Dúvidas, críticas e sugestões devem ser enviadas para agent.smith@globo.com.

Quer saber mais um pouco sobre o autor desta documentação? Acesse minha home page em http://www.agentsmith.kit.net.

Fonte: http://www.dicas-l.com.br/print/20050716.html

Acesso a rede windows atraves do browser.

Colaboração: Ricardo Henrique Cândido

Algum dias atras me deparei com a nessecidade de disponibilizar um certo compartilhamento (samba) para acesso remoto. Fui no site do google e deu uma pesquisada e encontrei o SmbWebClient

O SmbWebClient um script escrito por Victor M. Varela, para usar a rede windows atraves do browser. O SmbWebClient foi escrito em php, é um gpl.

Não foi preciso nem mesmo nenhuma configuração,baixei e copiei o script para o DOCUMENTROOT do apache, fui no browser e ja funcionou. É bem facil de configurar, alterei apenas duas linhas e ja estava como era preciso.

Fonte: http://www.dicas-l.com.br/print/20041116.html

Configurando a velocidade de sua placa de rede

Colaboração: Rodrigo Pace de Barros

Configurar a velocidade em que uma placa de rede funciona é simples. Para fazê-lo em ambientes que utilizem RedHat (ou sistemas operacionais provenientes dele, como o CentOS), deve-se utilizar o comanto ethtool da seguinte forma:

Como root, digite:

 ethtool -s <Placa> speed <Veloc> duplex <Multplx> autoneg <on|off> 

 

onde

• <Placa>: Placa de rede que se deseja alterar a velocidade.

   

• <Veloc>: Velocidade utilizada nesta configuração. Pode ser 10/100 e até 1000 dependendo da placa. Normalmente coloca-se off quando a configuração original da placa é alterada.

   

• <Multplx>: Indica se a placa trabalhará em half-duplex ou full-duplex. Para configurarmos como full-duplex, utilize a string "duplex". Para configurar como half-duplex, utilize a string "half".

   

• <on|off>: indica se a placa terá a capacidade de auto negociar a sua velocidade com o switch. Normalmente utiliza-se o "off" quando alteramos as configurações de velocidade e multiplexação da placa.

Assim, caso seja necessário configurar a placa eth0 em 100 full-duplex, utilze o comando:

 ethtool -s eth0 speed 100 duplex full autoneg off 

 

Para que estas configurações sejam permanentes no sistema, deve-se editar o arquivo de configuração que gerencia estas informações.

Acesse o diretório onde os arquivos de configuração das placas de rede se encontram:

 # cd /etc/sysconfig/network-scripts 

 

Dentro deste diretório existirá um arquivo por interface de rede. Assim, caso você tenha em seu computador 2 interfaces "eth", você terá os seguintes arquivos:

• ifcfg-eth0
• ifcfg-eth1

Claro que existirá o arquivo para a interface de loopback, denominada "ifcfg-lo". Porém esta não será vista aqui.

Para configurar a velocidade nas placas de rede, edite o arquivo desejado:

 # vi ifcfg-eth0 

 

e insira nele a seguinte linha:

 ETHTOOL_OPTS="autoneg <no|off> speed <Veloc> duplex <Multplx>" 

 

Assim, caso seja necessário configurar a placa eth0 em 100 full-duplex, utilze a string:

 ETHTOOL_OPTS="autoneg off speed 100 duplex full" 

 

Fonte: http://www.dicas-l.com.br/print/20060915.html

Imprimir do Gnu-Linux via rede local para impressora conectada ao Windows XP

Colaboração: Clodoaldo J. Duarte

Como imprimir de um microcomputador com Sistema Operacional GNU Linux, via rede local, numa impressora conectada a um computador com Windows XP.

É comum a usuários apaixonados pelo Sistema Operacional GNU Linux ter que utilizar, via rede local, uma impressora conectada a um microcomputador com Sistema Operacional MS Windows XP.

Após frustradas tentativas seguindo as instruções existentes na Web, inclusive foruns, para minha felicidade, encontrei no site http://www.swerdna.net.au/linhowtosambaprint.html, a orientação técnica abaixo, digna de transcrição e divulgação.

Como Ativar no Windows XP o suporte a impressão Unix

1. Ativar no Windows o suporte a impressão Unix: abra o Painel de Controle Adicionar ou remover programas, Adicionar ou remover componentes Windows. Selecione Outros serviços de arquivos e impressão de rede e clique em Detalhes. Assinale a opção Serviços de impressão para Unix , confirme e volte ao Painel de Controle.

    

2. Agora que o Serviço de impressão para Unix está ativado, é necessário ativá-lo como um Serviço do Windows XP: abra o Painel de Controle, Ferramentas Administrativas, Serviços (Local) e encontre a opção Servidor de impressão TCP/IP . Dois cliques nesta opção e na caixa Tipo de inicialização selecione Automático. Confirme (OK).

    

3. Reinicie o Windows e a impressora estará disponível para clientes Linux. Embora o how-to não faça referência, acredito ser necessário também ativar o recurso de Compartilhar a impressora na rede.

Observações

1. O artigo trata também de duas alternativas de protocolo de rede que permitem ao cliente Linux utilizar a impressora conectada no Windows: com a utilização do protocolo Samba's SMB/CIFS e com o protocolo LPD.

    

2. No computador com Gnu Linux neste caso um cliente do Servidor de impressão Windows XP utilizei os Servidores Samba e CUPS. Não entrarei em detalhes uma vez que na internet existe um vasto material a respeito. Entretanto, é bom destacar que para administrar impressoras no CUPS, digite no navegador web a URL http://localhost:631 e execute:

    

3. clique em Add Printer, preencha os campos Nome, Localização e Descrição da impressora;

    

4. no campo Device escolha Windows Printer via SAMBA;

    

5. na campo Device URI digite smb:workgroup/username:password@ip/nome-printer ou smb:workgroup ou ip/nome-printer ou lpd://workgroup ou ip/nome-printer, onde "username", "password" and "workgroup" são parâmetros utilizados na sua rede local e nome-printer é o nome de compartilhamento da impressora no WindowsXP;

    

6. campo Manufaturer, selecione o fabricante da impressora;

    

7. campo Modelo, selecione o driver compatível com o modelo da impressora. Em caso de dúvida, consulte o sitio www.linuxprinting.org/, o sítio do fabricante, dentre outros;

    

8. Clique em Add Printer , volte para a tela principal do CUPS e execute o teste de impressão Print Test Page . Bom trabalho.

Fonte: http://www.dicas-l.com.br/print/20070616.html

Implementando soluções com o OpenVPN

Colaboração: Tiago Cruz

VPN significa Virtual Private Network, usada amplamente para fazer um túnel seguro entre duas redes distantes, separadas pela internet. Os dados são criptografados antes de entrar no túnel e apenas a outra ponta conhece a chave para descriptografar o mesmo, criando um canal de comunicação relativamente seguro.

Este documento visa abranger os principais problemas de implementação de uma VPN, assim como suas soluções.

Porque usar PPTP

O PPTP (Point-to-Point Tunneling Protocol) é uma implementação de VPN baseado no protocolo GRE e na tecnologia PPTP. Seu funcionamento é semelhante ao de uma conexão dial-up: ele "disca" para um host conhecido, troca chaves através do protocolo GRE e conecta uma interface virtual (ppp) por onde a comunicação dentro do túnel ocorre. Para estabelecer a conexão é necessária a autenticação de um usuário, podendo ser local ou um já pré-existente em uma base LDAP como o Active Directory.

Ele possui a vantagem de ter sido "adotado" pela Microsoft, portanto funciona nativamente desde o Windows 95 até o atual Windows XP sem precisar instalar nada no cliente. Seria uma solução interessante: O cliente remoto com um notebook poderia conectar à nossa rede de uma forma segura, passando pelo firewall em Linux/ BSD e autenticando em nossa rede usando a mesma senha da rede local. Seria realmente bem bacana se não fosse as desvantagens do PPTP.

Porque não usar PPTP

Ao mesmo tempo que é uma vantagem ter um protocolo mantido pela Microsoft, é também uma desvantagem devido a falta de segurança da empresa citada e seus produtos. Segundo o Marcolino Alexandre, "O protocolo PPTP possui uma série de falhas exploradas por hackers que possibilitam a invasão ou a indisponibilidade de servidores Windows. Tanto o projeto POPTOP como o MPD que fazem o trabalho de servidor PPTP para Linux e FreeBSD respectivamente, não são vulnerável à ataques de exploits para Windows, apesar do protocolo ainda ser vulnerável a indisponibilidade."

Mas o problema mais grave que eu percebi durante a implementação do PPTP é este descrito pelo Gleb Smirnoff: //"Masquarading GRE protocol, which is used by PPTP as transport, isn't simple. Not all NATs can do this. If you are going to server a lot of clients connecting from random places in the world, then you will face this problem time to time."//

Portanto, se algum dia seu cliente com o notebook estiver em algum hotel, aeroporto ou qualquer lugar do mundo conectado à Internet atras de um NAT de roteador, ele não conseguirá se conectar a sua rede. Configurar um firewall para rotear o protocolo GRE é extremamente trabalhoso, incluindo passos como a recompilação do kernel no Linux. Fora o fato de que alguns roteadores "encaixados" simplesmente não roteiam e ponto final. E o trabalho deve ser feito no roteador onde o cliente está, e não do seu lado, tornando-se impraticável pedir para que cada sysadmin faça isso em seu firewall antes que seu cliente precise de tal recurso.

Para ler mais sobre esta solução, favor consultar o artigo anterior chamado Soluções de VPN integrando Linux, FreeBSD e Windows.

Sobre o OpenVPN

O OpenVPN usa criptografia de chaves ao invés de usuário e senha para fechar um túnel de VPN. Segundo o Luiz Antônio Filho, ele "simplesmente pega a informação que ele precisa mandar para a outra ponta, criptografa ela, e manda pela internet por um pacote UDP. A grande vantagem, é que ele não tem muitos problemas para passar por firewalls, e por roteadores que fazem NAT."

Atualmente, o OpenVPN roda nas seguintes plataformas: Linux, Windows 2000/XP ou superior, OpenBSD, FreeBSD, NetBSD, Mac OS X, e Solaris. É, por assim dizer, um projeto Open Source licenciado pela GPL.

1. Instalação

A parte da instalação está bem documentada no site oficial do projeto e traduzida para o Português do Brasil aqui.

Você pode encontrar pacotes pré-compilados para a maioria das distribuições Linux, ou ainda instala-lo através do /usr/ports/security/openvpn do FreeBSD. Se você preferir compilar "na unha" certifique-se de ter as bibliotecas de desenvolvimento do OpenSSL (algo como openssl-dev) instaladas no seu micro. O dispositivo TUN/TAP deverá estar compilado no seu kernel também, caso sua distribuição não o traga como padrão (está presente desde o kernel 2.4.7).

1.1. Gerando os Cerificados e Chaves RSA

Antigamente, você tinha que gerar as chaves CA manualmente, assina-las, criar as chaves dos clientes e gerar os parâmetros Diffie-Hellman (utilizado para a troca das chaves criptografadas durante a execução). Eram uma série de comando complicados de decorar, mas agora o OpenVPN vem com uma série de scripts chamados easy-rsa junto em seu pacote, para tornar esta tarefa mais simples.

Você pode encontrar estes scripts em /usr/local/share/doc/openvpn/easy-rsa e é encorajado a copia-los para seu diretório de configuração do OpenVPN (algo como /etc/openvpn ou /usr/local/etc/openvpn).

Ja dentro do diretório apropriado, você deve editar o arquivo vars e personalizar suas informações. Após isso, pode seguir com os comandos:

 # . ./vars # ./clean-all # ./build-ca 

 

O último comando, buil-ca irá gerar seu Certificado de Autoridade (CA) usando as bibliotecas do OpenSSL. Os parâmetros serão lidos do arquivo previamente configurado (vars) com excessão do parâmetro Common Name, onde você pode colocar algo como "CA-OpenVPN".

1.2. Gerando o certificado e a chave para o servidor

Use o comando abaixo, respondendo a questão "Common Name" como anteriormente (você pode usar "server" neste caso). Deverá tomar cuidado também em responder "y" quando solicitado em "Sign the certificate? [y/n]".

 # ./build-key-server server 

 

1.3. Gerando os certificados e chaves para os clientes

Os comandos abaixos deverão ser utilizados para gerar a chave dos clientes, e você deve colocar este mesmo nome quando solicitado no campo Common Name.

 # ./build-key mario # ./build-key maria # ./build-key renata 

 

Importante: Cada cliente deverá ter um Common Name único!

Para aumentar ainda mais a segurança, recomendo usar o comando build-key-pass para que as chaves seram geradas com uma senha. Assim, o cliente deverá ter o certificado e deverá saber a senha para acessar sua rede.

1.4. Gerando os parâmetros Diffie Hellman

Os parâmetros do Diffie Hellman deverão ser gerados da seguinte forma:

 # ./build-dh 

 

Nota: Isso pode demorar um pouco.

1.5. Chaves geradas

No subdiretório chamado "keys" você encontrará os arquivos gerados. Segue uma tabela falando sobre os principais arquivos:

Arquivo	Necessário por	Finalidade	Secreto
ca.crt	servidor + todos clientes	Certificado CA raiz	NÃO
ca.key	máquina que assina as chaves	Chave CA raiz	SIM
dh.pem	somente servidor	Parâmetros Diffie Hellman	NÃO
server.crt	somente servidor	Certificado do Servidor	NÃO
server.key	somente servidor	Chave do Servidor	SIM
mario.crt	somente mario	Certificado do mario	NÃO
mario.key	somente mario	Chave do mario	SIM
maria.crt	somente maria	Certificado da maria	NÃO
maria.key	somente maria	Chave da maria	SIM
renata.crt	somente renata	Certificado da renata	NÃO
renata.key	somente renata	Chave do renata	SIM

 

Agora você deverá copiar os arquivos para o diretório de configuração dos clientes ou servidores. A cópia deverá ser feita preferencialmente usando uma forma segura, pois a mesma garante a conexão do mesmo com a rede.

No servidor, copie as chaves para /etc/openvpn (Linux) ou /usr/local/etc/openvbd (FreeBSD). Nos clientes Windows, copie para "%programfiles%"/OpenVPN/Config.

1.6. Bloqueando clientes indesejados

Você pode ainda querer tira o o acesso de determinado cliente. Você pode fazer isso de pelo menos duas maneiras:

1.6.1. Criando uma rota inválida

Coloque essa linha no server.conf:

 client-config-dir ccd 

 

Crie o diretório ccd e dentro dele um arquivo como esse:

 # cat ccd/mario ifconfig-push 10.8.2.5 10.8.2.6 

 

Assim, quando o Sr. Mario conectar ele irá pegar uma rota inválida e não vai conseguir acessar nossa rede. Uma maneira mais elegante de fazer isso é descrito abaixo:

1.6.2. Revogando o certificado

Use o script contido no easy-rsa:

 # . vars # ./revoke-full mario 

 

E adicione essa linha no server.conf:

 crl-verify crl.pem 

 

Assim, o cliente irá falhar logo no "handshake". Apenas cerifique-se de copiar o arquivo crl.pem gerado dentro da pasta keys para o diretório de configuração do servidor!

1.7. Configurando o servidor

O arquivo openvpn.conf poderá ficar assim:

 # IP e porta do servidor local 200.222.222.222 port 1194 proto udp dev tun # Certificados gerados ca ca.crt cert server.crt key server.key dh dh1024.pem # Criar no diretorio cdd/cliente a configuracao # dele - ou uma invalida para trava-lo :) client-config-dir ccd # Rede que os clientes irão "pegar" server 10.8.0.0 255.255.255.0 push "route 192.168.0.0 255.255.252.0" push "dhcp-option DNS 192.168.0.19" # Neste arquivo serão guardados os IPs dos clientes # para conectarem com o mesmo IP da proxima vez ifconfig-pool-persist ipp.txt client-to-client # Ative para permitir dois clientes com o mesmo # certificado - não recomendável ;duplicate-cn keepalive 10 120 # Compressão, privilégios do cliente comp-lzo max-clients 15 user nobody group nobody # Logs e etc persist-key persist-tun status /var/log/openvpn-status.log log /var/log/openvpn.log log-append /var/log/openvpn.log verb 6 

 

Ao iniciar, fique atento aos logs para ver se está tudo certo.

1.8. Configurando um cliente Windows

1.8.1. Instalação

A instalação é bem simples: Basta instalar o arquivo openvpn-2.0.5-gui-1.0.3-install.exe e copiar os arquivos para sua pasta de configuração. Para simplificar mais ainda, escrevemos um arquivo de lote para facilitar a instalação em clientes remotos. Note que permissão de administrador se faz necessário para instalar este software.

 @echo off REM OpenVPN Installer REM by Tiago Cruz REM Julio Soares REM 20 Jan 2006 @echo. echo Wait, starting instalation of OpenVPN... echo Always click in 'Next', 'Install', 'Continue Anyway' and 'Finish' start /wait bin/openvpn-2.0.5-gui-1.0.3-install.exe @echo. echo Wait, copying files... @echo. copy conf*.* "%programfiles%"OpenVPNConfig @echo. echo Done. You can access the VPN now. @echo. pause @echo. 

 

Preparamos ainda um "pacote" zipado com arquivo a ser instalado dentro do diretório "bin" e as configurações no "config". Assim o usuário final apenas precisa descompactar o arquivo zip e clicar no install.bat 8-)

1.8.2. Configuração

Um exemplo de configuração de um cliente Windows:

 client dev tun proto udp remote 200.222.222.222 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert renata.crt key renata.key ns-cert-type server comp-lzo verb 3 

 

Você deve ser capaz de conectar ao seu servidor, pinga-lo através do IP 10.8.0.1 e sua rede 192.168.0.0/22 também através da rota criada no arquivo de configuração do servidor, caso ele seja o gateway de sua rede.

Consulte o howto oficial para maiores detalhes sobre os assuntos aqui abortados.

2. Dicas avançadas

2.1. VPN em um host não gateway

Se você montar seu servidor de VPN em um host que não é o gateway da internet (por exeplo no 192.168.0.253) você precisará criar uma rota em seu gateway pelo seguinte motivo:

Quando o cliente conectado via VPN com o IP 10.8.0.1 envia um pacote de ICMP para o host 192.168.0.11. O pacote chega até o host, mas ele não tem rota para a rede 10.8.0.0/24 portanto ele devolve o pacote para o gateway da rede. Se este gateway não tiver rota também, o pacote será descartado. Portanto, é necessário que o gateway envie os pacotes para o servidor de VPN.

Em um servidor FreeBSD a rota ficaria assim:

 route delete 10.8.0.0 &> /dev/null route add -net 10.8.0.0 -netmask 255.255.255.0 192.168.0.253 &>/dev/null 

 

Em um servidor Linux seria assim:

 route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.0.253 eth0 

 

2.2. Conflito: redes iguais

Se a rede de sua empresa é 192.168.0.0/24 e a do cliente também, ao fechar a VPN o cliente irá ficar com duas rotas para o mesmo destino. No caso do Windows, o pacote não irá para uma rede e nem para a outra :-)

Será necessário remapear a rede de destino para "enganarmos" o sistema operacioal, fazendo parecer que temos duas redes distintas: a do cliente 192.168.0.0/24 e a do servidor que também é 192.168.0.0/24 ficará como sendo 192.168.1.0/24.

Utilizando o iptables/ netfilter do Linux:

 iptables -t nat -A PREROUTING -d 192.168.0.0/24 -j NETMAP --to 192.168.1.0/24 

 

Utilizando o PF do Free/OpenBSD:

 vpn = "tun0" ... set loginterface $vpn2 ... binat on $vpn from 192.168.0.0/24 to any -> 192.168.1.0/24 ... pass in on $vpn from any to any keep state pass out on $vpn from any to any keep state 

 

Assim, para o cliente via VPN alcançar o host 192.168.0.32, ele deverá procurar por 192.168.1.32.

Outra coisa, no arquivo de configuração do OpenVPN deverá conter a rota adequada:

 push "route 192.168.1.0 255.255.255.0" 

 

No lugar da rota antiga:

 push "route 192.168.0.0 255.255.255.0" 

 

Você verá algo assim no tcpdump:

 54. 224700 rule 26/0(match): pass in on tun0: 10.8.0.6 > 192.168.0.32: ICMP echo request, id 1024, seq 13568, length 40 

 

Você pode encontrar mais informações neste artigo chamando Dirty NAT Tricks, escrito pelo Nick Martin.

2.3. Solucionando problemas

Caso você tenha algum problema durante a operação, será necessário acompanhar os logs do aplicativos, bem como utilizar a ferramenta tcpdump para ver o que está acontecendo com os pacotes. Os logs do firewall também podem ajudar neste caso, assim como o comando netstat -nr para acompanhar se os pacotes estão dando match nas rotas propostas.

Você pode ainda contar com a ajuda de algumas listas de discussão, como as listadas abaixo:

• https://lists.sourceforge.net/lists/listinfo/openvpn-users
• http://lists.freebsd.org/mailman/listinfo/freebsd-net
• http://lists.freebsd.org/mailman/listinfo/freebsd-pf
• http://lists.netfilter.org/mailman/listinfo/netfilter/

Fonte: http://www.dicas-l.com.br/print/20060316.html

Monopólio da cultura em declínio

© Rafael Evangelista

Livro líder de vendas nos EUA está disponível na internet. Fenômeno comprova a tese de que estar na rede não derruba as vendas. Pode até ajudar

Em 1999, fascinado com a internet e o fenômeno mp3, David Bowie já declarava ao diário inglês The Guardian: "A maneira como a nossa sociedade quebra os parâmetros tem levado à desintegração da propriedade intelectual". Mas, ao que parece, isso não afeta os negócios. Ao contrário, cada vez mais a rede é usada para a divulgação e distribuição de obras artísticas. O que é interpretado pela conservadora indústria como o caos, tem se mostrado como o paraíso para os artistas independentes.

O fato novo que comprova a tese não foi produzido por artistas, mas é mais uma evidência que se acumula de que a disponibilização online de obras não necessariamente derruba as vendas no mundo real. Surpreendentemente, um documento público, que pode ser baixado gratuitamente na rede, está, há nove semanas, no topo da lista dos livros mais vendidos do New York Times.

É claro, 9/11 Comission Report, o documento que relata as conclusões da comissão parlamentar que investigou a responsabilidade do governo Bush sobre o 11 de setembro, tem um apelo próprio, maximizado pelo período eleitoral. O livro que o secunda na lista de não-ficção em brochura trata das experiências de uma professora no Irã - Reading Lolita in Tehran - e os dois líderes da lista de não-ficção em capa dura são ataques a Bush e a Kerry - The Family e Unfit for Command, respectivamente. Mas o fato mostra que estar de graça na internet não arruína as vendas de ninguém.

Grata surpresa

As grandes vendas assustaram os editores da editora Norton, responsável pela publicação. Nas livrarias ao preço de US$ 10, o relatório já ultrapassou a marca de 600 mil exemplares. "Ninguém antecipou as vendas nesse nível", declarou a editora de publicidade da Norton, Louise Brockett, à revista Wired.

O fenômeno vai na contramão dos chamados e-books, os livros vendidos para serem lidos online. Embora as vendas tenham aumentado 28% neste ano, as cifras mundiais permanecem tímidas: US$ 3,23 milhões, quase nada se comparado ao mercado bilionário de livros em papel.

Na ficção, mais dificuldades

Poucas pessoas parecem se animar em pagar para ler na tela. O autor de romances de terror, Stephen King, por exemplo, teve uma experiência traumática - para ele e principalmente para seus fãs. Depois de comemorar as grandes vendas do romance Ridding the Bullet, um pequeno conto escrito quando convalescia de um acidente quase fatal e que foi vendido por US$ 2,50, King aventurou-se a escrever um livro em capítulos que seriam publicados gradualmente, The Plant. Depois de apenas 46% dos leitores terem feito o pagamento - que era voluntário - pelo quarto capítulo, o autor interrompeu a publicação no sexto, que já estava escrito. Quem pagou ficou furioso por ter comprado um livro sem final.

Ao mesmo tempo, escritores independentes e alternativos começam a liberar seus conteúdos online. Ted Nace, autor de Gangs of America, um livro que examina as raízes da cultura corporativa estadunidense, está disponível na internet e nas livrarias. Como não poderia deixar de ser, o pai da licença Creative Commons - aquela que autoriza o compartilhamento de obras protegidas por direito autoral -, Lawrence Lessig, também oferece para download sua última obra, Free Culture, embora seus livros anteriores continuem nas mãos da editora.

Em português, obras técnicas

No Brasil, literatura online em profusão somente com direitos autorais vencidos, ou seja, apenas obras antigas. O quadro muda um pouco quando o assunto são teses acadêmicas e livros técnicos. Univesidades como a Unicamp e sua Biblioteca Digital fazem um esforço de convencimento para que os alunos de mestrado e doutorado ofereçam dissertações e teses a todos. Já o projeto Scielo, mantido por fundações de apoio à pesquisa, oferece revistas de todas as áreas da ciência.

Uma experiência interessante, embora modesta, foi realizada pelo programador Aurélio Marinho Jargas, autor do Guia de Expressões Regulares, um livro sobre termos usados nos sistemas operacionais Linux, Unix e Windows. Ele colocou o livro em sua página pessoal, embora também possa ser encontrado em livrarias. Lançado em agosto de 2001, já vendeu mais de 1,5 mil cópias, marca que o autor comemora. "Pessoalmente, como programador que por acaso escreveu um livro, vender um exemplar por dia, durante quase 3 anos, é um marco. Sinto que essa empreitada foi um sucesso completo", afirma ele na página onde publica um gráfico com as vendas. "Na média, ganho mais R$ 50 por mês em direitos autorais. Acredita? Com Expressões Regulares! Quem diria que isso é vendável? E continua vendendo e rendendo, num ritmo constante", completa.

Download de mp3 não afeta venda de CDs

No mundo da música, até pesquisadores da Universidade Harvard e da Carolina do Norte já mostraram que os programas de trocas de arquivos não afetam as vendas. Em março deste ano, dois pesquisadores dessas universidades publicaram um estudo, feito durante 17 semanas de 2002, em que foram cruzados dados sobre a venda de discos e downloads feitos. A conclusão foi que o efeito de um sobre o outro é estatisticamente zero e que os usuários que baixam os arquivos na rede não comprariam os discos mesmo se as músicas não estivessem disponíveis. Mesmo assim, os processos e as multas contra os usuários continuam.

Até agora, quem tem feito um melhor uso da internet são as gravadoras independentes, que usam a rede para superar a dificuldade de distribuição dos CDs e a verba reduzida para o marketing. A banda pernambucana Mombojó usou essa estratégia e conseguiu grande destaque na grande imprensa e mais contatos para shows. Segundo declarou o empresário da banda, Luciano Meira, ao site Cultura e Mercado, primeiro a banda começou a ser citada por um grande número de blogs, já que as músicas estavam disponíveis para resenha, o que foi criando um movimento até atingir os maiores veículos. O empresário cita o caso da banda como uma comprovação do que foi afirmado pelos pesquisadores estadunidenses. "Temos muitos e-mails de pessoas que comentam ter baixado uma ou algumas músicas no site e daí terem decidido comprar o CD, aliás, muito em consonância com estudos recém-realizados a este respeito".

Outro que resolveu oferecer livremente suas músicas foi B Negão, ex-vocalista do Planet Hemp. Todas suas músicas de seu disco mais recente, Enxugando Gelo, estão disponíveis em copyleft. Ele usa o site do Centro de Midia Independente para oferecer as músicas."Você já ouviu falar em copyleft? Pois é...se informe sobre esse novo método de compartilhar idéias e conhecimento", diz ao fazer o link. Ainda no cenário nacional, uma das gravadoras a estratégia de distribuição de "amostras" de álbuns é a Trama, que oferece algumas - poucas - músicas de seus principais artistas e mantém o Trama Virtual. Lá, as bandas independentes podem oferecer suas músicas em um espaço controlado pela empresa.

Como nos EUA houve o maior número de processos e até prisões de usuários de usuários de sistemas de trocas de arquivos, o confronto com a associação das gravadoras é mais saliente. Muitas das gravadoras de música alternativa e independente já se dizem parte das campanhas em favor da não criminalização do download. "Vamos provar a todos que o download pode ajudar os artistas e não prejudicá-los", diz a Go-Kart, que reúne artistas como os Buzzcocks e Lunachicks. Ela oferece o álbum completo de algumas bandas e pede que os fãs apóiem os artistas, comprem o disco e assistam o show.

Quem manda são as gravadoras

A decisão sobre compartilhar ou não parece parece que não está nas mãos dos artistas e sim das gravadoras. Mesmo que tenham se declarado contra a política das gravadoras ou afirmado apoio ou ao copyleft ou às licenças da Creative Commons, a maior parte do catálogo de nomes como Pearl Jam, Beastie Boys, David Byrne, REM e outros continua fechada. No máximo, alguns desses artistas conseguem a liberação de direitos da gravação não-oficial de seus shows.

Nem o ministro da cultura Gilberto Gil conseguiu a liberação de três de suas músicas com a licença da Creative Commons. Sua gravadora, a Warner, não permitiu que Refazenda, Refavela e Realce fossem liberadas para download gratuito, como estipula a licença. Gil teve, então, que oferecer Oslodum, cujos direitos pertencem a ele.

Essa mesma licença, que também permite que trechos da música sejam usados para construir novas canções, regulará os direitos de um CD com a participação do ministro, que a revista Wired deverá lançar em novembro. Ele foi gravado durante um show em Nova Iorque, do qual também participaram David Bowie e os Beastie Boys e foi transmitido pela internet.

Tanta agitação no mundo da cultura mostra como a arte proprietária vagarosamente dá espaço a formas mais livres de expressão, sem ameaçar o sustento de ninguém. Parece que, em breve, assim como o software livre já substitui com vantagens o software proprietário, ninguém mais precisará da arte que não seja livre.

Para ler:

• 9/11 Comission Report
• Gangs of America:
• Biblioteca Digital da Unicamp:
• Scielo:

Para ouvir:

• B Negão e os Seletores de Frequência
• Mombojó:
• Go-Kart Records:
• Nebula

Fonte: http://www.dicas-l.com.br/print/20041002.html

A Polêmica Linux x Windows NT

Colaboração: Rubens Queiroz de Almeida

Como não poderia deixar de ser, e como eu já esperava, a mensagem de ontem causou uma certa polêmica. Estou incluindo algumas das mensagens que me enviaram sobre o assunto.

Alguns esclarecimentos, o teste foi realizado dentro da rede interna da Unicamp, ethernet a 10Mbits/s.

O equipamento utilizado foi o mesmo. Foi feita a transferência com NT, encerrado o sistema, e trocado o disco rígido para um contendo Linux, rebootada a máquina e feita a transferência com Linux.

A seguir, algumas das mensagens que recebi:

---

From: "Jorge Yuri de Lion Yaname" [<jorgeyur (a) techno com br>] Sou de Bauru-SP, e um amigo meu tem o Linux instalado num 486 dx4-100, com 16 mb, modem de 33.6 k, e tem o Win 95 em um micro Pentium II 300, com 64 mb e modem de 56.6 k. Ele começou a fazer um dowload com o Netscape de um mesmo arquivo, e o computador que tinha o Linux terminou, e o computador que tinha o Win ainda faltava 15 % para terminar. Parece que a lentidão da Internet não é só problema de linha telefonica, acho que o Sistema Operacional influi muito.

---

From: Jefferson Lordello Polizel [<jlpolize (a) carpa ciagri usp br>]

Esse foi um teste realizado no Depto. de Ciências Florestais/ESALQ/USP.

Testes de Transferência de Arquivos Utilizando ligação direta a Internet via Rede Local. Taxa de Transferência da rede: 100mbits/s Taxa de Transferência da placa de rede: 10mbits/s Taxa de Transferência da linha externa: 2Mbytes/s Tamanho do Arquivo: 25 MB Tempo de Transferencia em WindowsNT 4.01 com IE 4 5h e 13m Tempo de Transferencia em Linux RedHat Marumbi com NE 3h e 25m Tempo de Transferencia em Linux Debian 2.0.6 usando FTP 2h e 12m

---

Fonte: http://www.dicas-l.com.br/print/19990610.html

Instalação Linux em Modo Kickstart

Colaboração: Rubens Queiroz de Almeida

1. Introdução

É possível se fazer a instalação do Linux de forma automatizada, onde o programa de instalação obtém a resposta para a maioria das perguntas a partir de um arquivo de configuração. Desta forma o administrador pode obter um ganho considerável de tempo na instalação e configuração de um grande número de estações de trabalho Linux.

Esta modalidade de instalação chama-se kickstart. O administrador de sistemas cria um arquivo de configuração onde são especificadas todas as opções de instalação como tipo de placa de rede, teclado, pacotes a serem instalados, número IP da estação e do gateway, endereço IP do servidor de nomes e várias outras alternativas.

Este documento discute um subconjunto das opções disponíveis de instalação através do modo kickstart. Para maiores informações consultar o guia de instalação do Red Hat Linux, apêndice H (http://www.dicas-l.com.br/linux/rhl-instguide.pdf) Outra fonte útil de referência é o documento Kickstart-HOWTO distribuído juntamente com sistemas Red Hat Linux (/usr/doc/HOWTO).

2. Quando usar?

A opção kickstart de instalação do Red Hat Linux e derivados é interessante quando o administrador de redes necessita configurar um grande número de máquinas que possuem uma configuração de hardware semelhante. Desta forma a maior parte da instalação transcorre sem a necessidade de intervenção humana e apenas os ajustes finais são feitos manualmente.

Como exemplo podemos citar a configuração de equipamentos em laboratórios de ensino, pré-instalação do Linux em máquinas recém-adquiridas antes da entrega ao usuário final e realização de upgrades de versão.

3. Arquivo de configuração

O arquivo onde são especificadas todas as opções para instalação do sistema Linux chama-se ks.cfg. Linhas iniciadas em # são tratadas como comentários. O arquivo abaixo foi utilizado para instalação do Conectiva Red Hat Linux em um micro IBM/PC 486. 66MHZ, 32 MB de memória:

 lang pt_BR network --bootproto static --ip 143.106.20.73 --netmask 255.255.255.192 --gateway 143.106.20.65 cdrom device ethernet ne --opts "io=0x300, irq 5" keyboard br-abnt2 zerombr yes clearpart --all part / --size 500 --grow part swap --size 64 install mouse --kickstart generic3ps/2 --emulthree timezone --utc Brazil/East xconfig --server "SVGA" --monitor "lg studioworks 55i" rootpw --iscrypted a1veRaxg0oW/. lilo --location mbr %packages @workstation %post # acrescentar comentário ao arquivo /etc/motd echo Sistema Instalado em modo Kickstart em ""< }/bin/date""{ > > /etc/motd # acrescentar diretiva search ao arquivo /etc/resolv.conf echo search unicamp.br ccuec.unicamp.br 

Vamos agora analisar as opções selecionadas:

lang pt_BR

Esta opção seleciona o idioma de instalação, português do Brasil

network --bootproto static|dhcp|bootp --ip 143.106.20.73 --netmask 255.255.255.192 --gateway 143.106.20.65

Aqui temos as opções de configuração IP da máquina. O endereço IP é atribuído estaticamente, sem o uso de servidores DHCP. O endereço IP da máquina é 143.106.20.73, sua máscara de rede é 255.255.255.192 e o gateway da rede onde esta estação de trabalho se encontra é 143.106.20.65.

cdrom|nfs --server nome.do.servidor --dir /caminho/da/imagem/redhatlinux

A instalação será feita a partir de um cdrom

device ethernet ne --opts "io=0x300, irq 5"

A placa de rede é do tipo ne2000 ou compatível e está configurada para utilizar o endereço 0x300 e a interrupção de número 5. Esta informação pode ser obtida através do disquete de configuração normalmente distribuído com a placa de rede.

keyboard br-abnt2

Tipo de teclado. Esta opção, br-abnt2, é a utilizada pelos teclados nacionais. Normalmente apenas o Conectiva Red Hat Linux suporta esta opção.

zerombr yes|no

Indica se o MBR (Master Boot Record) deve ser totalmente apagado. Esta opção é a recomendada para novas instalações. Em máquinas onde existam partições válidas que se queira preservar utilizar ``zerombr no''.

clearpart --all|linux

Sinaliza se todas as partições existentes no equipamento devem ser apagadas.

part / --size 500 --grow

A diretiva part faz a alocação das partições de seu sistema Linux. Neste caso está sendo alocada a partição root com tamanho de 500MB. A diretiva --grow indica que, se ao final do processo de alocação de todas as partições ainda restar algum espaço livre, este espaço será acrescido ao tamanho especificado originalmente.

part swap --size 64

Esta diretiva aloca o espaço de swap

install|upgrade

Será feita uma nova instalação (ou um upgrade)

mouse --kickstart generic3ps/2 --emulthree

Especificação do mouse, tipo PS/2, com dois botões, com suporte à emulação de três botões.

timezone --utc Brazil/East

Região geográfica

xconfig --server "SVGA" --monitor "lg studioworks 55i"

Especificação do tipo de placa de vídeo e monitor

rootpw --iscrypted a1veRaxg0oW/.

A senha do usuário root pode ser incluída de forma encriptada, como acima, ou não. A senha, caso criptografada deve ser precedida da diretiva --iscrypted.

lilo --location mbr

O LILO (Linux Loader) será instalado no registro mestre de boot (MBR). Este é o default.

@workstation|@server

Neste seção especificamos os pacotes a serem instalados. Podemos fazer uma especificação mais genérica, como em nosso exemplo, ou especificar separadamente cada pacote que desejamos instalar. No Conectiva Linux versão 4.0 são os seguintes os valores possíveis, além dos já especificados acima:

 Base X Window System Mail/WWW/News Tools File Managers X multimedia support Console Multimedia Networked Workstation Dialup Workstation KDE 

Na especificação no arquivo ks.cfg preceder os valores acima do caracter ``@''.

Incluir nesta seção os comandos que você deseja executar após o fim da instalação. Exemplo:

 # acrescentar comentário ao arquivo /etc/motd echo Sistema Instalado em modo Kickstart em ""< }/bin/date""{ > > /etc/motd # acrescentar diretiva search ao arquivo /etc/resolv.conf echo search unicamp.br ccuec.unicamp.br 

4. Como Instalar em modo Kickstart

4.1. Através do disquete de boot

Para utilizar o disquete de boot basta copiar o arquivo ks.cfg criado para o disquete de boot. No Linux isto pode ser feito através do comando mcopy visto que este disquete está no formato MS-DOS (FAT). A cópia pode também ser feita a partir de um sistema DOS.

Isto feito, inserir o disquete no drive a: de seu computador. Ao aparecer o prompt

boot: linux ks=floppy

A partir deste ponto, se o seu arquivo ks.cfg estiver especificado corretamente, toda a instalação transcorrerá automaticamente.

4.2. Através da Rede

A instalação via rede requer a configuração de um servidor DHCP ou Bootp a partir do qual a estação de trabalho obtém suas informações de rede e a localização do arquivo kickstart. De posse destas informações o cliente tentará montar via NFS o sistema de arquivos com as informações que precisa. Esta opção de instalação será abordada em maiores detalhes nas próximas versões deste documento.

5. Geração Automática do Arquivo ks.cfg

O pacote mkkickstart permite a criação automática do arquivo ks.cfg. Este programa obtém a configuração de seu sistema automaticamente e cria um arquivo ks.cfg apropriado. É recomendável que o arquivo ks.cfg gerado seja examinado para verificar se todos os parâmetros codificados estão adequados.

O pacote mkkickstart pode ser encontrado em

http://ftp.unicamp.br/pub/conectiva/conectiva/RPMS/mkkickstart-1.2-2cl.noarch.rpm

Fonte: http://www.dicas-l.com.br/print/19990922.html

Configuração de rede sob Windows95

Colaboração: Rubens Queiroz de Almeida

Uma maneira bastante rápida de se verificar a configuração de rede de um micro rodando Windows95 é executar o comando winipcfg.

Para executar este comando selecione a opção "Run" ou "Executar" da barra de tarefas do Windows 95 e digite winipcfg.

Será exibida uma tela com as configurações de rede de seu micro (endereço IP, gateway, servidor DNS, etc.)

Bem mais rápido que obter esta informação através da opção rede do painel de controle.

Fonte: http://www.dicas-l.com.br/print/19970822.html

Como configurar mais de uma interface de rede no Solaris

Colaboração: Elaine Cristina Franchini

Solaris 8

• Obtendo informacoes sobre todas as interfaces de rede :

   # ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.3 netmask ffffffc0 broadcast 192.168.10.63 ether 8:0:20:b0:c:a0 

   

• Configurando a segunda interface de rede hme0:1 (A lo0 e' o loopback) :

   

   # ifconfig hme0:1 192.168.10.13 plumb # ifconfig hme0:1 192.168.10.13 netmask 255.255.255.255 up 

   

• Verificando novamente as interfaces :

   

   lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.3 netmask ffffffc0 broadcast 192.168.10.63 ether 8:0:20:b0:c:a0 hme0:1: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.13 netmask ffffffff broadcast 192.168.10.13 

   

• Para desabilitar a segunda interface de rede : (caso seja necessario !!)

   

   # ifconfig hme0:1 192.168.10.13 down # ifconfig hme0:1 192.168.10.13 unplumb 

   

• Para manter a segunda interface de rede apos o boot da maquina, e' preciso acrescentar a linhas no final do script /etc/rc2.d/S69inet : (faça uma copia de seguranca do script antes !!!)

   

• Configurando a segunda interfaca de rede hme0:1

   

   ifconfig hme0:1 192.168.10.13 plumb ifconfig hme0:1 192.168.10.13 netmask 255.255.255.255 up 

   

  ==Solaris 7==

   

• Obtendo informacoes sobre todas as interfaces de rede :

   

   # ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.3 netmask ffffffc0 broadcast 192.168.10.63 ether 8:0:20:b0:c:a0 

   

• Configurando a segunda interface de rede hme0:1 (A lo0 e' o loopback) :

   

   # ifconfig hme0:1 192.168.10.13 netmask 255.255.255.255 up 

   

• Verificando novamente as interfaces :

   

   lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.3 netmask ffffffc0 broadcast 192.168.10.63 ether 8:0:20:b0:c:a0 hme0:1: flags=843<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.13 netmask ffffffff broadcast 192.168.10.13 

   

• Para desabilitar a segunda interface de rede : (caso seja necessario !!)

   

   # ifconfig hme0:1 192.168.10.13 down 

   

• Para manter a segunda interface de rede apos o boot da maquina, e' preciso acrescentar a linhas no final do script /etc/rc2.d/S69inet : (faça uma copia de seguranca do script antes !!!)

   

• Configurando a segunda interfaca de rede hme0:1

   

   ifconfig hme0:1 192.168.10.13 netmask 255.255.255.255 up 

Fonte: http://www.dicas-l.com.br/print/20040431.html