<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=(0063)http://www.linuxfocus.org/English/May2001/article202.meta.shtml --> <HTML><HEAD> <META content="text/html; charset=windows-1252" http-equiv=Content-Type> <META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD> <BODY> <H1>Através do Túnel</H1> <H4>ArticleCategory: [Choose a category for your article]</H4>System Administration <H4>AuthorImage:[Here we need a little image form you]</H4><IMG alt="[Photo of the Author]" height=124 src="/common/images/Georges-Tarbouriech.jpg" width=115> <H4>TranslationInfo:[Author and translation history]</H4> <P>original in en <A href="mailto:georges.t@linuxfocus.org">Georges Tarbouriech</A></P> <P>en to pt <A href="mailto:bruno@linuxfocus.org">Bruno Miguel</A></P> <H4>AboutTheAuthor:[A small biography about the author]</H4> <P>Georges é já um utilizador de longa data do UNIX (comercial e livre). Interessa-se em segurança e quer agradecer à comunidade pelo software livre e pelo trabalho feito nesta área. <BR></P> <H4>Abstract:[Here you write a little summary]</H4> <P><A href="http://www.ssh.com/">SSH</A>, a "shell segura", é um bom produto comercial. Contudo existem em bom número as versões livres de clientes e servidores ssh disponíveis para Unix (comercial ou livres) e para outros sistemas operativos (S.O.) <BR> A mais conhecida disponível em <A href="http://www.openssh.org/">http://www.openssh.org/</A>. A partir deste "site" encontrará numerosas alternativas para os sistemas Unix, Windows, Mac.. Alguns Produtos livres para o Windows são só os clientes.<BR> Neste artigo, apresentamos alguns exemplos em como usar o ssh como meio de fazer circular os dados gerados pelas aplicações. As VPN (Virtual Private Network) assentam no ssh mas de um modo diferente, num modo mais elaborado do que o abordado aqui. Uma outra solução sofisticada consiste no <A href="http://vtun.sourceforge.net/">VTun</A>. <BR> Assim, consideremos este túnel como um simples e fácil meio de encriptar os dados numa rede heterogénea prevenindo a sua intercepção. É óbvio que isto se aplica a redes locais como a remotas. Mas lembre-se que o ssh somente encripta os dados não protege a rede por si só... <BR>Foi Avisado ! </P> <H4>ArticleIllustration:[This is the title picture for your article]</H4><IMG height=135 hspace=10 src="/common/images/illustration202.gif" width=200> <H4>ArticleBody:[The article body]</H4> <H2>Porquê Utilizar o ssh?</H2> <P>O SSH é o substituto do telnet ou rsh, rlogin como já mencionado num <A href="http://www.linuxfocus.org/English/January2001/article180.shtml">artigo anterior</A>. Mesmo após a detecção de algumas falhas de segurança ainda continua a ser um bom utilitário para a encriptação dos dados. O problema acima descrito referia-se às palavras passe: é fortemente recomendado utilizar "frases passe" em vez das RSA ! O uso do ssh não nos previne de utilizar outros utilitários de segurança como o tcpwrapper. <BR> É muito fácil de interceptar os dados em circulação numa rede com utilitários standard como o tcpdump ou o snoop. Pode testar isto numa rede com duas máquinas a trocar dados, no uso do telnet por exemplo. Duma terceira máquina correndo Linux por exemplo corre-se o tcpdump (como root obviamente) e veja o que acontece. Pode ler todos os dados ! (Leitores é de notar que os três computadores precisam de estar conectados através de um hub para testar isto. Isto não funcionará se tiverem um switch mas o ponto de vista é válido.) <BR> É certo que o "display" é muito rápido para ser lido no ecrã, mas nada nos proíbe de redireccionar o output para um ficheiro e depois sermos capazes de o ler enquanto bebemos café. Se isto é verdade para os dados, é verdade para a palavra passe, ou seja a porta está aberta para os piratas. Você está-lhes a dar a sua chave de casa. <BR>Imagine que a circulação dos dados é confidencial... Se você for o administrador de sistema, eu temo que o seu patrão lhe peça para arranjar trabalho noutro sítio qualquer. <BR> Os Comandos remotos, rsh, rcp, rlogin são muito perigosos também, visto que os dados não são encriptados. O ssh é um bom substituto para o rlogin ou rsh e contém o scp que é um bom substituto para o rcp. Quer isto dizer que você não necessita dos comandos remotos ou telnet se usa o ssh, em última instância não o devia utilizá-lo. <BR>Como instalas o ssh, como gerar chaves privadas e públicas... este não é o objectivo deste artigo. Encontrareis tudo o que precisais no arquivo ssh ou lendo a documentação disponível acerca da matéria a partir do <A href="http://www.linuxdoc.org/">Projecto de Documentação do Linux</A>. <BR> Visto que a utilização de um computador nos nossos dias envolve a transferência de dados de um modo ou de outro o ssh devia ser obrigatório... Bem, mas é consigo. Contudo o ssh consegue fazer mais do que substitiur o ssh ou os comandos remotos. <BR>Pode ser usado para encriptar os dados transferidos entre aplicações externas e obviamente diferentes S.O.. Pode também comprimir os dados. É muito frequentemente utilizado com protocolos como o pop, ftp, http... quer para compressão ou encriptação. Isto é muito útil se você for administrador de sistema, por exemplo, e ligar-se de casa para o trabalho ou vice-versa. <BR>Sendo uma aplicação cliente/servidor, o ssh necessita, obviamente, de ambas para trabalhar. Necessita de uma máquina correndo um servidor ssh e uma máquina correndo um cliente ssh (Espero que tenha reparado no quanto esperto sou !). <BR>Porque insisto num facto óbvio? Porque, visto que estamos a falar acerca de software livre, muitos S.O. à parte do Unix não possuem servidores livres. Ou seja, por vezes não conseguirá fazer o essencial e terá de contornar o problema: a chave é o redireccionamendo. Falaremos desta vantagem mais tarde. O que significa que usando S.O. como Mac OS ou Windows implica que não terá servidores livres e terá de tratar dos clientes na mesma óptica. Como fazê-lo nem sempre é óbvio, Vejamos alguns exemplos reais. </P> <H2>SSH e o VNC</H2> <P> Se não conhece o VNC, então não sabe o que está a perder, um dos melhores utilitários de sempre, Pode dar uma olhadela <A href="http://www.linuxfocus.org/English/July2000/article155.shtml">aqui</A> para aprender mais. <BR>Se for até ao site do VNC <A href="http://www.uk.research.att.com/vnc/docs.html">http://www.uk.research.att.com/vnc/docs.html</A> encontrará muita documentação acerca do que se está a falar. Por exemplo encontrará como usar o VNC através do ssh, de um cliente ssh windows para um Unix ssh servidor. Consequentemente não vou re-escrever o bom trabalho de Frank Stajano, visto que é melhor do que eu faria. <BR>Vejamos então como isto pode trabalhar. <BR>Em primeiro lugar escolha um cliente livre para windows. Para este exemplo utilizaremos o Teraterm Pro, com a sua extensão Ttssh. Pode encontrá-lo em <A href="http://hp.vector.co.jp/authors/VA002416/teraterm.html">http://hp.vector.co.jp/authors/VA002416/teraterm.html</A>. Por acaso chama-se Ttssf, visto ser uma versão permitida em França. (As coisas estão a mudar, mas cuidado, muitos países ainda não aceitam a encriptação. Veja no seu próprio país através deste URL: <A href="http://www2.epic.org/reports/crypto2000/countries.html">http://www2.epic.org/reports/crypto2000/countries.html</A> .) <BR>Agora, suponhamos que lançou o servidor ssh numa maquina Unix. Na mesma máquina, suponhamos que pode correr o vncserver. Uma vez que os dois servidores estejam a correr, pode ligar uma máquina NT ao servidor Unix, usando o Ttssh. Isto significa que tem uma ligação encriptada entre as duas máquinas. Mas isto não nos permite correr um protocolo encriptado vncviewer (vnclient) a partir de uma máquina NT. Para tal é preciso dizer ao ssh para reencaminhar (e lá estamos nós) o porto correcto. <BR>A máquina Unix correndo o vncserver chama-se "bandit" e utiliza o porto 5901 porque é o display número 1 e por defeito o display X para este máquina é 0. O uso normal seria enviar o comando "vncviewer bandit:1". Claro que isto trabalhará mas sem os dados serem encriptados. Em vez de, usando a "shell" NT (digamos a interface DOS...), enviamos o comando "/ssh-L5902:bandit:5901" sem espaço. Isto significa que criou uma porta local 5902. Um comando, agora, como: "vncviewer localhost:2" corre com uma ligação encriptada sobre o protocolo VNC na sua máquina NT. Isto pode ser feito sem ter de recorrer à linha de comandos, visto que o Ttssh possui uma interface gráfica. Adicionemos que esta sintaxe só diz respeito ao Ttssh. Digitando o mesmo comando numa máquina Unix seria: "ssh -L 5902:bandit:5901 bandit". <BR>Este é claro um exemplo básico, poderá fazer coisas mais complexas. Verifique a documentação a partir do site VNC, em especial a de Frank Stajano. </P> <H2>SSH e o MySQL</H2> <P><A href="http://www.mysql.org/">MySQL</A> é provavelmente uma das DBMS mais usadas em especial na Internet. De novo a segurança do MySQL está fora do âmbito deste artigo. Contudo, encriptando os dados entre o servidor MySQL e o cliente MySQL torna a ligação mais segura. O ssh permite fazer tal, do mesmo modo que se fez com o VNC, ou seja o "redirecionamento dos portos". <BR>Digamos que o nosso exemplo diz respeito a uma Intranet. O MySQL é uma máquina Linux e a maioria dos clientes são máquinas NT. Mais uma vez usamos um cliente Ttssh nas máquinas windows. <BR>A porta por defeito do MySQL é 3306. Então reencaminhamos a mesma porta (3306). Poderá fazer um reencaminhamento local ou remoto. <BR>Um reencaminhamento local será algo como: "/ssh-L3306:localhost:3306" numa máquina NT ou "ssh -L 3306:localhost:3306" numa máquina Unix. Usando "localhost" permite que os dados sejam enviados através da interface de loopback em vez da máquina. <BR>Um reencaminhamento remoto seria: "/ssh-R3306:bandit:3306" para NT e "ssh -R 3306:bandit:3306" para Unix. <BR>Isto somente diz respeito à ligação em si. Para fazer "login" na DBM necessitará, obviamente, de enviar o nome da máquina e o id de utilizador para o servidor MySQL, provavelmente, diferente do id do utilizador da sua máquina. Investigue as páginas "man" acerca da opção "-l". <BR>Isto só trabalhará se tiver um cliente MySQL na sua máquina NT. <BR>Se não for o caso, terá de utilizar, uma aplicação ODBC, Sybase por exemplo. Inicie a aplicação e utilize um driver ODBC para se ligar ao MySQL. É agora possível conectar-se à máquina local e não à máquina servidor MySQL, para aceder ao servidor MySQL. Os dados que circulam entre o servidor e o cliente estão agora encriptados. Poderá verificá-lo com o tcpdump e o snoop. <BR>Isto é um exemplo numa rede local. Se sente a necessidade de aplicar isto nas WAN's, deverá encontrar um maior grau de complexidade se se encontra por detrás de uma firewall. Este pode ser um meio de fazer administração remota a partir de casa se for um administrador de sistema, mas não espere utilizar um método semelhante para acesso a DBM num website. Terá de procurar algo mais sofisticado, como por exemplo o VPN, mas esta é a ideia. <BR>Apesar de tudo, não acredite que isto é suficiente para ter um servidor DBM seguro para transferir dados como números de crédito ! E, já agora quem acredita realmente que possui um servidor seguro capaz de transferir este tipo de dados sem nenhum risco ? Pessoalmente, eu não!!! </P> <H2>SSH e a emulação de terminal</H2> <P>Que significa isto, visto já estarmos a utilizar uma emulação de terminal ? <BR>Suponhamos que corre uma aplicação Cobol velha num servidor Unix. Os cliente são novamente NT. Para se conectarem precisam de uma emulação de terminal mais sofisticada que o vt100, vt220, vt320, pelo facto de necessitar da interface própria para o utilizador. Tais como acentos, tabelas... Definindo uma emulação standard (vt100, vt220,...) para 8 bits a mesma não trabalhará correctamente. O que obtém é praticamente inutilizável. Como é um produto "velho", pode utilizar um software específico para uma emulação de terminal "velho". <BR>Após uma longa luta tentando obter a emulação correcta, você pode encontrar a "ibm3151", que produz bons resultados. Até então estamos bem ! <BR>Mas, como o software que utiliza foi desenvolvido há alguns anos atrás ele não sabe nada de segurança. A ligação utiliza telnet ! De facto, os dados transferidos são mesmo confidenciais... E então ? Terá de encontrar um meio de encriptar os dados. E novamente ssh ajudará. Mais uma vez existem diversos modos de o fazer. <BR>Pode redireccionar o telnet para a porta 22 (ssh) ou redireccionar o porto de emulação de terminal. Contudo... Receio que o servidor não aceite um redirecionamento da porta telnet (por defeito a 23) utiizando um utilizador normal: Tem de ser o root para o fazer (Pelo menos assim espero!). Acerca da emulação de terminal, pode ser utilizada por vários utilizadores ao mesmo tempo, utilizando necessariamente diferentes portas para cada ligação, i.e. 10 utilizadores = 10 portas. <BR>Torna-se um pouco "complicado", não acha ? <BR>Assim a aplicação servidora tem de ter o servidor ssh a correr e à escuta no porto 22. <BR>>De um cliente NT, ligue-se à aplicação servidora ora usando o Ttssh ou a linha de comandos. Ou seja, estabelece uma ligação segura com o servidor e o cliente sendo um determinado utilizador. A partir das opções do Ttssh pode redireccionar a porta local 50000 para a porta 23 (telnet) do servidor. Pela linha de comandos seria algo como: "ssh-L50000:servername:23". A partir de agora pode dizer à emulação de terminal para correr sobre o porto 50000 e não no 23. Os dados circulam agora num canal seguro, ou seja, encriptados. Poderá verificá-lo com o snoop ou tcpdump. <BR>Obviamente que isto deveria ser feito para cada cliente com permissões para se conectar à aplicação, alterando o redirecionamento das portas. Por exemplo, poderia usar, 50001, 50002 e por aí adiante. <BR>Agora, pode perguntar o porquê de portas tão altas ? A resposta é: por muitas razões ! <BR>A razão mais séria deve-se ao facto de portas altas poderem ser "manipuladas" sem necessidade de ser o root. <BR>A segunda razão é que a porta em questão não deve estar já a ser utilizada por ambas as máquinas. Por Exemplo: se o servidor corre Solaris, muitas portas altas são utilizadas, dependendo dos serviços a correr. A partir do porto 50000 e seguintes deveria trabalhar. Antes de utilizar o redirecionamento deve verificar as portas se estão ou não em uso. <BR>É claro, que isto deve trabalhar em muitos outros S.O. capazes de utilizarem clientes ssh. <BR>Acerca do modo de automatizar todo este processo nas máquinas clientes, isso é consigo. Poderá pedir tudo isto a um utilizador normal, antes do mesmo se conectar ? Deixaremos isto como exercício para os leitores... </P> <H2>Partir para onde ?</H2> <P>Estes poucos exemplos mostram as numerosas utilizações do ssh. Poderá fazer muito mais com muitas aplicações e o ssh. Tudo depende das suas necessidades. Contudo a "filosofia" é quase sempre a mesma: redireciomento de portos. <BR>Não obstante, seja cuidadoso ao utilizar o redirecionamento de portas mais complexo. Por exemplo, se redirecionar para uma terceira máquina, os dados a circular não serão encriptados. <BR>Uma outra desvantagem prende-se com clientes Windos que utilizam Ttssh. A ligação para as portas redirecionadas assentam em endereços IP como os comandos remotos, permitindo então ataques de intercepção. Daqui urge a necessidade de utilizar outros utilitários para além do ssh tais como os "tcpwrappers". <BR>Investigue a "literatura" acerca do ssh, ensinar-lhe-á imenso. E a sua imaginação fará o resto.</P> <H2>Por Fim, finalizando !</H2> <P>A Segurança devia ser uma preocupação de todos, mas não o é ! O ssh é um dos utilitários de segurança que poderá utilizar todos os dias. É um utilitário bastante bom, logo que o considere no seu propósito, que é a encriptação e a compressão. <BR>Sozinho, é como que inútil pois não resolve os numerosos "buracos" que pode ter numa máquina ou numa rede. Securizar uma máquina ou uma rede, é um trabalho enorme e os utilitários não lhe fazem tudo por mais bons que sejam. <BR>As tarefas mais básicas são obrigatórias quando envolvem segurança. Não se esqueça de remover todos os serviços que não são utilizados, verifique o SUID dos programas root, desactive os programas de "risco"... Há muito que fazer e nunca será suficiente. Poderá instalar todos os utilitários de segurança disponíveis, contudo de nada lhe valerão se deixar uma "porta de trás" aberta. Claro que isto é outra história, mas não se esqueça do óbvio. <BR>Voltando ao ssh, digamos que é um utilitário com o qual não consegue deixar de viver quando o utilizar adequadamente e para o propósito para que foi criado. Mais uma vez utilize-o "frases passe" e chaves RSA e não com palavras passe. Verifique as diferentes permissões dos ficheiros na directoria .ssh e claro as permissões do mesmo directório. E insistindo, pelo menos utiliza "wrappers" ! <BR>Contudo lembre-se que pode fazer circular sobre o ssh a maior parte dos protocolos existentes. Isto é bastante útil para tornar as ligações um pouco mais seguras. <BR>Há ainda um outro uso muito comum do ssh, de que não falámos, o redireciomento das sessões X. Visto que isto implica correr o X em diferentes S.O. deixá-mo-lo intencionalmente de fora. Mas Está bem identificado no protocolo de "encaminhamento". O X não sendo tão seguro, o ssh pode tornar as coisas melhores. <BR>Para um uso mais sofisticado o ssh não é suficiente. Como dissemos anteriormente, procure utilitários VPN ou como o VTun que ajudaram imenso. <BR>Por último mas não o menos importante, verifique a situação de encriptação no se país. Seria triste ir para a prisão acusado de espionagem só por utilizar software como o ssh. <BR>É assim... <BR>De Qualquer modo vivemos numa época formidável ! <!-- vim: set sw=2 ts=2 et: --></P></BODY></HTML>