Início  |  Mapa  |  Índice  |  Procura

Convert to GutenPalm or to PalmDoc por Georges Tarbouriech Sobre o autor: 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. Conteúdo: Porquê Utilizar o ssh? SSH e o VNC SSH e o MySQL SSH e a emulação de terminal Partir para onde ? Por Fim, finalizando ! Forma de respostas para este artigo

Através do Túnel

Abstrato:

SSH, 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.)
A mais conhecida disponível em http://www.openssh.org/. A partir deste "site" encontrará numerosas alternativas para os sistemas Unix, Windows, Mac.. Alguns Produtos livres para o Windows são só os clientes.
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 VTun.
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ó...
Foi Avisado !

Porquê Utilizar o ssh?

O SSH é o substituto do telnet ou rsh, rlogin como já mencionado num artigo anterior. 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.
É 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.)
É 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.
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.
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.
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 Projecto de Documentação do Linux.
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.
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.
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 !).
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.

SSH e o VNC

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 aqui para aprender mais.
Se for até ao site do VNC http://www.uk.research.att.com/vnc/docs.html 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.
Vejamos então como isto pode trabalhar.
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 http://hp.vector.co.jp/authors/VA002416/teraterm.html. 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: http://www2.epic.org/reports/crypto2000/countries.html .)
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.
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".
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.

SSH e o MySQL

MySQL é 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".
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.
A porta por defeito do MySQL é 3306. Então reencaminhamos a mesma porta (3306). Poderá fazer um reencaminhamento local ou remoto.
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.
Um reencaminhamento remoto seria: "/ssh-R3306:bandit:3306" para NT e "ssh -R 3306:bandit:3306" para Unix.
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".
Isto só trabalhará se tiver um cliente MySQL na sua máquina NT.
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.
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.
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!!!

SSH e a emulação de terminal

Que significa isto, visto já estarmos a utilizar uma emulação de terminal ?
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".
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 !
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.
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.
Torna-se um pouco "complicado", não acha ?
Assim a aplicação servidora tem de ter o servidor ssh a correr e à escuta no porto 22.
>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.
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.
Agora, pode perguntar o porquê de portas tão altas ? A resposta é: por muitas raz�es !
A razão mais séria deve-se ao facto de portas altas poderem ser "manipuladas" sem necessidade de ser o root.
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.
É claro, que isto deve trabalhar em muitos outros S.O. capazes de utilizarem clientes ssh.
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...

Partir para onde ?

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.
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.
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".
Investigue a "literatura" acerca do ssh, ensinar-lhe-á imenso. E a sua imaginação fará o resto.

Por Fim, finalizando !

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.
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.
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.
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" !
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.
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.
Para um uso mais sofisticado o ssh não é suficiente. Como dissemos anteriormente, procure utilitários VPN ou como o VTun que ajudaram imenso.
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.
É assim...
De Qualquer modo vivemos numa época formidável !

Forma de respostas para este artigo

2001-07-20, generated by lfparser version 2.17