Jansen Sena

Archive for the ‘Dicas e truques’ Category

Muitos administradores de sistemas, desenvolvedores e até usuários (mais avançadas) de GNU/Linux (e outros tipos de Unix, na verdade) costumam lidar com a famosa “tela preta” por horas todos os dias. E, como não poderia ser diferente, mudar de diretórios é uma tarefa executada dezenas ou centenas de vezes em uma simples jornada de trabalho. Com isso, errar o caminho do diretório é algo bem comum e que, além de fazer você perder tempo, pode prejudicar sua paciência!

Uma das formas de facilitar sua vida no poderoso mundo da “tela preta” é o próprio recurso do auto completion, presente em shells com o bash. Outro truque bem simples e interessante, mas deconhecido por muitos, é comando shopt. Com ele, pode-se pedir uma ajuda da shell para completar seus comandos “cd” para mudar de diretório quando há apenas um pequeno erro de digitação.

Por exemplo, suponha que ao tentar entrar no diretório /tmp, vc execute o seguinte comando:

$ cd /tmx

Obviamente que você receberá uma mensagem de que esse diretório (/tmx) não existe. Entretanto, tente executar o comando shopt dessa maneira:

$ shopt -s cdspell

Em seguinda, tente executar o comando “cd /tmx” e confira que, mesmo tendo errado o caminho, você estará dentro do diretório pretendido, ou seja, o /tmp. Se você quiser que todas os seus terminais de comandos sejam executados já com essa opção, basta inserir o comando “shopt -s cdspell” no arquivo .bashrc ou .bash_profile (conforme sua distribuição Linux ou versão de Unix).

Antes de terminar, logicamente que o título desse pequeno post é completamente baseado nas “peripécias criativas” de meu grande amigo e mestre do shell Júlio Neves. Por fim, como se pode ver, mesmo no mundo da “tela preta”, às vezes, a ajuda cai do “shell”. Até a próxima!

Resolver problemas remotamente utilizando SSH é um recurso presenta no dia-a-dia dos sysadmins, desenvolvedores e até usuários mais avançados de ambientes Unix/Linux. Aliás, esse é um recurso seguro e muito útil, não é mesmo? Com isso, é comum que, ao longo de suas atividades diárias, um usuário que se vale desse recurso necessite abrir sessões SSH em muitas máquinas. Obviamente que a criptografia inerente ao protolo SSH não evita a existência de um processo de autenticação. São recursos de segurança complementares. Portanto, da maneira tradicional, cada abertura de sessão SSH necessita que o usuário insira uma senha. Com o tempo, principalmente para quem costuma fazer dezenas de sessões SSH diariamente, essa pode ser uma tarefa cansativa, não é mesmo?

Para evitar isso, o protocolo SSH possui um recurso muito interessante: a autenticação por meio de chaves públicas, que evita a necessidade de prover senhas durante a abertura de sessões SSH em máquinas remotas onde a chave pública do usuário já foi previamente copiada. Normalmente, esse processo se dá através da criação de um par de chaves criptográficas por meio do comando ssh-keygen, conforme apresentado no exemplo a seguir:

jansen@scadufax $ ssh-keygen -t dsa

Nesse caso, um par de chaves (pública e privada) está sendo criado usando-se o algorimo DSA. As chaves privada e pública, recém-criadas, são gravadas, nesse caso, nos arquivos id_dsa e id_dsa.pub, respectivamente, e ficam localizadas no diretório .ssh, dentro do home do usuário. Para se valer do recurso de não precisar prover senhas é preciso, então, copiar a chave pública para o arquivo .ssh/authorized_keys nos diretórios home dos usuários remotos, usando-se, por exemplo, o seguinte comando:

jansen@scadufax $ scp ~/.ssh/id_dsa.pub jsena@smeagol:~/.ssh/authorized_keys

Nesse caso, quando o usuário jansen, a partir da máquina scadufax, tentar abrir uma sessão SSH com o usuário jsena na máquina smeagol, nenhuma senha será necessária. O processo de autenticação se dará através das chaves criptográficas. Até nenhuma novidade, certo? Entretanto, imagine que mais de um usuário deseje acessar a conta jsena na máquina smeagol. Pode até ser a mesma pessoa utilizando um par de chaves criptográficas diferentes do anterior, gerado, por exemplo, em outro computador. Nesse caso, se o mesmo procedimento anterior for utilizado, o arquivo authorized_keys, que já contém a chave pública de outro usuário, será sobrescrito, passando a invalidar o acesso cadastrado anteriormente. Para evitar esse problema, a partir do segundo usuário, seria necessário adotar outros procedimentos para a cópia da chave-pública de forma a não sobrescrever o conteúdo já existente no arquivo authorized_keys.

Para facilitar esse processo, existe um utilitário chamado ssh-copy-id que é desconhecido por uma parcela considerável dos usuários de SSH. Essa pequena ferramenta resolve esse problema da cópia de diversas chaves para um mesmo arquivo authorized_keys:

jansen@scadufax $ ssh-copy-id jsena@smeagol

Caso seja necessário copiar outras chaves para acessar a conta jsena na máquina smeagol, basta utilizar o mesmo comando. Caso um mesmo usuário tenha mais de um par de chaves (sim, isso é possível), pode-se indicar quais delas se deseja copiar para a máquina remota:

jansen@gandalf $ ssh-copy-id -i .ssh/id_rsa.pub jansen.sena@boromir

Simples, não? Bem, acho que é isso.

IMPORTANTE: Para que o mecanismo de autenticação através de chaves públicas funcione corretamente, é necessário que o servidor SSH esteja configurado para tal. Mas isso é assunto para outro momento!

Foi-se o tempo em que as distribuições GNU/Linux eram limitadas aos terminais de “tela preta”. Atualmente, existem diversas alternativas de ambientes gráficos e uma vasta parafernalha de recursos para tornar seu ambiente gráfico de desktop ágil e bastante atrativo. Por outro lado, isso não significa dizer que a “tela preta” ficou para trás e não possui mais qualquer utilidade. Muito pelo contrário. Ela continua sendo uma excelente ferramenta para administradores de sistemas, analistas de segurança, desenvolvedores e usuários mais avançados.

Além de poder executar diversos comandos individuais de maneira ágil, a possibilidade de poder combinar comandos através do uso dos pipes é o que, particularmente, considero ser um dos grandes poderes “Jedi” da “tela preta”. Com esse recurso, é possível criar, facilmente, funcionalidades que não existem através de um único comando para atender às suas necessidades. É claro que, quanto maior a experiência com a “tela preta”, melhor será suas condições em usar do recurso dos pipes. E, logicamente, nada melhor do que praticar um pouco para desafiar a criatividade.

Diante disso, resolvi compartilhar por aqui um exemplo que pode ser útil para o seu dia a dia: reduzir o tamanho de suas fotos. Com câmeras digitais cada vez mais acessíveis e com a sua inclusão em diversos dispositivos como celulares e tablets, muitas pessoas costumam acumular muitos gigas armazenando suas imagens. Some-se a isso o fato das resoluções cada vez mais altas gerarem arquivos maiores. Diante disso, seja como uma forma de economizar espaço em seus meios de armazenamento (e.g. HDs externos) ou como facilitar o envio e o compartilhamento de suas fotos através da Internet, reduzir o tamanho de suas fotografias, às vezes, pode ser uma ideia interessante.

A questão é: como fazer isso de umam única vez aplicando a redução para todas as fotografias selecionadas? Bem, como você já deve ter desconfiado, a “tela preta” pode lhe ser útil nesse momento especialmente por meio do uso dos pipes. Vamos dar uma olhada?

Read the rest of this entry »

Tarefa básica e que faz parte do cotidiano de um usuário: abrir o browser de sua preferência e acessar algum site na Internet. Simples, não? Do ponto de vista do usuário, sim. Mas, aos olhos de um administrador de sistemas preocupado com segurança, essa é uma atividade que merece ser um pouco mais estudada. Todas as vezes que um cliente conecta-se a um servidor Web há uma troca de informações entre ambas as partes. Nesse caso, a linguagem falada é o HTTP. A questão é que algumas dessas informações podem revelar informações do seu servidor Web úteis na elaboração de um ataque.

Para verificar algumas das informações comumente reveladas por um servidor Web aos clientes que conectam-se a ele, basta utilizar o antiquado mas ainda útil telnet. Nesse caso, é suficiente escolher um site qualquer, direcionar a conexão para a porta 80 e submeter ao servidor algumas das poucas informações obrigatórias do protocolo HTTP (GET e Host, por exemplo), conforme mostrado a seguir:

# root@scadufax:~# telnet www.xxxxx.com.br 80
Trying 201.123.123.121...
Connected to server.xxxxx.com.br.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.xxxxx.com.br

Após a cláusula “Host”, pressione duas vezes Enter. Em seguida, o servidor Web deve retornar os cabeçalhos HTTP de resposta e o conteúdo da página, de acordo como mostrado abaixo:

HTTP/1.1 200 OK
Date: Fri, 08 Jul 2011 00:47:40 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny10 with Suhosin-Patch
Last-Modified: Thu, 20 Apr 2006 18:44:51 GMT
ETag: "9f132-c96-411e12ad8aec0"
Accept-Ranges: bytes
Content-Length: 3222
Content-Type: text/html; charset=ISO-8859-1

<<< CONTEÚDO DA PÁGINA>>>

Dentre os cabeçalhos de resposta, dedique atenção especial ao “Server”, em destaque. Nele, é possível identificar o servidor Web (Apache), sua versão (2.2.9), o sistema operacional (Debian) e ainda a versão do PHP (5.2.6-1+lenny10). Tais informações já ajudam um atacante a escolher quais ferramentas ele poderá ajudar em um eventual ataque. Pior ainda: o atacante consegue descobrir se seu servidor encontra-se completamente desatualizado e, portanto, possivelmente vulnerável contra um conjunto maior de exploits. Revelar essas informações no cabeçalho “Server” é o comportamento mais comum para um servidor Apache instalado diretamente dos repositórios de pacotes de sua distribuição.

Outra forma de identificar se o servidor está revelando mais informações do que deveria consiste simplesmente em provocar algum erro, acessando, por exemplo, uma página que, certamente, não existe naquele servidor Web:

http://www.xxxxx.com.br/abcdefghijklmnop

Servidor Apache revelando informações desnecessárias.

Normalmente, em sites mais bem configurados, as páginas de erro são todas customizadas. Nesses casos, algumas vezes, as informações sobre o servidor não são apresentadas.

Surpreso? É nesse estado que se encontra seu servidor? Bem, então é hora de corrigir esse problema.

O Apache possui duas configurações bem simples mas que são costumeiramente ignoradas, fundalmentalmente pelos administradores de sistemas menos experientes: ServerTokens e ServerSignature que podem impedir que o servidor revele informações mais detalhadas no cabeçalho “Server” do HTTP e que informações desnecessárias sejam apresentadas nas páginas de erro default do Apache, respectivamente. Para fazê-las desempenhar essas funções, basta adicioná-las no arquivo de configuração do Apache da seguinte maneira:

ServerTokens Prod
ServerSignature Off

Depois, reinicie o seu servidor Apache e veja se agora, seu servidor passou a “falar” um pouco menos…

Logicamente que existem muitas outras providências a serem tomadas para fazer um bom trabalho de hardening de um servidor Apache. Entretanto, deixaremos isso para uma outra oportunidade.

Bem, acho que é isso. Até o próximo post.

Assim que a febre dos netbooks começou a se espalhar, comprei o Asus eeePC 701, um dos modelos de mais sucesso desse tipo de equipamento e precursor de muitos outros notebooks que foram lançados posteriormente. Apesar de já ser um pouco antigo, eu ainda o utilizo para fazer tarefas menores e algumas “experiências”, principalmente envolvendo segurança de sistemas e redes. Enfim, o meu eeePC 701 desempenha uma função de coringa em meio aos meus computadores.

Já utilizei diversas distribuições Linux nesse equipamento. Aliás, foi essa uma das razões pelas quais eu o adquiri. Testar algumas distribuições Linux é um hobby antigo. Além da distro original, o Xandros, que durou poucas horas no equipamento, já testei diversas outras opções baseadas em Debian, o Eeebuntu, o Easy Peasy, dentre outros. O Ubuntu passou, então, a ter uma versão oficial para esses equipamentos: o Ubuntu Netbook Remix, que comecei a utilizar em meu Asus eeePC 701. Entretanto, esse produto passou a ser integrado ao Ubuntu padrão. Ou seja, a partir de então, a mesma imagem ISO poderia ser utilizada para notebooks e netbooks.

Read the rest of this entry »

Sem sombra de dúvidas, planejar o particionamento de um servidor GNU/Linux com LVM é uma opção muito interessante e praticamente obrigatória para um sysadmin precavido e organizado. Entretanto, podemos tratar um pouco mais sobre o LVM e suas vantagens em outra oportunidade. Esse rápido post é apenas para compartilhar uma situação que já passei em algumas oportunidades: em alguns servidores que administro, já tive problemas para remover volumes lógicos (LVs).

A maneira mais comum para remover um LV consiste, simplesmente, em utilizar o comando lvremove. Por exemplo:

# lvremove /dev/MyVG/lvol_test

Entretanto, em alguns sistemas, me deparei com o seguinte erro ao tentar remover LV:

# lvremove /dev/MyVG/lvol_test
Can't remove open logical volume "lvol_test"

Bem, caso você esteja com esse problema, existe uma solução muito simples por meio da utilização do dmsetup.

# dmsetup info -c MyVG-lvol_test

Name               Maj Min Stat   Open Targ Event  UUID
MyVG-lvol_test     253   8 L–w       1    1      0 XiuqlKY91paW...

Nesse caso, o valor que interessa é o da coluna Open. O  número “1″ identifica que o LV encontra-se no status de aberto e isso pode ser a causa do problema. Se esse for o seu caso, execute o comando dmsetup da seguinte maneira:

# dmsetup remove MyVG-lvol_test

Em seguida, tente executar novamente o comando lvremove que, dessa vez, deve reportar a remoção com sucesso do LV:

# lvremove /dev/MyVG/lvol_test
Logical volume "lvol_test" successfully removed

Bem, acho que é isso.

Remover arquivos faz parte da rotina diária de qualquer usuário de um sistema operacional, não é mesmo? Provavelmente você deve fazer isso algumas dezenas de vezes ao longo de um dia de trabalho em frente ao computador. Caso um arquivo qualquer (como uma ISO de um sistema operacional, por exemplo) esteja sendo apagado simplesmente para liberar espaço em seus meios de armazenamento, que mal há utilizar o bom e velho “rm”? Por outro lado, tenho a impressão de que você não gostaria de saber que aquele script que contém todas as suas regras de firewall, por exemplo, ou qualquer outro arquivo com alguma informação sensível pode cair em mãos erradas se você confiar no apenas no “rm”.

Bem, primeiramente, permita que eu me desculpe por ‘descortinar’ essa verdade caso você ainda achasse, até o parágrafo anterior, que um “rm -f” era um comando forte e com tanta ‘personalidade’ ao ponto de mandar pro espaço qualquer arquivo ou diretório. O fato é que ao remover um arquivo com esse comando o sistema operacional, em poucas palavras, simplesmente retira os “ponteiros” para os blocos de dados que formavam o arquivo. Por outro lado, esses blocos estão lá em seu HD e podem, com a ajuda de algumas ferramentas, ser recuperados. Provavelmente esses blocos irão ser sobrescritos apenas quando novos arquivos forem utilizando aqueles mesmos espaços e isso pode demorar um tempo bastante considerável principalmente se o computador em questão não tiver operações um fluxo de gravação de arquivos muito intenso.

E, antes que você se pergunte, mas quem pode ter acesso ao meu HD? Bem, fácil. Seu computador pode ser invadido através da Internet, você pode perdê-lo, você pode ser roubado, você pode vendê-lo ou você pode mandá-lo para uma assistência técnica para consertar um problema, por exemplo. Enfim, são muitas as possibilidade, não é verdade? Pior ainda quando se está falando dos pequenos e portáteis pen drives que carregamos conosco o tempo todo para todo lugar. Quando é possível, pode-se utilizar os sistemas de arquivos criptografados. Entretanto, em situações onde não é possível utilizar essas soluções, é preciso tomar cuidado para garantir que arquivos sensíveis foram, de fato, removidos.

Read the rest of this entry »

As coisas parecem estar progredindo bastante quando se fala de GNU/Linux, não é mesmo? Lembro-me da época em que tudo era muito complicado e trabalhoso para funcionar. Hoje em dia é provável que muitos usuários instalem uma distribuição como o Ubuntu em seus computadores e, em poucos minutos, tenham tudo funcionando perfeitamente, sem que sejam necessárias peripécias e truques. Mesmo assim, problemas acontecem…

Em algumas versões anteriores do Ubuntu, por exemplo, era necessário instalar alguns pacotes e fazer algumas configurações para que fosse possível acessar um iPhone a partir de seu sistema operacional. Com o Ubuntu 10.10 (Maverick Meerkat) as coisas evoluíram bastante: ao conectar um iPhone, o sistema já apresenta o seu sistema de arquivos automaticamente e ainda fica apto a conectar com ferramentas como o gtkpod, o Banshee e o RhythmBox. Maravilha, não? Isso funciona muito bem… ou, pelo menos, funcionava até atualizar a versão do iOS para a 4.2.1… Com essa versão, a conexão do aparelho celular ao seu computador deve apresentar um erro ao invés da tela que você estava acostumado a ver.

Com uma rápida pesquisa na Internet, encontrei uma solução muito simples que resolveu o problema.  Em poucas palavras, a saída consiste em atualizar alguns pacotes, dentre os quais o libimobiledevices, uma biblioteca que provê a interface de comunicação de dispositivos como iPhones e iPod Touchs com o sistema operacional, através de um repositório que deve ser adicionado ao seu sistema operacional.

Para isso, abra um terminal como super-usuário e execute os seguintes comandos:

# add-apt-repository ppa:pmcenery/ppa

# apt-get update

# apt-get dist-upgrade

Caso seu terminal não seja de super-usuário, não esqueça de acrescentar o “sudo” antes de cada um dos três comandos anteriores.

Após a execução dos comandos anteriores, basta reconectar o iPhone ao Ubuntu e tudo deve estar funcionando novamente. Simples, não?

O aumento da capacidade de armazenamento dos meios de armazenamento (HDs, pen drives, cartões de memória, etc) e a redução drástica nos preços desses equipamentos mantém uma relação proporcional ao nível de dependência, cada vez maior, diga-se de passagem, que os usuários (e suas corporações) possuem com relação às informações preservadas nesses dispositivos. Hoje, pequenos pen drives possuem muito mais espaço de armazenamento do que servidores inteiros de alguns anos atrás. Discos com terabytes de capacidade podem ser adquiridos na maioria das lojas de informática a preços bem acessíveis. Some-se a isso o fato desses meios de armazenamento estarem menores e , portanto, “perambulando” em bolsas, bolsos, mochilas, pastas, dentre outros.

Essas facilidades, entretanto, aumentam em muito a possibilidade de se perder esses equipamentos ou mesmo tê-los furtados por outra pessoa. Ainda que sejam arquivos de natureza pessoal, tais como fotos, e-mails e outros documentos, a maioria das pessoas não gostaria de ver esses arquivos em mãos erradas, não é mesmo? Trocando o contexto para o meio corporativo, o comprometimento de informações pode inviabilizar projetos, negócios, estratégias e até a própria sobrevivência da instituição. Por outro lado, são poucas as pessoas e as instituições que têm implementados mecanismos que possam proteger as informações contra a perda ou o roubo dos meios de armazenamento. A grande maioria prefere sofrer com o arrependimento e com as lamentações quando perdem seus dados e os deixam expostos sem qualquer proteção para evitar que os mesmos sejam acessados (e explorados) livremente.

A boa notícia é que existem recursos muito simples para instalar e configurar alguns mecanismos e ferramentas para melhorar a confidencialidade de suas informações. Dentre os diversos recursos e ferramentas disponíveis, uma das mais eficazes são os sistemas de arquivos criptografados e, em ambientes GNU/Linux é algo simples de fazer. A seguir, compartilho uma das maneiras que costumo utilizar para criar, rapidamente, sistemas de arquivos criptografados. Vamos lá?

Read the rest of this entry »

O rsync é uma ferramenta extremamente útil e bastante utilizada por diversos administradores de sistemas Unix/Linux e até mesmo por usuários mais avançados. O próprio nome do utilitário já se confunde com a função de sincronizar arquivos e diretórios. Basicamente, quando se deseja utilizar essa ferramenta para sincronizar arquivos entre máquinas distintas, existem duas maneiras básicas e mais comuns: ou por meio de um daemon rsync que deve estar sendo executado na máquina onde se deseja sincronizar os arquivos; ou através do popular servidor SSH. Como a última alternativa já se aproveita de um serviço de acesso remoto seguro, presente na grande maioria das máquinas que possui Unix e/ou alguma distribuição GNU/Linux, essa pode ser a maneira mais prática.

Por exemplo, suponha que você deseje sincronizar o conteúdo do diretório /home/jansen/docs com o diretório /home/bkp/jansen que fica na máquina chamada aragorn.jsena.com.br. Considerando que existe um usuário chamado jsena no host aragorn.jsena.com.br e um servidor SSH, basta utilizar o seguinte comando para realizar essa tarefa:

$ rsync -avz /home/jansen/docs jsena@aragorn.jsena.com.br:/home/jsena/bkp

Simples, não? É claro que existem outras opções do rsync bastante úteis e que podem ser consideradas para fazer operações de sincronismo mais customizadas e específicas. Normalmente, o SSH irá solicitar a senha para autenticar o usuário jsena no host aragorn.jsena.com.br. Entretanto, caso seja de seu interesse executar esse sincronismo automaticamente, sem a necessidade de inserção de senha, basta gerar um par de chaves com o aplicativo ssh-keygen e transferir a chave pública do usuário (criada normalmente com o nome de id_pub.dsa ou id_pub.rsa) em seu computador local para o arquivo /home/jsena/.ssh/authorized_keys. Mas, isso é assunto para outra oportunidade. A questão aqui é tratar do seguinte problema: como fazer o rsync funcionar por meio do SSH se esse servidor não estiver sendo executado em sua porta TCP padrão, a 22?

Antes que você possa se perguntar: “afinal de contas, por que utilizar o SSH em uma porta diferente da padrão?”, aí vai uma rápida explicação. Sempre coloco esse serviço para executar em outras portas, diferentes da padrão por questões de segurança e de hábito. Isso não representa muita segurança (e uma melhor solução seria utilizar o SPA, Single Packet Authorization). Po outro lado, quando isso não é aplicável, essa medida pode, ao menos, desviar a atenção principalmente dos atacantes e/ou curiosos menos experientes. O problema é que o rsync não possui um parâmetro do tipo “port” ou “-p” para se indicar a utilização de uma outra porta quando o SSH está sendo utilizado para o sincronismo de arquivos. A solução é, por outro lado, bastante simples. Tomando como base o exemplo apresentado e supondo que o servidor SSH no host aragorn.jsena.com.br esteja funcionando na porta 22119, basta executar o comando anterior da seguinte maneira:

$ rsync -avz -e 'ssh -p 22119' /home/jansen/docs \
      jsena@aragorn.jsena.com.br:/home/jsena/bkp

Pronto. O problema está resolvido!