![[Photo of the Author]](/common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to pt Bruno Miguel
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.
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 !
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.
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.
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!!!
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...
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.
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 !