Olá, eu sou linuxdicas
Ver o meu perfil


Dezembro 2007

SMTW TFS
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

Tag

Últimos comentários

Últimos artigos

Os meus links favoritos

    Divulga os conteúdos

    Juntar a MyDada

    Juntar a MyDada

    Partilha os teus conteúdos

    De.licio.us
    Tag assim

    Pipes em bash

    by linuxdicas (09/12/2007 - 18:55)

    Pipes em bash

    Colaboração: Rodrigo Bernardo Pimentel <<rbp (a) sp conectiva com br>>

    As ferramentas de Unix surgiram com o conceito de "seja simples, faça bem o que tem a fazer, saiba conversar com outras aplicações". Bem, parte dessa última premissa é realizada com o uso de "pipes". "pipes" (utilizados com o caracter '|') conectam a saída de uma programa à entrada de outro. Ou seja, funcionam como um "tubo" ou "cano" mesmo.

    Por exemplo: o comando "cat" joga na saída padrão o conteúdo de um arquivo. O comando "cut" mostra só uma parte especificada do texto que lhe é passado como entrada padrão. Assim, para conseguirmos uma lista de usuários do sistema, podemos fazer

     [rbp@muppets ~]$ cat /etc/passwd | cut -d : -f 1 = 

    O comando "cat /etc/passwd" jogaria na tela todas as linhas do arquivo /etc/passwd.

    O comando "cut -d : -f 1" divide cada linha da entrada utilizando o ":" (dois pontos) como separador e pega o primeiro campo (com "-d :" e "-f 1" respectivamente). Assim, em uma linha do /etc/passwd normal, os campos seriam

     rbp:x:500:500:Rodrigo Bernardo Pimentel:/home/rbp:/bin/bash 1 2 3 4 5 6 7 

    Ou seja, o primeiro campo é o login.

    Assim, o pipe usa a saída do primeiro comando para fornecer uma entrada para o segundo, e o resultado é o campo de login de cada linha do /etc/passwd.

    Outro exemplo, envolvendo mais pipes (ou seja, você pode usar mais de um pipe de uma vez):

     [rbp@muppets ~]$ w | grep '^rbp ' | wc -l = 7 [rbp@muppets ~]$ = 

    O comando "w" lista os usuários conectados na máquina. O comando "grep '^rbp '" pega essa lista e mostra só as que começem com "rbp " (para não pegarmos substrings como 'rbpsdgf'). Finalmente, o comando "wc -l" conta essas linhas. Assim, sei que, no momento, o usuário rbp tem 7 shells abertos na máquina (dia fraco... ;) .




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

    Vota este artigo

    Semana 4Linux: A Importância da Segurança na Kernel Space

    by linuxdicas (03/12/2007 - 04:04)

    Semana 4Linux - A Importância da Segurança na Kernel Space

    Colaboração: Tiago Luiz Maruyama

    Em um passado não muito distante, um servidor configurado corretamente tinha seus riscos de ser invadido, mas esse risco era fisicamente dimencionado até os limites da sua rede local. Mas nos dias de hoje isso não é mais possível, por causa da chegada da Internet.

    O grande crescimento de computadores interconectados, o crescimento de serviços virtuais e a quantidade de softwares com finalidades ilícitas, trazem como consequência a preocupação de se defender dessas pessoas mal intencionadas que posso utilizar esses softwares que tentam de várias formas invadir seu computador.

    Existem vários aplicativos voltados a detectar a invasão do seu sistema, mas existem dois tipos de IDS, o que trabalha na user space (nível de usuário) ou kernel space (nível de kernel).

    Podemos dizer que os IDS do tipo tripware que trabalha na camada de usuário podem ser mais vulneráveis, sendo assim burlados com mais facilidade, porque a maioria desses IDS tem arquivos de configuração, onde é informado , quais diretórios ou arquivos que precisam ter a proteção do IDS.

    Caso a pessoa que efetuar a invasão não precisar fazer nenhuma alteração em arquivos, que estão relacionados no arquivo de configuração do IDS, somente fizer alterações em arquivos não configurados no IDS ou na camada de kernel ela possivelmente ela não será notada,tudo depende do contexto como o acesso arbitrário ocorreu.

    Já com um sistema configurado com um IDS que esteja na camada de kernel, a dificuldade aumenta porque tudo o que a pessoa estiver tentando executar, gerará uma chamada no kernel(systemcall), assim como o IDS está na camada de kernel, todas as chamadas feitas geram mensagens de logs.

    O registro das atividades dos usuários e serviços dos sistemas é, notoriamente, muito importante para os administradores e como foi citado o fato de todas as chamadas ao sistema que são negadas serem registradas, cria um cenário muito importante para auditorias futuras.

    A importância de registro dos eventos do sistemas é tanta, que na norma NBR ISO/IEC 17799, o item 9.7.1 é todo dedicado ao "Registro (log) de eventos. Deixando claro que registro de eventos são também prioridade em uma política de segurança.

    Em um sistema de log, oficialmente somente o root poderia alterar os arquivos de log, já com o Lids aplicado, nem o root teria o poder de alterar esses arquivos.

    Lids é um path de segurança no nível de kernel, ou seja, é necessário a recompilação do kernel para a aplicação do path. Esse patch pode ser encontrado no site oficial do LIDS "www.lids.org" e o fonte do kernel em "www.kernel.org"

    As ferramentas que acompanham o patch do Lids "lidsadm e lidsconf" são fáceis de utilizar e de configurar, elas estão no nível de usuário e servem para configurar as ACLs que serão determinadas pelo root, que, dependendo da configuração das ACLs do Lids, não será mais o dono do sistema, mas sim somente um usuário comum.

    Como o Lids está no nivel de kernel, ele é acionado já no início do boot do sistema, portanto, já na inicialização o sistema se encontra protegido.

    Com esse sistema de proteção no boot, ela nega permissão a muitos serviços padrões do sistema, como o dmesg, que gera um relatório de todo a inicialização do kernel. Isso é muito importante, por isso que se deve liberar o dmesg a gravar no diretório /var/log/.

     # lidsconf -A BOOT -o /var/log/dmesg -j WRITE 

     

    Todos sabem que o arquivo /etc/shadow contém as senhas de todos os usuários do sistema e que as senhas estão criptografadas. Mesmo assim, existe um grande risco de alguém descobrí-las.

    Por esse motivo, o LIDS trabalha da seguinte forma: ainda como usuário root é possivel determinar que nenhum binário vá conseguir o acesso a esse arquivo de senhas, colocando uma regra de DENY (proibido), por exemplo:

     # lidsconf -A -o /etc/shadow -j DENY 

     

    Mas o mais importante é que para toda regra existem as exceções, podendo assim liberar qual binário poderá acessar o /etc/shadow como READONLY (somente leitura). Um exemplo claro, seria o binário /bin/login, que precisa ter permissão de leitura no arquivo para que possa efetuar o login normalmente.

     # lidsconf -A -s /bin/login -o /etc/shadow -j READONLY 

     

    Mas caso se tente visualizar o conteúdo do arquivo com outros binários (por exemplo: vi, cat, more, etc..), o IDS acusará que esse arquivo não existe.

    Da mesma que é possivel proibir o acesso as arquivos para todos os binários e liberar para alguns, também existe a possibilidade de ocultar processos, isso mesmo esconder os processos. Veja por exemplo como ocultar o processo do serviço ssh.

     # ldisconf -A -s /usr/sbin/sshd -o CAP_HIDDEN -j GRANT 

     

    Quando tentar listar os processos da máquina, esse processo do serviço ssh não aparecerá, mas o serviço está ativo.

    Diante desse poder de fogo sugiro como a melhor opção seria utilizar os dois sistemas de IDS, para que vc esteja protegido na camada de usuário e na camada de kernel. Assim dificultado em muito possiveis atividades arbritárias.

    Mesmo hoje tendo recursos como LIDS e outros como o SELinux, GrSecurity, devemos pensar sempre de forma estratégica em tudo que for possivel e viável tanto na Kernel Space como na User Space, pois em algumas situações como uma estação de trabalho fica impraticavel o uso de um recurso com LIDS.

    O Lids também é um mecanismo a mais para aumentar o nível de segurança de um sistema operacional buscando atender também as diretrizes inerentes ao nível C2 de segurança no que diz respeito o Sistema Operacional.

    O nivel C2 recomendado pelo TCSEC " Trusted Computer System Evaluation Criteria", que é nível de segurança minimo requerido pelo governo Americano e utilizada em algumas instituições no Brasil.

    Outro valor agregado nessa história é que somente conhecendo profudamente como o sistema funciona e as respectivas aplicações que estejam sendo executadas, conseguimos tirar proveito de um recurso como LIDS, pois do contrário simplesmente nada vai funcionar corretamente, ou seja, além de melhoramos a segurança do sistema e aprendemos muito a emoção é grande :-).


    Novidade: O curso ** "Segurança em Servidores Linux usando a BS7799 " ** da 4linux mostra como fazer customizações no sistema Linux objetivando melhorar sua segurança, buscando correlacionar as ações no sistema com as recomendações da norma internacional BS7799. Esta norma é utilizada pois é focada em Segurança deInformação e apesar de tratar de vários ativos iremos focar apenas o ativo software, dessa forma o foco será nos itens da norma relacionados a Software.

    Saiba mais no site http://www.4linux.com.br/treinamento/security_415.php ou ligue para (011) 2125-4747




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

    Vota este artigo

    GMail como gerenciador de emails externos

    by linuxdicas (03/12/2007 - 02:56)

    GMail como gerenciador de emails externos

    Colaboração: Luiz Gonzaga dos Santos Filho

    Recentemente (mas nem tanto) o GMail lançou uma nova funcionalidade: gerenciar contas de email externas a ele (por exemplo, emails do Yahoo, hosts próprios, etc).

    Assim, o GMail passa a se comportar com um Thunderbird, Evolution, Kontact ou (cof cof) Outlook da vida.

    1. Como configurar

    Para configurar essa funcionalidade:

    1. Clique em "Configurações" lá no topo da página
    2. Clique em "Contas"

    Agora você se deparará com duas seções:

    "Enviar e-mail como: (Use o Gmail para enviar mensagens a partir de seus outros endereços de e-mail.)"

    e

    "Pegar mensagens de outras contas: (baixar e-mails usando POP3)"

    Dispensa explicações, né? :-)

    A partir daqui tudo é muito intuitivo...

    2. Para enviar emails como se fosse da outra conta:

    1. Clique em adicionar

       

    2. Abrirá um pop-up lhe pedindo o nome (nome que será exibido quando você enviar mensagens através daquela conta)

       

    3. Preencha os dados e clique em avançar.

    Ele enviará um email de confirmação para este email externo, pra confirmar que você é você e não outra pessoa. :-D Cheque este email e confirme clicando no link, ou copiando o código no corpo do email e colando na janelinha pop-up que ficou aberta... Seja feliz!

    3. Para receber emails da outra conta no gmail:

    1. Clique em adicionar
    2. Abrirá um pop-up lhe pedindo o email da conta que ele irá baixar os emails
    3. Preencha os dados e clique em avançar
    4. Nesta nova tela, preencha os dados como se você fosse logar na outra conta Obs: Se você não sabe o endereço pop3 da sua conta, entre nas opções / ajuda do seu webmail que provalmente lá tem. Para contas yahoo, esse endereço é: pop.mail.yahoo.com
    5. Escolha as opções de acordo com o seu gosto/necessidade. Seja feliz!

    4. Dicas

    Se sua conta não lhe permite acesso pop, verifique se ela oferece REDIRECIONAMENTO, assim não é preciso o pop: você configurar para redirecionar para o seu gmail, aplica os marcadores que quiser e pronto!

    5. Vantagens

    Porque fazer isso? Se você tem mais de uma conta de email provavelmente usa soluções como Thunderbird, Evolution, Kontact, Outlook ou outros gerenciadores de email. Eu, gerenciando 5 contas de emails diferentes, não vivia sem um. Sempre preferi o webmail, pelas seguintes razões:

    • Ser mais leve (geralmente você já está com o navegador aberto mesmo... :-))

       

    • Você pode acessar de qualquer lugar que seu email estará lá. Geralmente as pessoas que usam gerenciadores de email optam por apagar as mensagens do servidor quando baixam para sua máquina para evitar replicação, e não ir consumindo inultimente o espaço da conta... Daí diante da necessidade de ver aquele email longe de casa te deixa frustrado.

       

    • Não baixar emails que você não vai ler. Hoje em dia é cada vez mais comum duas pragas da internet: spam e .pps (as vezes o próprio .ppt! :-P) Assim, você não precisa gastar seu hd e sua conexão baixando aquela corrente de 2 megas se você não irá lê-lo. Idem para os spams.

       

    • Facilidade para encaminhar mensagens. Em programas gerenciadores de email, quando você quer encaminhar um certo email para sua lista de amigos, você tem que re-enviar a mensagem toda, gastando sua conexão. Se for aquele email legal com o vídeo da última sensação da internet então, torna-se desencorajador encaminhar emails... No webmail, como a mensagem já está lá no servidor, a mensagem é encaminhada sem a necessidade de fazer upload dela novamente, pois não há mais o caminho servidor -> seu pc -> servidor -> email do seu amigo, reduzindo para servidor -> email do seu amigo.

    6. Vantagens do GMail em particular

    As vantagens acima servem para qualquer tipo de webmail, mas ainda temos as vantagens já conhecidas por nós do gmail:

    • Filtro de spam eficiente
    • Aninhamento de réplicas a um mesmo email (agrupamento)
    • Rapidez

       

    • É uma solução Web 2.0 exemplar que roda na maioria dos navegadores. Diferente, por exemplo, do novo yahoo mail, que exige navegadores bem atuais para rodar e mesmo assim ficando um pouco pesado...

       

    • Integração com gtalk, orkut, googlevideo, documentos, planilhas, enfim: qualquer serviço google lançado ou ainda a ser lançado



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

    Vota este artigo

    Usando o Kismet

    by linuxdicas (02/12/2007 - 17:17)

    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

    Vota este artigo

    Criando delay pools(PROXY/SQUID)

    by linuxdicas (01/12/2007 - 21:23)

    Criando delay pools(PROXY/SQUID)

    Colaboração: Felipe Augusto Batista Reis

    Neste tutorial vamos ver como se usa as delay pools. Delay pools é uma opção usada no squid para fazer limite de banda, neste tutorial vamos nos concentrar apenas em delay pools, delay class, delay access e delay parameters. Este tutorial já leva em conta que você já tenha algum conhecimento em squid, sendo porém expansivel também a quem está apredendo a usar o squid.

    Este tutorial vamos como exemplo duas delay pools. Seguindo assim uma linha muita usada com delay pools, vamos neste tutorial, usar as delay pools em nossa rede interna e para internet.

    Leve em conta que temos duas acl's criadas com os nomes de "extensoes" e "interno". Essas acl's serão usadas em nosso tutorial.

     acl extensoes url_regex -i .* 

     

    esta acl que criamos está pegando tudo que é relacionado a ponto ou seja, inclusive extensões html, jpeg, jpg, gif, php, png, htm e etc... Que são usadas em paginas de internet. se você quer bloquear tudo menos estas extensões faça assim...

     acl extensoes url_regex -i .* !.html !.htm !.php !.jpeg !.jpg !.png !.gif e etc....... 

     

    bloqueamos tudo exceto as seguintes extensões. Mas se o seu interesse é bloquear arquivos como mp3, avi, faça o seguinte.

     acl extensoes url_regex -i .exe$ .mp3$ .vqf$ .tar.gz$ .gz$ .rpm$ .zip$ .rar$ .avi$ .mpeg$ .mpe$ .mpg$ .ram$ .rm$ .iso$ .raw$ .wav$ .mov$ 

     

    você também pode criar-las em um arquivo.

     acl extensoes url_regex -i "caminho do arquivo" 

     

    coloque as extensões dentro deste arquivo(mas apenas uma extensão por linha).

     acl interno url_regex -i 192.168.1.0 

     

    delay_pools:

    Está opção especifica o número de delay pools que você vai possuir, por exemplo, se você possui 2 delay pools, este número deve ser igual a 2, se você tem 3 delay pools, este número deve ser igual a 3, e assim por diante.

    delay_pools (número de delay pools)

    delay_pools 2 #isto significa que nós possuimos 2 delay's pools.

    Como dito acima, o número de delay pools que vamos criar.

    delay_class:

    Define a classe de cada delay pool. Deve haver exatamente uma delay class para cada delay pool.

     delay_class (número da delay pool) (número da classe da delay poll) delay_class 1 2 #isto significa que a delay pool 1 é uma delay class 2 delay_class 2 2 #isto significa que a delay pool 2 é uma delay class 2 

     

    Como visto acima, nós temos duas delay pools e duas delay class, e também podemos ver que nossas delay class são todas classe 2. Não esqueça, o primeiro número é sua delay pool, e o segundo é a sua delay class.


     

    delay_access:

    Determina em qual delay pool uma requisição será encaixada. A primeira a combinar será utilizada, por isso verifique com cuidado suas acls.

    delay_access (número da delay poll) allow|deny nome da acl

     delay_access 1 allow extensoes #estamos direcionando nossa delay pool 1(que é uma classe 2) para a acl palavras. delay_access 2 allow interno #fazendo o mesmo que acima, porém para a acl interno(que também é uma classe 2). 

     


     

    delay_parameters:

    Define os parâmetros para uma delay pool. Cada delay pool tem um número de alocação de tráfego associado.

     delay_parameters (número da delay pool) agregado (delay_class 1) delay_parameters (número da delay pool) agregado individual (delay_class 2) delay_parameters (número da delay pool) agregado network individual (delay_class 3) 

     

    Aqui vou mostrar apenas a saída da delay class 3 pois está engloba todas a opções.

     delay_parameters 1 -1/-1 24000/24000 1000/1000 

     

    vamos ao significado:

     -1/-1: 

     

    Valor AGREGADO:aqui especificamos quanto toda a banda vai utilizar, no caso -1/-1 significa valor ilimitado, por isso, se você quer limitar sua banda nunca coloque -1/-1.

     24000/24000: 

     

    Valor NETWORK(REDE):aqui especificamos quanto cada uma de nossas redes irá poder utilizar, no caso algo em torno de 23Kb/s.

     1000/1000: 

     

    Valor INDIVIDUAL:aqui especificamos quanto cada um de nossos usuários poderá utilizar, no caso menos de um 1K/s.

    Cada valor tem duas areás, uma antes da barra e outra depois. Vamos lá.

    RESTORE:O antes da barra.

    Especifica quantos bits poderão tráfegar por segundo.

    MAX:O depois da barra.

    Especifica quantos bits poderão trafegar no total.

    Delay pools sempre trabalham com bits, não se esqueça.

     delay_parameters 1 -1/-1 500/1000 #leia acima para entender. delay_parameters 2 -1/-1 15000/25000 #leia acima para entender. 

     

    TUDO FICARIA ASSIM.

     acl extensoes url_regex -i .exe$ .mp3$ .vqf$ .tar.gz$ .gz$ .rpm$ .zip$ .rar$ .avi$ .mpeg$ .mpe$ .mpg$ .ram$ .rm$ .iso$ .raw$ .wav$ .mov$ acl interno url_regex -i 192.168.1.0 delay_pools 2 delay_class 1 2 delay_parameters 1 -1/-1 500/1000 delay_access 1 allow extenões delay_class 2 2 delay_parameters 2 -1/-1 15000/25000 delay_access 2 allow interno 

     

     flipeicl@hotmail.com flipe@hyperlinux.com.br HyperLinux -- www.hyperlinux.com.br -- consultoria, soluções e suporte em Linux Bhz. MG BRASIL. 

     




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

    Vota este artigo

    Guia para o Novato em Linux

    by linuxdicas (29/11/2007 - 02:14)

    Guia para o Novato em Linux

    Colaboração: Alex-Gurgel <<Gurgel (a) linuxdicas com br>>

    Pois bem, depois de muito pensar você resolveu se aventurar pelo mundo Linux! Parabéns! Mas ai começam as duvidas e os problemas: Qual distribuição usar ? Vai funcionar no meu micro ? Onde posso conseguir os CDs ?

    Calma! Este artigo foi escrito com o intuito de ajudar você, novo usuário do Linux, a responder essas e outras perguntas. Antes de começar, apenas um detalhe importante: este artigo não vai responder a todas as suas duvidas, vai apenas lhe dar um ponto de partida.

    Antes de mais nada: como você pretende entrar no mundo Linux ? Quer instalar ou preferia que tivesse outro modo ? Bem, existe outro modo sim: as distribuições que rodam diretamente dos CDs, sem instalar ou modificar nada no seu micro! Pode ser interessante, testar o que é o Linux e depois instalar para realmente aproveitar todo o potencial deste Sistema Operacional.

    Se essa for sua escolha, faça o seguinte: acesse a Internet, vá a um site de busca e procure por 'kurumin' (em português) ou 'knoppix' (em dinamarquês ou inglês). Baixe os arquivos ISO de uma delas, a sua escolha, grave um CD e está pronto! Basta agora dar boot no seu micro, com o CD colocado, que, em poucos instantes, você estará testando seu Linux. Claro, nos sites dessas distribuições existe farta documentação sobre eles, leia tudo o que puder. Quando se decidir por, finalmente, instalar um Linux volte para esse artigo.

    Ah, você prefere instalar o Linux no seu micro! Pois bem, para começar, é preciso lhe explicar uma coisa básica: o Linux é um Sistema Operacional que exige uma coisa a mais que outros SO's: que você use o seu cérebro !

    Do princípio: você já se decidiu a experimentar o Linux. Mas aonde você vai encontrar as informações iniciais: Ah sim, você já procurou na Internet e encontrou vários sites sobre o assunto, vários deles com fóruns! E o que você vai fazer agora ? Algumas dicas iniciais:

    • Acesse os fóruns que você encontrou, eles são uma fonte valiosa de informações vinda de pessoas que passaram por varias etapas no aprendizado do Linux.

       

    • Quando fizer uma pergunta procure não usar apenas letras maiúsculas. Isso equivale a gritar com os outros. E você não gosta que gritem com você, não é mesmo ?

       

    • Evite perguntar "Qual a melhor distribuição ?". Essa pergunta vai, com certeza, gerar um volume de discussões que podem não lhe responder exatamente o que você quer saber. No fundo, a sua verdadeira duvida é: "Qual distribuição eu vou gostar mais ?". Isso apenas você pode responder. Na maior parte das vezes a resposta que você vai ter será algo como "A melhor distribuição é aquela que se adaptar melhor a você."

       

      Aqui vai um bom conselho: providencie uma distro, qualquer uma, e instale. Teste por algum tempo, providencie outra, instale, teste e assim por diante. Antes que você se de conta você já estará usando bem o Linux e terá se decidido por uma distribuição !

       

      Ok, mas, mesmo assim, você quer saber qual a diferença entre elas ? Tudo bem, ai vai a resposta: a bem da verdade, nenhuma. O Linux em si é o mesmo. Afinal, o Linux é apenas o núcleo, o kernel do sistema. Claro, apenas com ele não se faz nada. O resto dos programas que compõe uma distribuição é que faz a diferença entre elas. Mas esses programas( no Linux chamamos os programas de pacotes) não são Linux ? Não. Eles são softwares, livres ou não( Open-Source, código aberto, ou proprietários), agrupados por uma empresa que, em conjunto com o Linux, dão a forma final a uma distribuição. Esse conjunto pacotes/Linux normalmente é chamado de GNU/Linux.

       

      Apenas como exemplo, podemos comparar esse conjunto ao hardware do seu computador. O processador( Linux) é o computador em si, mas você não faz nada apenas com o computador. Ao montar um micro, você acrescenta itens de diversos fabricantes, como memória, placa-mãe, HD, unidade de CD-Rom, disquete( pacotes) obtendo, assim, um conjunto que convencionamos chamar de computador (GNU/Linux). Simples, não ?

       

      Prosseguindo. Agora você já decidiu que distribuição usar, o que fazer agora ? Onde podemos encontrar uma descrição do modo de instalação ? Lembra dos fóruns que você descobriu ? Não, não, nem tente perguntar como instalar o Linux! Ou você vai obter muita informação ou nenhuma! Mais prático: todos os fóruns tem uma ferramenta de busca. Ela permite que você localize, no fórum, a informação desejada com facilidade. Use-a. Com certeza você vai descobrir que alguém, algum dia, em resposta a uma pergunta qualquer, informou um link para a documentação que você precisa.

       

      Achou a documentação ? O que ? Ela esta em inglês e seu inglês é muito fraco ? Isso pode se tornar um problema, a longo prazo. Tudo bem, lembra que dissemos que o Linux e sempre igual, o que muda são os pacotes que o acompanham ? Pois bem, você pode perfeitamente pegar um manual de outra distribuição( em português, claro)e instalar a sua a partir do que essa documentação lhe informar. Nesse ponto, cuidado! Supondo que você tenha se decidido pela distribuição Slackware ou pela Debian esse processo não vai dar muito certo. Felizmente para isso tem solução. Procure na Internet, use os sites de busca, que você vai encontrar sites com as informações que você precisa sobre essas distribuições em bom português !

       

      Agora, que você já instalou sua distribuição escolhida posso explicar algumas coisinhas importantes.

       

    • Primeiramente, pode acontecer de algum item do seu computador não funcionar de imediato com o Linux. Nesse caso o que fazer ? De novo, vamos aos fóruns! Novamente, não pergunte coisas como: "Sou novato em Linux, como fazer para o hardware xxx funcionar no meu Linux ?" Em 90% dos casos alguém já perguntou isso e, possivelmente, já teve resposta. De novo, use a ferramenta de busca que o fórum lhe oferece.

       

    • Não achou o que precisa ? Certo, nesse caso vamos perguntar o que fazer! Mas pergunte direito: informe qual distribuição você tem, diga exatamente qual o seu hardware e, o mais importante: seja preciso na sua pergunta.

       

    • Agora você já tem a informação que precisa mas, mesmo assim, não funciona. Não adianta perguntar "Instalei o pacote xxx mas meu yyy ainda não funciona. O que fazer ?" Diga o que você já tentou, qual o distribuição, qual o hardware e, o mais importante, quais as mensagens que o sistema lhe fornece. Essas informações são básicas para que os freqüentadores dos fóruns tenham um mínimo de base para te ajudar.

       

    • Você conseguiu a ajuda necessária e tudo funciona agora ? Excelente !! Não se esqueça de retornar ao fórum e informar que seu problema foi resolvido. Diga o que você fez para resolver, a partir das informações que você obteve. Isso vai ajudar novos usuários.

    Complementando: lembre-se de que alguns itens podem não funcionar no seu sistema, mesmo depois de muita ajuda. Duas possíveis causas: o item em questão não é mais suportado pelo Linux ou ainda não é suportado. Se for um item de baixo custo pode-se sempre pensar na sua troca por um que seja suportado. Se for um item de custo mais elevado pode-se aguardar que seja desenvolvido um pacote que permita seu funcionamento ou você mesmo pode desenvolver um processo. Neste último caso, não se esqueça de compartilhar sua descoberta com a comunidade Linux.

    Pronto! Agora você é um usuário Linux! O que ? Você ainda tem problemas ? Resolveu experimentar outra distribuição, instalou sem problemas mas seu modem( por exemplo) se recusa a funcionar ? Vejamos, o pacote que você usou para fazer seu modem funcionar não estaria desatualizado ? Você não teria se esquecido de instalar algum pacote importante (o pacote kernel-source é um bom exemplo) quando instalou o novo sistema ? Verifique esses pontos. Se o problema continuar, aonde você vai encontrar ajuda ? Isso mesmo ! Nos fóruns !

    Como ? Na verdade você simplesmente atualizou a distribuição por uma versão mais moderna ? E, ai, um item de hardware deixou de funcionar ? Certo, ele funcionava sem problemas antes. Voltamos a situação anterior. Será que o pacote que você instalou, para que aquele determinado item funcionasse, não estará obsoleto em relação a essa versão que você está usando agora ? E aonde você vai para conseguir ajuda ? Não, nos fóruns não! Pelo menos ainda não. Em primeiro lugar você deve ir ao site de onde você baixou aquele pacote pela primeira vez, pode ter uma versão mais atual. Depois sim, vá aos fóruns.

    Conforme você pode ver, a Internet, na figura dos sites sobre Linux e seus fóruns são aquelas entidades que irão funcionar como seus professores, permitindo que você tenha uma transição relativamente fácil, de Novo Usuário Linux para Usuário Linux. Mas nunca se esqueça: antes de perguntar pense, pesquise, leia a documentação disponível, experimente. Você vai aprender muito assim !




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

    Vota este artigo

    Implementando soluções com o OpenVPN

    by linuxdicas (20/11/2007 - 20:53)

    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:




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

    Vota este artigo