Introdução
Antes de começar a falar sobre os sistemas de arquivos, temos que ter em mente o que é um sistema de arquivos.
Sistema de arquivos é uma estrutura lógica que permite armazenar informações em massa e de forma bem organizada, permitindo que um Sistema Operacional ou aplicações possam ser usadas pelo computador, assim como gravar novas informações, e essas informações possam ser acessadas posteriormente. Um sistema de arquivos depende de estruturas de dados sobre os arquivos. Uma dessas estruturas são os metadados de dados que descrevem os dados. Cada arquivo está associado com um inode, o qual é identificado por um número inteiro, muitas vezes referido como um número ‘i-‘, ou número de inode. Inodes armazenam informações sobre arquivos e diretórios (pastas), tais como a propriedade do arquivo, modo de acesso (ler, escrever, executar permissões) e tipo de arquivo. Em muitos tipos de implementações de sistemas de arquivos, o número máximo de inodes é fixado no momento da criação do sistema de arquivos, limitando o número máximo de arquivos que o sistema de arquivos pode conter. – Posso usar Sistema Operacional, ou alguma aplicação, sem ter que aplicar um sistema de arquivos? Não, o disco rígido que armazena as informações é formatado fisicamente pelo fabricante, e esse tipo de formatação não faz com que o disco possa armazenar informações, porém, não se consegue utilizar o mesmo, pois ainda precisa de uma estrutura lógica para utilizar todo o espaço que o disco disponibiliza. Objetivo do artigoNão faz parte do objetivo do artigo fazer um estudo aprofundado sobre cada sistema de arquivos abordado, mas sim, abordar as características dos mesmos, permitindo conhecer mais de cada um. EsclarecimentosTodo e qualquer sistema de arquivos não é ANTI-FALHAS. O mesmo não impede que sua estrutura de dados fique corrompida ou danificada após um desligamento inesperado causado por falta de energia, ou por travamento no sistema ou aplicação, fazendo com que você seja obrigado a usar o botão de desligamento ou de reinicialização. E após desligar ou reinicializar desta forma, pode ter certeza que seu HD logo ficará com badblocks, principalmente se este tipo de situação acontecer constantemente. Não se impressione se o seu sistema, após um acontecimento destes, não conseguir mais ser acessado, ou precisar de reparos manuais para poder ser usado novamente. O único sistema que ouvi falar bem quanto à tolerância de falhas, mas não cheguei a usar e nem a testar, foi o ZFS, desenvolvido pela Sun Microsystems. Aí você pode se perguntar: – Mas o que é um ‘badblock’ e por quê o sistema pode ficar corrompido, caso aconteça o que você citou acima? 1° – Um ‘badblock’ é uma área danificada de um disco que não pode ser mais utilizada, pois o dano é permanente. Este tipo de dano pode ser causado por desligamentos forçados, como por exemplo, apertar o botão de desligamento da máquina, assim como reinicialização forçada, formatações erradas, esbarrões no HD, falta de energia etc. Quando há muitos ‘badblocks’, seu HD está próximo do fim de sua vida útil, pois o mesmo está com muitos problemas. 2° – O sistema de arquivos pode ficar corrompido e o SO ficar inacessível, porque algum, ou alguns dados que estejam sendo utilizados pelo sistema no momento em que acontece o que foi citado anteriormente ainda não foram salvos, fazendo com que o mesmo fique incompleto, sendo assim corrompido. E se um arquivo deste for importante para o sistema, pode fazer com que o sistema fique inacessível. Porém, muitos dos sistemas de arquivos tem tolerância de falhas, alguns mais consistentes e robustos que os outros. Para os sistemas de arquivos usados no GNU/Linux, toda essa consistência tem ajuda do recurso muito utilizado que é o Journaling. |
|
Journaling
Journaling é um recurso usado pelos sistemas de arquivos que consiste em uma área dedicada para registros, armazenando todas as ações que serão feitas nos arquivos, como gravação e/ou alteração de dados, por exemplo. Seja armazenamento somente de metadados, ou de metadados e dados de arquivos, permitindo restaurar o sistema de arquivos, caso aconteça algum erro inesperado.
A principal finalidade do ‘journaling’ é recuperar o sistema de arquivos de erros (tolerância de falhas), sejam eles causados pelo sistema, aplicações ou desligamentos incorretos de forma forçada ou inesperada. Com isso é possível localizar todas as operações que não haviam sido completadas, restaurando a consistência do sistema de arquivos e permitindo que o sistema operacional continue sendo utilizado. Aí você ainda fica com dúvida e pergunta: Mas como assim? Com o ‘jounaling’, o sistema de arquivos passa a registrar em uma área especial chamada journal, ou log, as ações que serão feitas nos arquivos (gravação ou alteração de dados, por exemplo) antes da gravação no FS em si. Após a execução, as operações registradas no log são tidas como concluídas e, portanto, eliminadas. Note que todo este procedimento acontece de maneira extremamente rápida. Mas em que exatamente, o ‘journaling’ mostra-se vantajoso? Os registros de log são escritos antes que as mudanças efetivamente ocorram no sistema de arquivos. Estes registros somente são eliminados quando as mudanças são executadas. Se, por exemplo, o computador for desligado repentinamente (como ocorre em falta de energia elétrica), o sistema de arquivos verificará os registros existentes no ‘journal’ e executará aquilo que estiver marcado como não realizado. Isso faz com que o risco de perda de dados diminua drasticamente, já que o sistema operacional saberá ‘onde parou’. Porém temos que ter em mente que este recurso não é anti-falhas e sim, um recurso para tolerar falhas até um certo ponto. Pois esta tolerância não previne 100% de erros como os citados anteriormente, toda essa tolerância a falhas pode acabar de uma hora para outra, após várias quedas de energia ou desligamentos forçados. Contudo, nem todos os sistemas de arquivos que usam o ‘journaling’ possuem uma boa implementação do mesmo, fazendo com que este recurso não seja 100% confiável. Se você começar a desligar o sistema incorretamente com frequência, vai perceber que, algumas vezes, o sistema não será capaz de verificar o ‘journal’, e o sistema de arquivos terá que ser verificado usando um utilitário para verificação da integridade do sistema de arquivos, tentando localizar todas as operações que não haviam sido completadas para tentar recuperar a integridade de alguns arquivos, fazendo com que, quase sempre, alguns arquivos sejam perdidos. Técnicas de journaling
Outras informaçõesOs sistemas de arquivos para GNU/Linux: JFS, XFS, ReiserFS, ext3 e ext4, possuem ‘journaling’. O arquivo de log do ‘journaling’ pode estar no mesmo sistema de arquivos, ou em um sistema de arquivos de outra partição, e/ou outro disco. E seu tamanho pode ser aumentado também para melhorar o desempenho. Então o ‘journaling’ torna-se indispensável para os sistema de arquivos usados hoje e no futuro, pois é através deste recurso que temos uma certa tolerância a certos acontecimentos não planejados. |
|
Sistema de arquivos ext3
O sistema de arquivos ext3 já está entre a comunidade GNU/Linux a muito tempo e ainda é bastante utilizado. O ext3 é uma atualização do sistema de arquivos ext2.
Em relação ao ext2, a principal diferença é a implementação do journaling, um recurso muito interessante abordado na segunda página deste artigo, que consiste no armazenamento de registros para posterior restauração das informações, caso aconteça algum erro. Principais vantagens1. Possui journaling. Há três níveis de operação do journaling disponíveis na implementação do ext3:
O modo de operação padrão é o Ordered, porém não significa dizer que você não consiga mudar isso. Para usar o modo Writeback ou o modo journal, você deve adicionar a opção “data=writeback” ou “data=journal” nas opções referentes à partição, dentro do arquivo /etc/fstab ou usando o comando tune2fs. 2. Possui indexação de maior quantidade de diretórios; 3. Suporte para tamanhos maiores de volumes e arquivos em relação a sua versão anterior. Veja abaixo uma tabela: Tamanho do bloco Tamanho máx. arquivo Tamanho máx. fs 1 KiB 16 GiB 2 TiB 2 KiB 256 GiB 8 TiB 4 KiB 2 TiB 16 TiB 8 KiB 2 TiBsp 32 TiB 4. O ext3 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como:
Principais desvantagens
O sistema de arquivos ext3, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportar o journal, e sim, foi integrado a partir da versão 3 do mesmo, por isso, o journal não é tão eficaz no ext3. E quando o journal falha, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido. Para muitos, este sistema de arquivos é obsoleto e para outros estável, e tem um bom desempenho. |
|
Sistema de arquivos ext4
O sistema de arquivos ext4 é última versão do sistema de arquivos extFS até o momento, ele é na verdade a atualização do ext3, já abordado no artigo.
O ext4 trouxe, de acordo com seus desenvolvedores, alguns recursos que não existiam no ext3, mantendo alguns que a versão anterior já possuía. Na verdade são recursos que estavam tentando implantar na versão 3 do extFS (ext3), porém, devido a alguns problemas na implementação, lançaram essa nova versão com as características descritas abaixo. Principais vantagens
Principais desvantagens1. Alocação tardia e potencial perda de dados: Com as mudanças de alocação atrasada, este recurso representa algum risco adicional de perda de dados nos casos em que o sistema trava antes que todos os dados tenham sido gravados no disco. Devido a isto, o ext4, na versão 2.6.30 do kernel GNU/Linux, detecta automaticamente estes casos e reverte para o comportamento antigo. O cenário típico em que isso pode ocorrer é um programa que substitui o conteúdo de um arquivo sem forçar uma gravação para o disco com sync. 2. Criação do sistema de arquivos: Assim como no ex3, o ext4 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda. O sistema de arquivos ext4, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportá-lo e este recurso foi integrado a partir da versão 3 do mesmo, por isso o journal não é tão eficaz, nem no ext3 e no ext4, apesar que o último mencionado teve melhorias. E quando o journal falhar, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido. Atualmente o ext4 é bem rápido, tem um ótimo desempenho, mas seu journal pode deixar a desejar quanto à tolerância de falhas, apesar que o mesmo teve melhorias e resiste bem. |
|
Sistema de arquivos XFS
O sistema de arquivos XFS é considerado por muitos de alto desempenho, é um sistema de arquivos de 64 bits sendo compatível com sistemas de 32 bits. Foi desenvolvido inicialmente para o SO IRIX, depois portado para o kernel GNU/Linux.
O kernel e a maioria dos sistemas GNU/Linux dão suporte durante a instalação para usar o XFS como sistema de arquivos de suas partições, e assim, como os outros sistemas de arquivos apresentados até agora, possui journaling. Principais vantagens
Principais desvantagens
|
|
Sistema de arquivos ReiserFS
O sistema de arquivos ReiserFS foi criado por Hans Reiser e pode ser usado pelas distribuições GNU/Linux, sendo que algumas dão bom suporte durante a instalação e outras não. Sua versão atual é a 3.6.x. O ReiserFS foi o primeiro sistema de arquivos com suporte a journaling incluído no núcleo do GNU/Linux.
Algo muito interessante no ReiserFS é suporte ao journaling implantado desde o início e não depois de ter sido desenvolvido (como foi feito no extFS). Isso garante que o ReiserFS trabalhe melhor com o journal, possibilitando uma tolerância contra falhas mais eficaz. Principais vantagens
Principais desvantagens
Atualmente, devido à paralisação das atividades da Namesys, que é sua principal desenvolvedora junto com Hans Reiser, o projeto ReiserFS está armazenado em kernel.org. O ReiserFS tem um nova versão, que é a 4, mas a mesma ainda não está inclusa no kernel versão 3.x.x, que atualmente é 3.4.2 no momento da criação deste artigo, pois os desenvolvedores afirmam que o Reiser4 não segue o padrão GNU/Linux de decodificação. Para mais informações sobre o Reiser4, acesse link: |
|
Sistema de arquivos JFS
O JFS foi criado com o propósito principal de ser utilizado em servidores que deveriam usar poucos recursos do processador, e ser capaz de ser redimensionado mesmo em uso. JFS é um sistema de 64 bits, assim como XFS, onde existem duas versões: JFS1 e JFS2. No pinguim é usada a versão 2.
JFS está disponível na maioria das distros, assim como outros, mas durante a instalação o FS padrão, em sua maioria, é o ext4. Principais vantagens
Principais desvantagens
|
|
Benchmark básico dos sistemas de arquivos
Depois de tantas informações sobre cada sistema de arquivos abordado, você pode ficar com, no mínimo, um pouco de curiosidade de saber o desempenho de cada um deles em teste.
Aqui vou mostrar vários gráficos que comparam o desempenho de cada um, trata-se de benchmark básico. ESCLARECIMENTO: Para este Benchmark não fiz otimização em nenhum dos sistemas de arquivos, todos foram instalados com suas opções padrões. O SO usado para testar foi o Debian 6, rodando em uma máquina com processador Intel Core 2 Duo e espaço em memória de 4 Gigas, além de um disco SATA Samsung. Todos os testes não informam o uso de CPU, apenas o tempo que foi necessário para concluir a tarefa, e foram feitos em modo texto. Primeiro testeTrata-se de criar um arquivo de 10 Gigabytes de tamanho em cada sistema de arquivos usando o comando dd, todos concluíram o teste em minutos. Veja o resultado no gráfico abaixo: Neste teste o mais veloz foi ext4, seguido de ext3 e logo depois XFS, seguido de ReiserFS e em último ficou o JFS. Segundo testeFoi desempacotado um arquivo do kernel 3.4 com tamanho de 77 Megas e todos concluíram a tarefa em menos de um minuto, ou seja, concluíram em segundos. Veja o resultado no gráfico abaixo: Neste segundo teste, ext4 também foi mais rápido, mas a diferença não foi tanta para ext3 e ReiserFS, XFS veio logo atrás, e no último lugar, mais uma vez ficou JFS. Terceiro testeFiz uso de um script para criar 30 mil arquivos de texto simples, sem conteúdo, e todos concluíram o trabalho em poucos segundos, veja o resultado no gráfico abaixo: Nesta terceira rodada, o mais rápido foi ReiserFS, seguido de pertinho por ext4 e ext3, e mais uma vez, JFS foi o mais lento. Quarto testeFiz uma listagem de todos os 30 mil arquivos criados no teste anterior, e mais uma vez todos concluíram em poucos segundos. Veja o resultado no gráfico abaixo: Nesta rodada, o ext3 foi muito mais rápido que os outros, concluindo o trabalho em menos de um segundo, logo depois veio ext4, ReiserFS, JFS e XFS, com pouco tempo de diferença entre eles. Quinto testeFiz a remoção de todos os 30 mil arquivos criados anteriormente, e mais uma vez todos concluíram o teste em menos de um minuto, veja o resultado no gráfico abaixo: Neste teste o mais rápido foi ext4, seguido de ext3 e ReiserFS, o mais lento foi XFS, aliás, muito lento em comparação com os outros. Sexto testeRemovi o diretório do kernel 3.4 e todos seus arquivos e subdiretórios criados após a descompactação, e o teste foi concluído em segundos. Veja o resultado no gráfico abaixo: Neste teste o ext3 e ext4 foram absurdamente mais rápidos, respectivamente, com um pouquinho de tempo a mais, o ReiserFS demostrou muita velocidade. O JFS foi muito lento. Sétimo testeFiz uso de um script para criar 30 mil diretórios vazios e a tarefa levou menos de um minuto para ser concluída, mais uma vez (foi concluída em segundos). Veja o resultado no gráfico abaixo: Neste teste houve um certo equilíbrio na velocidade de término de tarefa de cada um, dupla exts foram um pouco mais velozes que ReiserFS e JFS, e XFS foi o mais lento mais um vez. Oitavo testeRemovi os diretórios criados e o término da tarefa foi em segundos também: Neste último teste os sistemas de arquivos ext4, ext3 e ReiserFS foram absurdamente mais rápidos, acabando a tarefa em menos de um segundo cada. Você pode ver também um benchmark feito pela Phoronix acessando o link abaixo: Nota-se neste benchmark básico realizado por mim, que os sistemas mais velozes foram ext4 e ext3, seguido do ReiserFS e depois XFS e por último, o JFS. Tenho que levar em conta que não foi feito nenhum tipo de personalização no sistema de arquivos aplicado, tal como: aumento de tamanho do arquivo do journaling, ou journaling externo, por exemplo. Ou seja, nenhum sistema de arquivos foi turbinado. |
|
Considerações finais
Todos os testes realizados e mostrados na página anterior foram baseados na velocidade de término de cada tarefa, contudo, não faça a escolha do sistema de arquivos somente pelo desempenho, leve em consideração as características positivas e negativas de cada um.
Quando o assunto é sistema de arquivos no GNU/Linux, é inevitável as comparações entre o ReiserFS, XFS, ext4 e o ext3, além do JFS, que é menos usado. Nada mais natural, afinal, cada administrador de sistemas e ou redes e até mesmo usuários busca qual é o melhor para suas necessidades. Apontar qual realmente é melhor não é uma tarefa fácil. Há vários comparativos na Internet que tentam oferecer esta resposta, mas na minha opinião, a melhor coisa a fazer é testar os sistemas de arquivos que lhe atraíram para definir qual mais lhe agrada. Definitivamente, o uso de sistemas de arquivos sem suporte a journaling, ou algum recurso similar, para tolerância de falhas e erros não é recomendável de usar, pois pode deixá-lo na mão. NOTA: Não incluí o Btrfs, pois o mesmo é considerado instável e não é aconselhável o seu uso em produção, e ainda está em desenvolvimento constante para ser aprimorado. Se deseja mais informações sobre o mesmo, leia o artigo: Recomendação de usoSe quer desempenho, recomendo ext4, pois o mesmo mostra-se muito rápido, e o suporte dele no kernel (usado como default nas instalações até então de muitas distros) é muito bom. E ext3, que apesar de ser considerado obsoleto por muitos, é bem estável e ainda é rápido também, porém, o mesmo não tem tanta eficácia com o journaling (como explicado durante o artigo). Para isso recomendo ReiserFS e XFS, pois estou usando-os a um bom tempo, e os mesmos até o momento não apresentaram nenhum problema, mesmo já passando por desligamentos inesperados e ambos terem um desempenho muito bom, cada um com suas vantagens. XFS trabalha melhor com arquivos grandes e ReiserFS com arquivos pequenos. São apenas recomendações, porém, recomendo que teste e veja qual é o que mais o agrada no quesito que deseja e necessita. Concluindo, menciono mais uma vez que o journal é para tolerar falhas e erros, e não protege 100% contra perda de dados. |
Metasploit – Instalação e utilização em ambiente GNU/Linux
Instalando
1. Visite a seguinte página e baixe a versão de instalação para GNU/Linux 32 ou 64 bits:
Salve o arquivo de instalação em uma pasta qualquer. Nesse tutorial será a pasta “Documentos”. 2. Abra o terminal como administrador. 3. Utilize o comando chmod +x para dar poder de execução ao arquivo baixado. Exemplo: # chmod +x /home/pedro/Documentos/metasploit-latest-linux-installer.run 4. Execute o arquivo com: # ./metasploit-lateset-linux-installer.run ![]() 5. Clique em “Avançar” para começar a instalação. 6. Marque: “I accept the agreement” → Clique em: “Avançar”. ![]() 7. Caso queira mudar a pasta de instalação ou clique em: “Avançar”. ![]() 8. Nesta etapa pode-se escolher registrar ou não no serviço. Neste caso escolheremos: “Yes”. ![]() 9. Deixe a porta default. Clique em: “Avançar”. ![]() 10. Escolha um nome para o servidor e clique em: “Avançar”. ![]() 11. Clique em “Avançar” para instalar. ![]() 12. Marque: “Access Metasploit Web UI” → Clique: “Finish”. ![]() 13. Aguarde cerca de 5 minutos e aparecerá essa tela para criação de login. 14. Após criado o login, clique em “GET PRODUCT KEY”, para obter a chave do Metasploit. 15. Selecione: “GET COMUNITY EDITION”. 16. Preencha o formulário e clique em: “Submit”. 17. A chave será mandada para o e-mail cadastrado, copie e cole ela, depois clique em: “ACTIVATE LICENSE”. 18. Pronto, o Metasploit está instalado e ativado. 19. Esta interface WEB é uma das interfaces que o Metasploit fornece para o usuário. Porém, utilizaremos o console do Metasploit chamado Msfconsole. Para executar, digite no terminal: msfconsole É aconselhável utilizar o Msfconsole em modo root. |
|
Definições / Metasploitable / Msfconsole
Definições básicasAntes de utilizarmos o Metasploit é importante conhecermos alguns conceitos:
MetasploitableA equipe do Metasploit fornece uma máquina virtual Ubuntu para testes, chamada Metasploitable e que, intencionalmente, possui diversas vulnerabilidades. Faça o download da Metasploitable e execute-a em algum software de virtualização, tal como VirtualBox ou VMware. MsfconsoleÉ possível utilizar o Metasploit através de várias interfaces, como a interface WEB utilizada na instalação ou através de linhas de comando. Neste tutorial, estaremos utilizando o Msfconsole, que fornece um interface com o framework do Metasploit baseada em console. O Msfconsole oferece recursos que tornam mais fácil o seu uso, tais como a auto-complementação de comandos (utilizando TAB) e a possibilidade de se usar comandos externos (nmap, por exemplo). Para utilizar o Msfconsole, basta digitar o comando no terminal: # msfconsole No Metasploit temos a ideia de módulos. Um módulo no Msfconsole é acessado por seu caminho completo em uma árvore de diretórios. Os módulos estão agrupados de acordo com suas características, como por exemplo, o seu tipo (exploit, payload, auxiliary, encoder, nop), sistema operacional, software vulnerável, etc. Por exemplo, um caminho para um exploit na maioria dos casos segue este padrão: exploit/sistema_operacional/tipo_do_serviço/ nome_do_módulo Esse tipo de organização adicionada do sistema de auto-complementação facilita muito a pesquisa por um módulo. ComandosA seguir estão alguns comandos básicos do Msfconsole: use < módulo > Este comando é utilizado sempre que queremos executar um módulo. ![]() back Usado para “sair” de um módulo. ![]() search < valor > Comando utilizado para pesquisar um módulo. É possível utilizar filtros de pesquisa, especificando o filtro como parâmetro e o valor procurado. Por exemplo, digitando: search plataform:windows Serão mostrados apenas módulos aplicáveis à plataforma Windows. show < valor > Mostra uma lista de módulos de acordo com o valor passado. Utilizado frequentemente dentro de um módulo (após o comando use), pois exibe somente os módulos “compatíveis” com o módulo utilizado no momento (principalmente no caso de estar se usando um exploit e procurando por um payload). Dentro de um módulo é possível também listar outras coisas além de módulos, como a configuração do módulo em questão ou os sistemas alvo disponíveis. set < parâmetro > < Valor > Utilizado para configurar os parâmetros de execução de um módulo. *info < módulo > Utilizado para exibir os detalhes de um módulo. Estando dentro de um módulo (após o comando use) não há a necessidade do parâmetro “< módulo >” para exibir as suas informações. Existem diversos outros comandos disponíveis que podem ser visualizados com o comando help. Para saber mais sobre o uso de um comando específico, basta digitar: < comando > -h |
|
Explorando sistemas vulneráveis
Para explorar as vulnerabilidades de um sistema, precisamos descobrir as portas que nele estão abertas e as aplicações que as utilizam. Podemos fazer isso de duas formas: utilizando o comando nmap ou módulos do próprio Metasploit.
Utilizando o nmap, digite no console: nmap -sV -O < ip_alvo > Os parâmetros “-sV -O” são utilizados para recuperar a versão do serviço que está utilizando uma porta e o sistema operacional alvo, respectivamente. Utilizando módulos do Metasploit, devemos pesquisar por algum que realiza a verificação de portas abertas. Digite no console: search scanner/portscan Após escolher o tipo de scanner, basta utilizar o comando use passando o caminho do módulo como parâmetro. Exemplo: use auxiliary/scanner/portscan/tcp ![]() Os parâmetros que um módulo utiliza são configuráveis, e alguns obrigatórios para a sua execução. Para verificar os parâmetros do módulo digite: show options Para configurar uma parâmetro, devemos digitar: set < nome_do_paramentro > < valor > Na coluna “Required”, observamos os parâmetros que o módulo necessita que estejam configurados para executar. Neste caso, por exemplo, devemos atribuir o endereço IP do sistema alvo ao parâmetro RHOSTS. Por exemplo: set rhosts 192.168.0.1 Uma vez configurado o módulo, digite o seguinte para executá-lo: run ![]() Como visto, ambas as abordagens exibem uma lista com as portas abertas no sistema alvo. A vantagem de se utilizar o nmap é que podemos obter informações mais detalhadas sobre as portas e sobre o sistema alvo, assim como configurar o modo sobre como a varredura será feita. A lista das portas encontradas é o que devemos utilizar como guia para os próximos passos. Uma vez descoberto um serviço, a porta que ele utiliza e o sistema operacional do alvo, é hora de utilizar os comandos do Msfconsole para pesquisar exploits e payloads, que estão relacionados com aquele serviço e sistema operacional. O primeiro passo: pesquisar um exploit. Como sabemos o serviço que utiliza determinada porta, podemos utilizar essa informação para refinar a nossa busca. Por exemplo, podemos utilizar o comando search com a seguinte configuração: search type:exploit name:mysql Neste caso, serão retornados somente exploits que estão relacionados com o MySQL. * Lembrando que o comando: info < módulo > pode ser utilizado para ver os detalhes de um módulo. Uma vez escolhido o exploit, é hora de configurá-lo. Com o comando show options, será exibida uma lista contendo informações sobre os parâmetros utilizados pelo exploit. Aqueles parâmetros que na coluna Required possuírem o valor “yes”, devem obrigatoriamente possuir um valor na coluna “Current Setting” para que o módulo seja executado. Para configurar um parâmetro, utilize o comando: set < parametro > < valor > ![]() Como dito anteriormente, o exploit faz o trabalho de invasão do sistema através de uma aplicação com vulnerabilidades. E após a invasão ele executa o payload para realizar alguma ação naquele sistema. Para configurar um payload para o exploit, digite o comando: show payloads Como estamos dentro de um exploit, será retornada uma lista contendo apenas os payloads compatíveis com o exploit em questão. Para utilizar um payload, digite o comando: set payload < payload > É preciso verificar novamente com o comando show options se os parâmetros do payload estão corretamente configurados. Caso nenhum payload seja configurado, após a invasão do exploit, o console funcionará como um terminal no sistema invadido. Após terminada a configuração, basta digitar o comando exploit para executar o exploit: |
|
Explorando uma vulnerabilidade no Android
Iremos agora explorar uma vulnerabilidade no sistema Android. Nesse teste estamos utilizando um aparelho com a versão 2.3 do sistema.
O primeiro passo é pesquisar um exploit para o Android: search android Se executarmos o comando: info auxiliary/gather/android_htmlfileprovider Veremos que, com esse exploit, é possível extrair arquivos do dispositivo a partir de uma conexão do browser do aparelho com a nossa máquina. O browser deve acessar um link no seguinte formato: http://ip_da_maquina_local (No meu caso: http://192.168.0.102/) Ao acessar o link o browser fará o download de um arquivo enviado pelo exploit e, quando o arquivo for aberto, será exibido no console o conteúdo dos arquivos que extraímos do dispositivo. Vamos então usá-lo: use auxiliary/gather/android_htmlfileprovider Se digitarmos: show options Veremos as configurações do exploit. Os seguintes parâmetros devem ser configurados (set < parametros > < valor >):
Agora basta executar o exploit com o comando: exploit Ao acessar o link no dispositivo Android, faremos o download de um arquivo HTML enviado pelo exploit. No Msfconsole veremos então o conteúdo dos arquivos que foram extraídos do dispositivo: ConclusãoCom o Metasploit, podemos explorar vulnerabilidades em vários tipos de sistemas. Independente do tipo a sequência de passos, na maioria das vezes, obedece um padrão. Quando não se tem ideia da configuração ou da existência de uma máquina alvo em uma rede, deve-se fazer a varredura de uma faixa de IPs utilizando comandos do GNU/Linux ou módulos do próprio Metasploit. Quando se conhece o IP do sistema alvo e suas respectivas portas e serviços associados a estas, basta utilizar o comando search do Metasploit para encontrar módulos específicos para aquele sistema e serviço. Módulos novos surgem constantemente no Metaspoit, logo, é aconselhável atualizar a ferramenta periodicamente (digite msfupdate em um terminal). É possível também, desenvolver nossos próprios módulos. Procuraremos abordar esta parte de desenvolvimento de módulos em artigos futuros. Para maiores informações a respeito do Metasploit, acessem o site: E a comunidade oficial: |
Bonding para Heartbeat + Bonding para DRBD + OCFS2 + Debian Squeeze
Introdução
E aí, galera.
Aqui vou abordar a configuração de Bonding para termos a redundância de interfaces físicas para o serviço de HA, pois o Heartbeat vai trabalhar no bond0 e o DRBD + OCFS2, vai trabalhar no bond1. Estou utilizando o algoritmo round-robin, que faz o balanceamento dos dados, porém, temos outros algoritmos que podemos utilizar para o mesmo fim. Quero ganhar disponibilidade do servidor e aumentar a performance de acesso à rede, onde temos, às vezes, gargalos como no serviço do DRBD, que é um RAID 1 via rede. Como vai funcionar: aqui vamos agrupar 2 interfaces para montar um bond para o Heartbeat e agrupar as outras 2 interfaces para montar o bond para o DRBD. Caso caia alguma das interfaces por causa de algum problema de hardware, o servidor vai continuar funcionando, pois temos uma interface de “Backup” trabalhando, caso as duas estejam funcionando, vamos fazer o balanceamento de carga entre elas e, com isso, melhorando a performance. Prepare o seu sistema com o seguinte script, para que não falte nenhum pacote ou configuração: Pré-requisitos
|
|||||||||
Instalação e configuração do Bond
Agora, vamos mandar atualizar os repositórios e instalar os pacotes para o bond no servidor srv01:
# aptitude update && aptitude install ifenslave ethtool -y Agora vamos acertar a configuração dos módulos do kernel: # echo “options bonding mode=0 miimon=100” >> /etc/modprobe.d/bonding.conf Vamos verificar se todas as interfaces estão com link: # mii-tool Saída:
Agora, vamos acertar a configuração de rede para o bonding: # vim /etc/network/interfaces Edite:
Agora, precisamos reiniciar o servidor: # reboot E vamos listar as nossas interfaces, para verificar se subiu o bond e os endereços IPs: # ifconfig A saída seria:
O bonding para o srv01 já está OK, agora vamos configurar o srv02. Vamos mandar atualizar os repositórios e instalar os pacotes para o bond no servidor srv02: # aptitude update && aptitude install ifenslave ethtool -y Acertar a configuração dos módulos do kernel: # echo “options bonding mode=0 miimon=100” >> /etc/modprobe.d/bonding.conf Verificar se todas as interfaces estão com link: # mii-tool Saída:
E acertar a configuração de rede para o bonding: # vim /etc/network/interfaces
Agora, precisamos reiniciar o servidor: # reboot Agora, vamos listar as nossas interfaces para verificar se subiu o bond e os endereços IPs # ifconfig
Vamos testar agora, a conectividade entre os dois, iremos mandar pingar do srv01 para o srv02: # ping -c 3 10.101.0.26 Vejamos o resultado:
Agora, vamos mandar pingar do srv02 para o srv1: # ping -c 3 172.20.0.25 Resultado:
Agora que o bond está pronto, vamos configurar o Heartbeat para garantirmos um IP virtual compartilhado entre os servidores, que é o que o cliente vai utilizar para acessar os serviços. Este IP, sempre vai setar o servidor que for definido como master, e caso ele caia por algum motivo, o servidor slave vai assumir este IP, e o cliente nem vai notar que está trabalhando em outro servidor. Vamos acertar o arquivo de hosts, deixe o arquivo como o abaixo nos dois servidores. # vim /etc/hosts
|
|||||||||
Instalação e configuração do Heartbeat
Agora, vamos instalar o Heartbeat no srv02:
# aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y Vamos acertar a configuração do Heartbeat: # vim /etc/ha.d/ha.cf
Agora, vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat: # vim /etc/ha.d/haresources srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
Explicando o arquivo acima:
Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats: # vim /etc/ha.d/authkeys auth 3
3 md5 h34rt64t Agora vamos acertar as permissões do arquivo de senha: # chmod 600 /etc/ha.d/authkeys Agora vamos instalar o Heartbeat no srv02: # aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y Acertar a configuração do heartbeat: # vim /etc/ha.d/ha.cf
Agora vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat: # vim /etc/ha.d/haresources srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats: # vim /etc/ha.d/authkeys auth 3
3 md5 h34rt64t Agora vamos acertar as permissões do arquivo de senha: # chmod 600 /etc/ha.d/authkeys Agora vamos reiniciar o Heartbeat nos dois servidores: # /etc/init.d/heartbeat restart Agora no servidor master (o srv01), vamos consultar os endereços IPs: # ifconfig
Agora no servidor slave (o srv02) vamos consultar os endereços IPs: # ifconfig
Como pode ser notado, temos o IP 10.101.0.27/24 no servidor srv01, que é o master. Agora vamos fazer um teste: vamos deslitar o servidor srv01: # telinit 0 Agora no servidor srv02 vamos consultar os endereços IPs: # ifconfig
Note que o endereço IP 10.101.0.27/24, já foi atribuido ao servidor srv02, pois ele é o slave; então, caso o cliente esteja conectado em algum serviço, ele não vai notar quando trocar de servidor. Agora vamos ligar novamente o servidor srv01 e consultar novamente: # ifconfig
Note que o IP compartilhado voltou para o servidor srv01, pois definimos ele como master. A primeira parte já está OK, que era garantir um IP compartilhado que vai ser utilizado pelo cliente. Pense que no servidor srv01, temos um site rodando, e este site está também no servidor srv02, com isso, o cliente vai acessar o: http://10.101.0.27 …E vai para o servidor master disponível, que em nosso caso, vai ser o srv01. Caso o master caia, o cliente vai acessar as páginas que estão no servidor srv02, e nem vai sentir que ele está acessando outro servidor. 😉 Mas, note que ainda temos um problema: os dados têm que ser sincronizados manualmente entre os servidores, por isso que vamos utilizar agora o DRBD + OCFS2, que vai trabalhar como um RAID 1 via rede, espelhando os dados em tempo real. Então, caso seja alterado um arquivo qualquer na partição do DRBD, o outro servidor já vai ter acesso a essas novas informações. Aqui vou utilizar o OCFS2, que é um sistema de arquivos distribuido, onde podemos trabalhar com os nodos sendo !master/master, ou seja, qualquer um dos servidores podem alterar qualquer arquivo, e esse arquivo vai aparecer alterado para a outra ponta. |
|||||||||
Instalação e configuração do DRBD + OCFS2
Agora, vamos instalar o DRBD e o OCFS2, faça isso nas duas máquinas:
# aptitude install drbd8-utils ocfs2-tools ocfs2-tools-dev -y Agora vamos carregar os módulos (faça isso nas duas máquinas): # modprobe cn Vamos configurar o DRBD. Deixe o arquivo como abaixo nas duas máquinas: # vim /etc/drbd.conf include “drbd.d/global_common.conf”;
#include “drbd.d/*.res”; Execute nas duas máquinas a parte abaixo. Vamos fazer backup do arquivo de configuração original: # cp /etc/drbd.d/global_common.conf{,.bkp} Deixe o arquivo como abaixo: # vim /etc/drbd.d/global_common.conf
Agora, vamos preparar o disco, faça isso nos dois servidores: # fdisk /dev/sdb Vai aparecer as peguntas:
Aqui, tecle w para escrever as mudanças no disco. E por fim, q para sair. Agora vamos zerar as partições (tem que ser executado nos dois servidores): # dd if=/dev/zero of=/dev/sdb1 bs=1M count=128 Execute este comando nos dois servidores, antes de passar para o próximo comando: # drbdadm — –discard-my-data connect r1 Onde “r1”, é o nome do nosso dispositivo, que no arquivo de configuração do DRBD, está como resource r1. Execute este comando nos dois servidores, antes de passar para o próximo comando: # drbdadm create-md r1 Execute este comando nos dois servidores, antes de passar para o próximo comando: # drbdadm attach r1 Execute este comando nos dois servidores, antes de passar para o próximo comando: # drbdadm connect r1 Pronto, agora podemos iniciar o DRBD. Inicie-o nos dois servidores com o seguinte comando: # /etc/init.d/drbd start Podemos observar como está a situação do nosso dispositivo DRBD, com o seguinte comando: # cat /proc/drbd Exemplo:
Se em “Connected st” estiver como Primary/Primary, está tudo OK, porém, se estiver como “Secondary/Secondary”, temos que forçar os dispositivos a passarem para primary, e temos mais uma situação quanto ao dispositivo Unknown, normalmente é quando um dos servidores não está operante por problemas de rede, ou de configuração do arquivo do DRBD. Então, muita atenção a esses detalhes. Vamos levar em consideração que só estamos com o problema que os dois servidores estão como secondary, resolvemos com o seguinte comando. Este comando tem que ser rodado nos dois servidores: # drbdadm — –overwrite-data-of-peer primary r1 Agora vamos monitorar novamente: # cat /proc/drbd Resultado:
Agora, é só esperar eles sincronizarem os dados, isso depende da placa de rede, da velocidade do disco e do tamanho do disco, fora os processos do DRBD, se você notar muita lentidão em algum desses fatores, veja se não é bom fazer algum upgrade. Para acompanhar a sincronização, pode utilizar o seguinte comando: # cat /proc/drbd Agora depois de sincronizados:
Agora, vamos configurar o OCFS2 Vamos configurar o cluster para o OCFS2. Tem que ser configurado nos dois servidores: # vim /etc/ocfs2/cluster.conf Edite:
Agora vamos configurar o O2CB, para ser habilitado (tem que ser configurado nos dois servidores): # sed -i ‘s/O2CB_ENABLED=false/O2CB_ENABLED=true/g’ /etc/default/o2cb Agora é so restartar o serviço nos dois servidores: # /etc/init.d/o2cb restart E criar o sistema de arquivos OCFS2 no DRBD, precimos fazer isso somente em um dos dois servidores. Opções:
# mkfs.ocfs2 -b 4K -C 128K -N 2 -L ocfs2 /dev/drbd1 Montando a partiçãoVamos criar um diretório para o OCFS2 nos dois servidores, e vamos montar: # mkdir /ocfs2 Vamos agora verificar nossas partições: # df -Th Resultado:
Como podemos ver, temos nossa partição montada com OCFS2. Agora podemos deixar isso na inicialização do sistema: # vim /etc/fstab Acrescentando: /dev/drbd1 /ocfs2 ocfs2 _netdev,defaults 0 0
Agora vamos ajustar a ordem de inicialização dos serviços, no dois servidores. Vamos primeiro acertar o DRBD nos dois servidores: # vim /etc/init.d/drbd Deixe como: # Deixe a opção Default-Start como abaixo
# Default-Start: S Agora temos que acertar o o2CB nos dois servidores: # vim /etc/init.d/o2cb Adicione/edite: # Temos que inserir a opção drbd para que ele inicialize depois que subir o dispositivo
# Required-Start: $network drbd Agora temos que recarregar as configurações de inicialização dos serviços. Vamos tirar os serviços da inicialização primeiro: # insserv -r -v ocfs2 Agora vamos colocar eles na inicialização novamente: # insserv -f -v drbd Agora vamos reiniciar os servidores para testarmos se vai ser montado o DRBD na inicialização: # init 6 Depois, da inicialização nodo1: # uptime Saída:
# df -Th Saída:
Depois, da inicialização nodo2: # uptime Saída:
# df -Th Saída:
Caso dê algum problema na inicialização, como um dos dois servidores não ficar como primary, podemos resolver da seguinte maneira: – Primeiro vamos mandar desmontar as partições montadas com o OCFS2 nos dois servidores: # umount /ocfs2 – Agora vamos mandar reiniciar o DRBD nos dois servidores: # /etc/init.d/drbd restart – Agora vamos forçar a utilização dos dois nodos primary: # drbdadm — –overwrite-data-of-peer primary r1 – Depois, é só remontar as partições novamente nos dois servidores: # mount.ocfs2 /dev/drbd1 /ocfs2/ Erros de sincronismoExemplo de erro de sincronismo dos discos, aonde perdemos a consistência dos dados, com isso, vamos precisar acertar este erro: # cat /proc/drbd Resultado:
No nodo2, vamos mandar ele desconsiderar os dados que ele já tem e ressincronizar com o nodo1: # drbdadm — –discard-my-data connect r1 Agora vamos verificar a sincronismo: # cat /proc/drbd Resultado:
Assim que terminar este processo, precisamos somente forçar os dois como primary da seguinte forma: # drbdadm — –overwrite-data-of-peer primary r1 O discos ainda sincronizando e forçados como primary: # cat /proc/drbd
|
|||||||||
Plus de Heartbeat
Pense que você precisa fazer o HA de um servidor de FW, por exemplo.
O que tem de diferente? Você poderia perguntar. Pense nas interfaces de rede: Temos no mínimo 2 interfaces, uma WAN e uma LAN. Neste caso, precisaríamos configurar o Heartbeat para atribuir endereços virtuais para as duas interfaces. Vamos a um exemplo, vou utilizar as interfaces de bond mesmo. Agora vamos instalar o Heartbeat no srv02: # aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y Agora vamos acertar a configuração do Heartbeat: # vim /etc/ha.d/ha.cf Edite:
Agora vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat: # vim /etc/ha.d/haresources srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
srv01 IPaddr::172.20.0.27/24/bond1/172.20.0.255 Explicando o arquivo acima:
Agora vamos acertar o arquivo com a senha de autenticação entre os Heartbeats: # vim /etc/ha.d/authkeys auth 3
3 md5 h34rt64t Agora vamos acertar as permissões do arquivo de senha: # chmod 600 /etc/ha.d/authkeys Agora vamos instalar o Heartbeat no srv02: # aptitude update && aptitude dist-upgrade -y && apt-get install heartbeat heartbeat-dev -y Agora vamos acertar a configuração do Heartbeat: # vim /etc/ha.d/ha.cf
Agora, vamos acertar a configuração do nosso IP compartilhado pelo Heartbeat: # vim /etc/ha.d/haresources srv01 IPaddr::10.101.0.27/24/bond0/10.101.0.255
srv01 IPaddr::172.20.0.27/24/bond0/172.20.0.255 Agora, vamos acertar o arquivo com a senha de autenticação entre os Heartbeats: # vim /etc/ha.d/authkeys auth 3
3 md5 h34rt64t Agora vamos acertar as permissões do arquivo de senha: # chmod 600 /etc/ha.d/authkeys Agora vamos reiniciar o Heartbeat nos dois servidores: # /etc/init.d/heartbeat restart Agora vamos consultar as interfaces no servidor srv01: # ifconfig Resultado:
Aqui, o que é preciso mudar são as interfaces, caso não trabalhe com o bond e os endereços IPs. 😉 |
SSH – Tradução da man page
Sinopse / Descrição
Nome:
SSH – Cliente OpenSSH SSH (programa de login remoto) Sinopse: ssh [ -1246AaCfgKkMNnqsTtVvXxYy ] [ -b bind_address ][ -c cipher_spec ] Descrição: O SSH (cliente SSH) é um programa para conectar-se e executar comandos em máquina remota. É proposital substituir o “rlogin” e o “rsh” e prover comunicações criptografadas de forma segura entre dois hosts não confiáveis sobre uma rede não segura. As conexões X11 e portas TCP arbitrárias, também podem ser encaminhadas através do canal seguro. O SSH conecta-se e faz o login em um hostname específico (com nome de usuário opcional). O usuário deve provar sua identidade à máquina remota usando um dos vários métodos, dependendo da versão usada do protocolo (veja abaixo). Se o comando é especificado, ele é executado em um host remoto ao invés de um acesso shell. As opções estão a seguir: -1 :: Obriga o SSH a tentar somente a versão 1 do protocolo; -2 :: Obriga o SSH a tentar somente a versão 2 do protocolo; -4 :: Obriga o SSH a usar somente endereços IPv4; -6 :: Obriga o SSH a usar somente endereços IPv6; -A :: Ativa o encaminhamento de uma conexão de autenticação de agente. Isto também pode ser especificado numa base por host em um arquivo de configuração. O agente encaminhado deve ser ativado com cuidado. Usuários com a habilidade de ignorar arquivos de permissões em um host remoto (para o socket Unix-domain do agente) podem acessar o agente local pela conexão encaminhada. Um atacante não pode obter material chave de um agente, porém, ele pode executar operações nas chaves que permite sua autenticação usando identidades carregadas no agente. -a :: Desativa o encaminhamento da conexão da autenticação do agente; -b bind_address :: Usa bind_address na máquina local como o endereço origem da conexão. É útil somente em sistemas com mais de um endereço. -C :: Requer compressão de todos os dados (incluindo stdin, stdout, stderr, e dados encaminhados via X11 e conexões TCP). O algoritmo de compressão é o mesmo usado pelo gzip(1), e o “nível” pode ser controlado pela opção “CompressionLevel” da versão 1 do protocolo. A compressão é desejada em linhas de modem e outras conexões mais lentas, mas irá somente diminuir as coisas em conexões rápidas. O valor padrão pode ser definido em uma base host-para-host nos arquivos de configuração. Veja a opção compressão: -c cipher_spec :: Seleciona a especificação de cifra para criptografar a sessão. A versão 1 do protocolo permite a especificação de uma cifra única. Os valores suportados são “3des”, “blowfish”, e “des”:
Para a versão 2 do protocolo, cipher_spec é uma lista de cifras separadas por vírgula listadas em ordem de preferência. Veja a palavra-chave “Ciphers” para mais informações. -D [bind_address:]porta :: Especifica um encaminhamento de uma porta de nível de aplicação local “dinâmica”. Funciona alocando um socket para escutar a porta no lado local, opcionalmente limitado pelo específico “bind_address”. Quando uma conexão é feita nessa porta ela é encaminhada sobre o canal seguro, e o protocolo da aplicação é depois usado para determinar onde se conectar na máquina remota. Atualmente os protocolos SOCKS4 e SOCKS5 são suportados, e o SSH irá atuar como um servidor SOCKS. Somente o usuário root pode encaminhar portas privilegiadas. Encaminhamentos dinâmicos de portas podem ser especificados no arquivo de configuração. Endereços IPv6 podem ser especificados com uma sintaxe alternativa: [ bind_address/]porta Ou colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão a porta local é limitada de acordo com a configuração do GatewayPorts. Porém um “bind_address” explícito pode ser usado para ligar a conexão com o endereço específico. O “bin_address” de “localhost” indica que a porta escutada pode ser limitada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces. -e escape_char :: Define o caractere de escape para sessões com tty (default: “~”). O caractere de escape é somente reorganizado no começo de uma linha. Se o caractere de escape for seguido por um ponto (‘.’) fecha a conexão; seguido por Ctrl-Z suspende a conexão; e seguido por si mesmo envia o caractere de escape uma vez. Definindo o caractere como “none”/”nenhum” desativa quaisquer escapes e torna a sessão completamente transparente. -F configfile :: Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração é passado por linha de comando, o arquivo de configuração de todo o sistema (/etc/ssh/ssh_config) será ignorado. O padrão para um arquivo de configuração por usuário é: ~/.ssh/config. -f :: Pede para o SSH ir para background antes da execução do comando. É útil se o SSH vai perguntar por senhas ou frases secretas, mas o usuário o quer em background. Isto implica em “-n”. O modo recomendado para iniciar programas X11 em um site remoto é com alguma coisa do tipo: ssh -f host xterm. Se a opção de configuração “ExitOnForwardFailure” for definida como “yes”, logo, um cliente iniciado com “-f” irá esperar por todos os encaminhamentos das portas remotas serem estabelecidas com sucesso antes de colocarem a si mesmos em background. -g :: Permite hosts remotos conectarem-se à portas de encaminhamento locais. -I smartcard_device :: Especifica o dispositivo que SSH deve usar para se comunicar com um smartcard usado para guardar a chave privada RSA dos usuários. Esta opção está disponível apenas se o suporte para dispositivos smartcards forem compilados (padrão não é suportado). -i identity_file :: Seleciona um arquivo de onde cada identidade (chave privada) para autenticações RSA ou DAS são lidas. O padrão é ~/.ssh/identity para a versão 1 do protocolo, e ~/.ssh/id_rsa e ~/.ssh/id_dsa para a versão 2 do protocolo. Arquivos de identidade devem ser especificados em uma base por host em um arquivo de configuração. É possível ter múltiplas opções “-i” (e múltiplas identidades especificadas em um arquivo de configuração). -K :: Ativa a autenticação GSSAPI e encaminha (delegação) das credenciais GSSAPI para o servidor. -k :: Desativa o encaminhamento (delegação) das credenciais GSSAPI para o servidor. -L [bind_address:]port:host:hostport :: Especifica que a porta passada no host local (cliente) deve ser encaminhada para o host passado e porta no lado remoto. Isso funciona basicamente alocando-se um socket para escutar uma porta no lado local, opcionalmente ligada ao “bind_address”. Sempre que uma conexão é feita nessa porta, a conexão é encaminhada sobre o canal seguro, e a conexão é feita na porta do host (host port) da máquina remota. Encaminhamentos de portas podem ser especificados em um arquivo de configuração. Endereços IPv6 podem ser especificados com uma sintaxe alternativa: [ bind_address/]port/host/hostport Ou, colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é ligada de acordo com a configuração GatewayPorts. Porém, um “bind_address” explícito pode se usado para ligar a conexão a um endereço específico. O “bind_address” de um “localhost” indica que a porta que escuta seja ligada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces. -l login_name :: Especifica o usuário a logar na máquina remota. Isto também pode ser especificado em uma base por host em um arquivo de configuração. -M :: Coloca o cliente SSH no modo “master” para compartilhamento de conexão. Múltiplas opções “-M” coloca o SSH no modo “master” com confirmação necessária antes que conexões escravas sejam aceitas. Veja a descrição do ControlMaster em “ssh_config(5)” para mais detalhes. -m mac_spec :: Adicionalmente, para o protocolo versão 2, uma lista de algoritmos MAC (código de autenticação de mensagem) separada por vírgulas pode ser especificada em ordem de preferência. Veja a palavra chave MAC para mais informações. -N :: Não executa um comando remoto. Pode ser útil apenas para portas de encaminhamento (apenas protocolo versão 2). -n :: Redireciona a saída “stdin” para /dev/null (na verdade, previne a leitura do “stdin”). Deve ser usado quando o SSH roda em background. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo: $ ssh -n shadows.cs.hut.fi emacs & Irá iniciar um Emacs em shadows.cs.hut.fi, e a conexão X11 será automaticamente encaminhada sobre um canal criptografado. O programa SSH irá ser colocado em background (isso não funciona se o SSH precisar perguntar por uma senha ou frase secreta. Veja também a opção: -f). -O ctl_cmd :: Controla uma conexão ativa multiplexando processos mestre. Quando a opção “-O” é especificada, o argumento “ctl_cmd” é interpretado e passado para o processo mestre. Os comandos válidos são:
-o option :: Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isto é útil para especificar opções que não são separadas por uma flag de linha de comando. Para detalhes completos das opções listadas abaixo, e seus possíveis valores, veja o “ssh_config(5)”:
-p porta :: Porta para conectar no host remoto. Isto pode ser especificado em uma base por host no arquivo de configuração. -q :: Modo quieto. Faz com que a maioria das mensagens de aviso e diagnóstico sejam suprimidas. Apenas erros fatais são exibidos. Se um segundo “-q” é dado, então, mesmo erros fatais são suprimidos, exceto aqueles produzidos por argumentos errados. -R [endereço_de_ligação:]porta:host:porta_do_host :: Especifica que a dada porta no host (servidor) remoto será direcionada para o host e porta dados no lado no local. Isto funciona por meio de uma alocação de socket para escutar a porta no lado remoto, e quando a conexão é feita nesta porta, a conexão é direcionada sobre um canal seguro, e uma conexão é feita para host na porta “porta_do_host” da máquina local. Direcionamento de portas pode também ser especificado no arquivo de configuração. Portas privilegiadas só podem ser direcionadas quando estiver logado como root na máquina remota. Endereços IPv6 podem ser especificados por meio de uma inclusão do endereço entre colchetes ou usando uma sintaxe alternativa: [bind_address/]host/port/hostport Por padrão o socket que está escutando no servidor será ligado para a interface de loopback somente. Isto pode ser sobrescrito especificando um endereço_de_ligação. Um endereço_de_ligação vazio, ou o endereço ‘*’, indica que o socket remoto deve escutar em todas as interfaces. Especificando um endereço_de_ligação remoto só irá ter sucesso se a opção GatewayPorts do servidor estiver habilitada (veja: ssh_config(5) ). Se o argumento porta for ‘0’, a porta de escuta será dinamicamente alocada no servidor e reportada para o cliente em tempo de execução. Quando usado junto com “-O forward”, a porta alocada será impressa na saída padrão. -S caminho_ctl :: Especifica a localização de um socket de controle para compartilhamento de conexão, ou a cadeia “none” para desabilitar o compartilhamento de conexão. Consulte a descrição de ControlPath e ControlMaster em ssh_config(5) para mais detalhes. -s :: Pode ser usado para requisitar uma invocação de um subsistema no sistema remoto. Subsistemas são uma característica do protocolo SSH2 o qual facilita o uso do SSH como um transporte seguro para outras aplicações (ex.: sftp(1)). O subsistema é especificado como o comando remoto. -T :: Desativa a alocação de pseudo-tty. -t :: Força a alocação pseudo-tty. Isto pode ser usado para executar programas arbitrários baseados em tela em uma máquina remota, o qual pode ser muito útil, por exemplo, quando estiver implementando serviços de menu. Múltiplas opções “-t” forçam a alocação tty, mesmo se o SSH não tem um tty local. -V :: Mostra o número da versão e sai. -v :: Modo de detalhe. Faz o SSH imprimir mensagens de depuração sobre o seu progresso. Isto é útil para depurar problemas de conexão, autenticação e configuração. Múltiplas opções “-v” aumentam o detalhamento. O máximo é 3. -w – local_tun[:remote_tun] :: Requisita um encaminhamento de dispositivo de encapsulamento com os dispositivos tun(4) especificados entre o cliente (local_tun) e o servidor (remote_tun). Os dispositivos podem ser especificados por ID numérico ou pela palavra-chave “any” (qualquer), que faz utilizar o próximo dispositivo de encapsulamento disponível. Se “remote_tun” não for especificado, “any” é utilizado por padrão. Veja também as diretivas Tunnel e TunnelDevice em ssh_config(5). Se a diretiva Tunnel estiver indefinida, será definido o modo de encapsulamento padrão, que é “point-to-point” (ponto-a-ponto). -X :: Habilita o encaminhamento de X11. Isto pode ser especificado por host no arquivo de configuração. O encaminhamento de X11 deve ser habilitado com cuidado. Usuários com a habilidade de contornar permissões de arquivos no host remoto (para o banco de dados de autorização X do usuário) podem acessar o display X11 local através da conexão encaminhada. Uma pessoa pode atacar e conseguir fazer atividades como monitoramento de teclas pressionadas. Por esta razão, o encaminhamento X11 está sujeito, por padrão, à extensão de restrições X11 SECURITY (segurança). Por favor, refira-se à opção “-Y” do SSH e a diretiva ForwardX11Trusted no “ssh_config(5)” para mais informações. -x :: Desativa o encaminho de X11. -Y :: Habilita o encaminhamento confiável de X11. O encaminhamento confiável de X11 não está sujeito aos controles de extensão X11 SECURITY. -y :: Envia informações do log utilizando o módulo de sistema syslog(3). Por padrão, esta informação é enviada para stderr. O SSH, adicionalmente, poderá obter dados de configuração de um arquivo de configuração por usuário e um arquivo abrangente do sistema. O formato do arquivo e as opções de configuração, são descritos em “ssh_config(5)”. O SSH sai com o status de saída do comando remoto, ou com 255, se um erro ocorrer. |
|
Autenticação
O cliente SSH do OpenSSH suporta os protocolos SSH 1 e 2. O protocolo 2 é o padrão, com SSH voltando para o protocolo 1 se detectar que o protocolo 2 não é suportado. Estas configurações podem ser alteradas usando a opção Protocol em “ssh_config(5)”, ou impostas usando as opções “-1” e “-2” (veja acima).
Ambos os protocolos suportam métodos semelhantes de autenticação, mas o protocolo 2 é preferível, pois proporciona mecanismos adicionais de confidencialidade (o tráfego é encriptado usando AES, 3DES, Blowfish, CAST128, ou Arcfour) e integridade (HMAC-MD5, HMAC-SHA1, UMAC-64, HMAC-RIPEMD160). O protocolo 1 carece de um forte mecanismo para assegurar a integridade da conexão. Os métodos disponíveis para autenticação são:
Métodos de autenticação são tentados na ordem especificada acima, embora o protocolo 2 tenha uma opção de configuração para mudar a ordem padrão: “PreferredAuthentications”. A autenticação baseada em host funciona da seguinte maneira. Se a máquina que o usuário logar estiver listada em /etc/hosts.equiv ou /etc/ssh/shosts.equiv na máquina remota, e o nome dos usuários é o mesmo em ambos os lados, ou, se os arquivos ~/.rhosts ou ~/.shosts existirem no diretório HOME do usuário na máquina remota e conter uma linha contendo o nome da máquina cliente e o nome do usuário naquela máquina, o usuário é considerado para logar. Adicionalmente o servidor precisa ser capaz de verificar a chave de host do cliente (veja a descrição de /etc/ssh/ssh_known_hosts e ~/.ssh/known_hosts, abaixo) para o login ser permitido. Este método de autenticação fecha buracos na segurança devido ao IP spoofing, DNS spoofing, e spoofing de roteamento. ** Nota para o administrador: /etc/hosts.equiv, ~/.rhosts e o protocolo rlogin/rsh, em geral, são inerentemente inseguros e devem ser desativados se a segurança é desejada. A autenticação por chave pública funciona da seguinte maneira: O esquema é baseado na criptografia de chave-pública, usando criptosistemas onde a encriptação e decriptação são feitas usando chaves separadas, e é inviável derivar a chave de decriptação através da chave de encriptação. A ideia é que cada usuário crie um par de chaves pública/privada para o propósito de autenticação. O servidor conhece a chave pública, e somente o usuário conhece a chave privada. O SSH implementa o protocolo de autenticação por chave pública automaticamente, usando o algoritmo RSA ou DAS. O protocolo 1 é restringido a usar somente chaves RSA, mas o protocol 2 pode usar qualquer um. A seção HISTORY de “ssl(8)” (em sistemas não-OpenBSD, veja em HISTORY) contém uma breve discussão dos dois algoritmos. O arquivo ~/.ssh/authorized_keys lista as chaves públicas que são permitidas para efetuar logon. Quando o usuário loga, o programa SSH diz ao servidor qual par de chaves gostaria de usar para a autenticação. O cliente prova que tem acesso à chave privada e o servidor checa que a chave pública correspondente está autorizada a aceitar a conta. O usuário cria seu par de chaves executando ssh-keygen(1). Isto armazena a chave privada em ~/.ssh/identity (protocolo 1), ~/.ssh/id_dsa (protocolo 2 DSA), ou ~/.ssh/id_rsa (protocolo 2 RSA) e armazena a chave pública em ~/.ssh/identity.pub (protocolo 1), ~/.ssh/id_dsa.pub (protocolo 2 DSA), ou ~/.ssh/id_rsa.pub (protocolo 2 RSA) no diretório HOME do usuário. O usuário deve, então, copiar a chave pública para ~/.ssh/authorized_keys em seu diretório HOME na máquina remota. O arquivo “authorized_keys” corresponde ao arquivo ~/.rhosts convencional, e tem uma chave por linha, embora as linhas podem ser muito longas. Depois disto, o usuário pode efetuar logon sem dar o password. A maneira mais conveniente de usar autenticação por chave pública pode ser com um agente de autenticação. Veja “ssh-agent(1)” para mais informações. A autenticação desafio-resposta funciona da seguinte maneira. O servidor envia um “desafio” arbitrário em texto, e espera por uma resposta. O protocolo 2 permite múltiplos desafios e respostas; o protocolo 1 é restrito a apenas um desafio/resposta. Exemplos de autenticação desafio-resposta incluem autenticação BSD (veja login.conf(5)) e PAM (para alguns sistemas não-OpenBSD). Finalmente, se outros métodos de autenticação falharem, o SSH pede uma senha para o usuário. A senha é enviada para o host remoto para ser checada; entretanto, já que todas as comunicações são encriptadas, a senha não pode ser vista por alguém que esteja escutando a rede. O SSH, automaticamente, mantém e checa um banco de dados contendo uma identificação de todos os hosts com que ele já foi usado. As chaves do host são armazenadas em ~/.ssh/known_hosts no diretório HOME do usuário. Adicionalmente, o arquivo /etc/ssh/ssh_known_hosts é automaticamente checado para hosts conhecidos. Quaisquer novos hosts são automaticamente adicionados ao arquivo do usuário. Se a identificação de um host mudar, o SSH alerta sobre isto e desativa a autenticação por senha para prevenir ataques de spoof de servidor ou man-in-the-middle, que poderiam caso contrário ser usados para circundar a encriptação. A opção StrictHostKeyChecking pode ser usada para controlar logins em máquinas cuja chave hospedeira não é conhecida ou tenha mudado. Quando a identidade do usuário for aceita pelo servidor, ou o servidor executa o comando dado, ou loga na máquina e dá ao usuário um shell normal na máquina remota, todas as comunicações com o comando remoto ou shell vão ser automaticamente encriptados. Se um pseudo-terminal foi alocado (sessão normal de login), o usuário poderá usar os caracteres de escape escritos abaixo. Se nenhum pseudo-tty foi alocado, a sessão é transparente e pode ser usada para transferir dados binários confiavelmente. Na maioria dos sistemas, definindo o caractere de escape para “none”, também fará a sessão ser transparente mesmo se um tty for utilizado. A sessão finaliza quando o comando, ou shell na máquina remota, sai e todas conexões X11 e TCP são fechadas. |
|
Caracteres / Encaminhamento / Chaves de host
Caracteres de escapeQuando um pseudo-terminal for requisitado, o SSH suporta um número de funções através do uso de um caractere de escape. Um simples til (~) pode ser enviado como “–“, ou colocando um caractere na frente no til que não esteja descrito abaixo. O caractere de escape deve sempre seguir uma quebra de linha para ser interpretado como especial. O caractere de escape pode ser trocado nos arquivos de configuração usando a diretiva de configuração EscapeChar ou na linha de comando pela opção “-e”. Os escapes suportados (assumindo o padrão ‘-‘) são:
Encaminhamento TCPO encaminhamento de conexões TCP arbitrárias, sobre o canal seguro, podem ser especificadas ou na linha de comando ou no arquivo de configuração. Uma possível aplicação para o encaminhamento TCP é uma conexão segura para um servidor de correio eletrônico; outra é ir através de firewalls. No exemplo abaixo deparamos com a encriptação da comunicação entre um cliente e servidor IRC, mesmo que o servidor IRC não suporte comunicações encriptadas diretamente. Isto funciona da seguinte maneira. O usuário conecta no host remoto usando SSH, especificando uma porta para ser usada para encaminhar conexões para o servidor remoto. Depois disso pode-se iniciar o serviço o qual será encriptado na máquina cliente, conectando na mesma porta local, e o SSH irá encriptar e encaminhar a conexão. O exemplo a seguir encapsula uma sessão IRC da máquina cliente “127.0.0.1” (localhost) para o servidor remoto “server.example.com”: $ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 Isto encapsula uma conexão para o servidor IRC “server.example.com”, unindo ao canal “#users”, com nickname “pinky”, usando a porta 1234. Não importa qual porta é usada, desde que seja maior que 1023 (lembre-se: somente o root pode abrir sockets em portas privilegiadas) e não conflita com qualquer porta que já esteja em uso. A conexão é encaminhada para a porta 6667 no servidor remoto, já que esta é a porta padrão para serviços IRC. A opção “-f” faz o SSH ficar em background e o comando remoto “sleep 10” é especificado para permitir uma quantidade de tempo (10 segundos, no exemplo) para iniciar o serviço que irá ser encapsulado. Se nenhuma conexão for feita no tempo especificado, o SSH sairá. Encaminhamento X11Se a variável ForwardX11 estiver definida como “yes” (ou veja acima a descrição das opções “-X”, “-x”, e “-Y”) e o usuário estiver usando X11 (a variável de ambiente DISPLAY está definida), a conexão para o display X11 é automaticamente encaminhada para o lado remoto, de tal maneira que, quaisquer programas X11 iniciados pelo shell (ou comando) irão através do canal encriptado, e a conexão para o verdadeiro servidor X será feita a partir da máquina local. O usuário não deve definir DISPLAY manualmente. Encaminhamento de conexões X11 podem ser configuradas pela linha de comando ou nos arquivos de configuração. O valor definido para DISPLAY pelo SSH irá apontar para a máquina servidor, mas com um número de display maior que zero. Isto é normal, e acontece porque o SSH cria um servidor X “proxy” na máquina servidor para encaminhar conexões sobre o canal encriptado. O SSH também irá definir dados Xauthority automaticamente na máquina servidor. Para este fim, ele criará um cookie de autorização aleatória, armazená-lo em Xauthority no servidor, e verificar que as conexões encaminhadas que carregam esse cookie e substituí-lo pelo cookie real quando a conexão é aberta. O cookie de autenticação real nunca é enviado para a máquina servidor (e nenhum cookie é enviado na íntegra). Se a variável ForwardAgent é definida como “yes” (ou veja a descrição das opções “-A” e “-a”, acima) e o usuário está usando um agente de autenticação, a conexão com o agente é automaticamente encaminhada para o lado remoto. Verificando chaves de hostAo se conectar a um servidor pela primeira vez, um fingerprint (impressão digital) da chave pública do servidor é apresentado ao usuário (a menos que a opção foi StrictHostKeyChecking desativada). Fingerprints podem ser determinados usando “ssh-keygen(1)”: $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key Se o fingerprint já é conhecido, ele pode ser comparado e a chave pode ser aceita ou rejeitada. Por causa da dificuldade de comparar chaves de host só de olhar para cadeias hexadecimais, também há suporte para comparar chaves de host visualmente, usando arte aleatória. Ao definir a opção VisualHostKey para “yes”, um pequeno gráfico ASCII é exibido em cada login para um servidor, não importando se a sessão em si é interativa ou não. Ao aprender o padrão que um servidor conhecido produz, um usuário pode facilmente descobrir que a chave de host mudou quando um padrão completamente diferente é exibido. Por causa que estes padrões não são ambíguos no entanto, um padrão que se parece com o padrão lembrado apenas dá uma boa probabilidade de que a chave de host é a mesma, e não uma prova garantida. Para obter uma lista dos fingerprints, juntamente com sua arte aleatória para todos os hosts conhecidos, a seguinte linha de comando pode ser usada: $ ssh-keygen -lv -f -/.ssh/known_hosts Se o fingerprint é desconhecido, um método alternativo está disponível: “fingerprints de SSH verificados por DNS”. Um registro de recurso (RR) adicional, SSHFP, é adicionado a um zonefile (arquivo de zonas) e o cliente que está conectando poderá comparar o fingerprint com aquele da chave apresentada. Neste exemplo, estamos conectando um cliente para um servidor (host.example.com). O registro de recurso SSHFP deve, primeiramente, ser adicionado ao zonefile para “host.example.com”: $ ssh-keygen -r host.example.com As linhas de saída terão de ser adicionadas ao zonefile. Para verificar que a zona está respondendo consultas de impressões digitais: $ dig -t SSHFP host.example.com Finalmente, o cliente conecta:
Para mais informações, veja o VerifyHostKeyDNS, opção em “ssh_config(5)”. |
|
Base Virtual / Ambiente / Files
SSH – Base Virtual de Redes PrivadasSSH contém suporte para Virtual Private Network (VPN) tunnelling usando tun(4) rede pseudo-device permitindo que duas redes se juntem de forma segura. O “sshd_config(5)”, opção de configuração PermitTunnel, controla se o servidor suporta isso, e em que nível (camada 2 ou 3 de tráfego). O exemplo a seguir, iria ligar a rede cliente “10.0.50.0/24” com a rede remota “10.0.99.0/24” usando uma conexão ponto-a-ponto a partir de “10.1.1.1” a “10.1.1.2”, desde que o servidor SSH esteja rodando no gateway para a rede remota, em “192.168.1.15”, permitir. No cliente: # ssh -f -w 0:1 192.168.1.15 true No servidor: # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 O acesso do cliente pode ser mais afinado através do arquivo /root/.ssh/authorized_keys (veja abaixo) e a opção do servidor PermitRootLogin. A entrada a seguir, permitirá conexões em tun(4) dispositivo 1 para o usuário “Jane” e em tun dispositivo 2 para o usuário “john”, se PermitRootLogin é definido para “forced-commands-only”: tunnel=”1″,command=”sh /etc/netstart tun1″ ssh-rsa … jane
tunnel=”2″,command=”sh /etc/netstart tun2″ ssh-rsa … John Desde que uma instalação SSH-based implica em certa quantidade de sobrecarga, pode ser mais adequado para instalações temporárias, como para VPNs sem fio. VPNs mais permanentes são melhores fornecidas por ferramentas, como “ipsecctl(8)” e “isakmpd(8)”. AmbienteSSH normalmente define as seguintes variáveis de ambiente:
Além disso, o SSH lê ~/.ssh/environment, e adiciona linhas do formato “VARNAME = value” para o ambiente, se o arquivo existe, e os usuários têm permissão para mudar seu ambiente. Para mais informações, consulte o PermitUserEnvironment opção em “sshd_config(5)”. Files
Veja também
|
Jogos PS1 no emulador ePSXe – Sem lags em placas lentas
Requisitos e procedimentos
Estamos carecas de saber que a placa de vídeo SiS 661/671 (e as outras também) têm desempenho baixo, bem diferente do Windows, onde pelo menos o driver para SiS 661/671 tem suporte à aceleração 2D e 3D.
Então jogos pesados e que exigem o vídeo em fullscreen no GNU/Linux com esses tipos de placas de vídeos estão fora de escolha, pois nestas placas não vai rolar nada de bom. (rsrs)
Mas não pense que basta ter qualquer placa de vídeo lenta que isto irá dar certo. Pelo menos no Windows, a placa de vídeo deve ter um desempenho razoável, pois os desenvolvedores de drivers preferem produzir os produtos para o sistema do tio Bill, e é por isso que o desempenho é bom nesse sistema operacional. O desempenho no GNU/Linux poderá ser alcançado também.
Mas fuçando em tudo, descobri que jogos de PS1 rodam liso, pelo menos na minha SiS, e estou trazendo este artigo para habilitar sua placa de vídeo para rodar os jogos de PS1, sem lag. 😀
Sendo que sua placa precisa ter, pelo menos, os requisitos mínimos para que o emulador ePSXe faça a sua parte sem problemas e com desempenho.
Os requisitos mínimos, são:
- Processador: Pentium 200 MHz;
- RAM: 256 MB;
- Sistema operacional: GNU/Linux ou Windows;
- CD-ROM: 16x ou mais rápido (opcional).
Bom, vamos começar.
Se você não tem ou não sabe configurar o ePSXe, veja a dica postada aqui no VOL por um user que não está mais entre nós:
Depois que o seu ePSXe está configuradinho e rodando os seus jogos (com lag), vamos ao segredo que vai deixar os jogos rodando liso, até em fullscreen em seu emulador.
O segredo é, nada mais nada menos, que um plugin de vídeo (ohhhh!!).
O plugin usa sistema/modo gráfico “Software”, foi por isso que os requisitos sobre placa de vídeo eu não pude determinar, pois o segredo de tudo isso é o plugin de vídeo para o emulador.
Procedimentos
Informações sobre o plugin:
Vamos baixar o plugin para o ePSXe:
Faça os procedimentos para aplicar o plugin ao emulador em seu terminal:
$ wget http://www.pbernert.com/gpupeopssoftx118.tar.gz
$ tar -vzxf gpupeopssoftx118.tar.gz
$ sudo cp libgpuPeopsSoftX.so.1.0.18 /opt/epsxe/plugins/
$ sudo cp gpuPeopsSoftX.cfg /opt/epsxe/cfg/
* Aviso: “/opt/epsxe/plugins/” é um exemplo do diretório onde o emulador está instalado, e este diretório foi baseado no diretório padrão do emulador instalado pelo pacote “epsxe” para o Arch Linux disponível no AUR.
Então você deve substituir este diretório pelo local onde o emulador está instalado.
Configuração
Agora vamos abrir o ePSXe (recomendo abrir pelo terminal):
$ sudo epsxe
Obs.: Você deve abrir com sudo, pois o diretório e as configurações são salvas em locais onde um usuário normal não pode manusear com todos os direitos, caso contrário, qualquer configuração será perdida ao encerrar.
Após abrir o emulador ePSXe, vamos às configurações:
- Vá em: Config → Vídeo
- Em: “Select Vídeo Plugin”, selecione: “P.E.Op.S. SoftX Driver 1.18”
- Clique em: “Configure”
Enfim, siga o exemplo:
-Resolution-
*Fullscreen mode: 320×200Windowed mode: 320×200
Stretching mode: 0:Full size stretch
Dithering: 1:Game dependend-Framerate-
Show FPS display on startup (opcional ativar)
*Use FPS limit
*Auto-detect FPS/Frame skipping limit
*Use Frame skipping
Framerate: 100.0 FPS*Use SSSPSX Frame limit
NOTA: Onde houver “*” na frente do item acima, é porque você deve marcar/ativar a opção ou configuração.
Prontinho. Se você não conseguiu acompanhar a parte sobre como configurar o plugin, veja na figura abaixo o print do plugin já configurado: =D

Agora, meu amigo, seu equipamento será capaz de rodar todos os jogos compatíveis com o emulador.
Bom, isso que eu estou ensinando hoje é o essencial, mas há configurações extras que podem melhorar ainda mais.
Resumo LPI 102: Tópico 107 – Tarefas Administrativas
107.1 – Administrar contas de usuários e grupos
Em mais um resumo de tópico para a prova LPI 102, venho percebendo a facilidade em estudar usando associação. Com comandos de modo geral, procure saber para que ele serve e o que significa.
Alguns são bem intuitivos, por exemplo, o passwd (password), lsusb (list usb), nc (netcat), chfn (change information). Outros, são mais complicados. Geralmente comandos com ch, tem algo a ver com change (alteração, mudança), ls com list (listar). Estar atento e disposto a associar os nomes dos comandos facilitará e MUITO seu estudo. O mesmo vale para parâmetros. Leia, ao menos, a descrição nas páginas de manual e faça testes, simule situações, se você ainda não passa boa parte do dia de frente pra tela preta. Contas de usuáriosO comando adduser só pode executado pelo root. Cria usuários automaticamente, com parâmetros definidos no arquivo: /etc/adduser.conf O comando useradd só pode ser executado como root. Cria usuário setando manualmente os parâmetros desejados. Indicado para uso em scripts. Principais parâmetros:
O diretório /etc/skel/ serve como modelo na criação dos diretórios pessoais. Skel = Skeleton (esqueleto). O comando passwd altera a senha de usuários. Sintaxe: # passwd <usuário> Ou seja, como root, é possível alterar a senha de qualquer usuário. Como usuário comum, somente é possível alterar a própria senha. O comando chfn (change information) altera o campo descrição da conta de um usuário. Não precisa ser root. O comando chsh (change shell) altera o shell padrão do usuário. Não precisa ser root. O comando userdel exclui uma conta de usuário. Parâmetro principal: “-r” (remove) – remove o diretório pessoal. O arquivo /etc/passwd armazena informações de contas de usuários e pode ser lido por qualquer usuário (permissão: rw-r–r–). Utiliza como separador de campos o “:” (2 pontos). Observe a estrutura: root:x:0:0::/root:/bin/bash
Enumerando os campos:
O comando vipw usa o editor padrão do sistema (Vi) para alterar o arquivo /etc/passwd, bloqueando-o contra edições concorrentes. Parâmetro principal: -s (shadow) – edita o arquivo /etc/shadow, usando o modelo de bloqueio. No arquivo /etc/shadow estão as senhas criptografadas dos usuários e mais algumas configurações. Não está visível para todos usuários, por medida de segurança (permissão: rw-r—–). Seu separador de campos também é o “:”. Estrutura: root:<senha>:15516:0:99999:7:::
Enumerando os campos:
O comando pwconv altera o armazenamento das senhas do arquivo /etc/passwd para o /etc/shadow. O comando pwunconv altera o armazenamento das senhas do arquivo /etc/shadow para o /etc/passwd. O comando chage altera informações referentes à validade de senhas de usuário. Parâmetros principais:
O comando usermod modifica contas de usuários. Parâmetros principais:
Administrando grupos de usuáriosO comando groupadd cria um grupo de usuário. Principal parâmetro: -g (GID) – Especifica um ID para o grupo. O comando groupdel exclui um grupo de usuário. O comando gpasswd insere e exclui usuários de grupos e realiza algumas modificações relacionadas às senhas. Este comando usado sem parâmetro cria uma senha para um grupo. Principais parâmetros:
O comando groups mostra o grupo que o usuário pertence. Usado sem argumentos, mostra os grupos do usuário atual. O comando id mostra os grupos do usuário e informações de UID e GID. O comando newgrp altera o grupo principal do usuário. Caso ele não pertença, é adicionado automaticamente. O arquivo /etc/group armazena informações dos grupos. Possui permissão: rw-r–r– Estrutura: adm:x:5012:pedro,joao
Enumerando os campos:
O comando vigr edita o arquivo /etc/group, evitando gravações concorrentes. Principal parâmetro: -s (shadow) – Edita o arquivo /etc/gshadow. O arquivo /etc/gshadow armazena informações de senhas com criptografia. Possui permissão: rw–r—- Estrutura: adm:*::pedro
Enumerando:
O comando grpconv converte o armazenamento das senhas dos grupos, do arquivo /etc/group para o /etc/gshadow. O comando grpunconv faz o inverso do comando grpconv. O comando groupmod realiza algumas modificações nos grupos. Principais parâmetros:
|
|
107.2 – Automatizar e agendar tarefas administrativas
O comando at é usado para agendar a execução de um comando/script apenas uma vez.
Sintaxe: # at <quando> <comando> O argumento “<quando>” pode ser:
Usuários comuns podem usar o “at”, se constarem no arquivo /etc/at.allow. Se este arquivo não existir, o arquivo /etc/at.deny será lido e só não poderá usar o “at” quem constar nele. Se nenhum dos arquivo existirem, só o root poderá usar o “at”. Parâmetros e variações:
O cron é um daemon para agendamento de tarefas em determinados intervalos de tempo. A cada minuto este daemon verifica as tabelas de agendamento, chamadas crontabs, e executa as tarefas que estiverem configuradas. Principal crontab (ou tabela de agendamento): /etc/crontab :: Este é o crontab do sistema. Existem também um crontab para cada usuário. O comando crontab é para usuários específicos, ao invés do arquivo geral do sistema. Usamos o comando comando crontab, que editará a tabela de agendamento do respectivo usuário. Principais parâmetros:
Sintaxe: # crontab <parâmetro> <usuário> Configurando uma tabela de agendamento (ou crontab). O separador pode ser: 0-59 0-23 0-31 1-12 0-6 <comando>
Enumerando:
Exemplo real de utilização: * */4 * 5,6 1-5 /root/script.sh
Nesta linha, que poderia estar no arquivo /etc/crontab, por exemplo, executaria o arquivo “script.sh” a cada quatro horas, nos meses de maio e junho de segunda à quinta-feira. Explicando os caracteres utilizados no exemplo:
Diretórios auxiliares:
Estes diretórios são usados quando não é necessário especificar a hora para execução de uma tarefa. Arquivos para controle de utilização do contrab:
Obs.: Se os dois não existirem, todos os usuários poderão agendar tarefas. |
|
107.3 – Localização e internacionalização
Fuso horário:
O comando tzselect ajusta o fuso horário do sistema. Após configurado, é criado o arquivo /etc/timezone. O arquivo /etc/localtime guarda informações sobre o horário de verão. As opções de configuração estão no diretório /usr/share/zoneinfo. O comando locale exibe as variáveis de ambiente que contém informações de idioma e padrão de codificação do sistema. A variável LANG é uma variável global usada pela maioria dos programas, como referência para definição do idioma padrão. O conteúdo dessa variável obedece o formato idioma_PAIS.CODIFICAÇÃO. Exemplo: $ echo $LANG Neste caso, significa:
Obs.: Em scripts é recomendável setar a variável LANG dessa forma: LANG=C. Evitando assim resultados diferentes quando o script é executado em sistemas diferentes, com configurações diferentes. Outras variáveis de ambiente são importantes para a correta configuração de programas. São elas:
|