Anúncios

Arquivo

Posts Tagged ‘Windows’

Erro de Certificado no IIS


Olá pessoal

Passei por um problema recentemente e a solução dele é bem simples e pode ajudar muita gente, por isso resolvi compartilhar.

Fizemos o procedimento de renovação do Certificado Digital do nosso Webserver com IIS 6.0, tudo ocorreu normalmente e recebemos o certificado novo.

Quando instalamos o novo certificado, nenhuma página com HTTPS estava abrindo. O Navegador retornava um erro dizendo que não era possível estabelecer uma conexão segura com o servidor.

Ao analisar o problema verificamos o seguinte ao abrir o certificado instalado o trecho sublinhado abaixo visto na imagem não estava sendo exibido, estava tudo em branco.

Captura de Tela 2012-12-21 às 17.08.39

 

Ou seja o problema estava ocorrendo pois por algum motivo a chave privado do certificado tinha se perdido ou corrompido.

Para resolver isso basta fazer o seguinte digite o seguinte comando.

certutil -repairstore my “45 a6 1a a7 54 35 5a ec df b5 d3 73 5d 53 f6 1a 81 c6 68 6b”

Troque a sequência de números acima pelos número obtidos no certificado com problema, para isso abra o certificado vá na guia Detalhes selecione o campo Thumbprint você irá então obter os números corretos para executar junto ao comando acima.

Captura de Tela 2012-12-21 às 17.18.48

 

Feito isso o certificado passou a funcionar normalmente.

Espero que essa informação possa ser útil

Lembre-se também de compartilhar por gentileza

Meus agradecimento ao Adilson Oliveira que ajudou na resolução do problema

http://www.linkedin.com/pub/adilson-basilio-de-oliveira/20/539/402

Até a próxima

 

 

Anúncios

Tutorial: Usando o Armitage no Backtrack 5 para Pentest


Hoje gostaria de mostrar pra vocês alguns passos simples para usar o Armitage no Backtrack 5 R3

Como sabem essas informações devem ser usadas com responsabilidade.

O Armitage é uma ferramenta que auxilia no uso do Metasploit Framework, uma ferramenta bastante utilizada para fazer PenTest. Ela já vem instalada no Backtrack.

Nossa máquina alvo é um sistema Windows XP com Service Pack 3 Instalado, que está com o IP 192.168.2.93.

Você pode tentar com um sistema semelhante ou pode fazer o download dessa VM que é uma Máquina Virtual Linux intencionalmente com muitas vulnerabilidades que podem ser exploradas.

http://sourceforge.net/projects/metasploitable/

Vamos lá então

Abra o Armitage e o primeiro passo é adicionar a console nossa máquina alvo, para isso faça o seguinte:

Clique no menu Hosts e clique em Add Hosts

Digite o IP da máquina Alvo e clique Add

 

Na sequência vamos scanear o host por possíveis vulnerabilidades para isso clique com botão direito do mouse sobre o host que foi adicionado ao console e clique em “scan”

 

Aguarde a conclusão do scan que vai identificar as possíveis vulnerabilidades bem como o tipo de OS. Na sequência clique em “Attacks” e Depois em “Find Attacks”

 

Aguarde a conclusão da busca e na sequência de volta ao menu “Attacks” dessa vez selecione a opção “Hail Mary”, se você fizer tudo certo e o sistema alvo for vulnerável você verá uma mudança no ícone do Host semelhante a abaixo indicando que o sistema foi comprometido.

 

Agora é só ir explorando as possibilidades uma vez que o sistema foi comprometido.

Espero que tenham gostado da dica.

Se precisar de Consultoria para execução de um pentest acesse www.infrasecurity.com.br

Além disso lá você vai encontrar também outras opções de serviço como Suporte Técnico e Hospedagem.

Compartilhem.

Abraço

 

Lentidão ao acessar e salvar arquivos do Office na rede.


Olá a todos

Recentemente tive um problema que foi um tanto complicado até conseguir resolver. O problema foi o seguinte: Fizemos a migração de um servidor Windows Server 2003 para 2008 R2 com as funções de File Server, AD, DNS e DHCP, após essa migração porém foi notada extrema lentidão ao acessar arquivos do Office na rede, em especial, planilhas de excel, demora cerca de 1 minuto para salvar um simples arquivo. O Servidor é novo em com boa configuração, as estações também são novas e a rede é gigabit, mesmo assim havia extrema lentidão nesses arquivos. Ao copiar ou executar outros tipos de arquivos o acesso era normal, e apenas estações com Windows 7 tinham esse problema, clientes XP ou MAC não tinham essa dificuldade.

Após muita pesquisa descobri uma maneira que no meu caso resolveu o problema. Foi só desabilitar a indexação de arquivos offline no Windows 7 para isso faça o seguinte:

1 No menu iniciar digite “opções de indexação

2 Clique no botão “Modificar

3 Desmarque “Arquivos offline

4 Reinicie o computador

Ao reiniciar você estará acessando os arquivos normalmente, no meu caso, resolveu o problema e todas estação windows 7 estão acessando normalmente agora.

Espero que essa experiência possa ajudar aqueles que estão com o mesmo problema. Se este artigo lhe foi útil deixe um comentário, se tiver alguma dúvida ou alguma outra opinião também.

Grato.

Erro ao usar uma Imagem Windows 7 após Sysprep.


Olá a todos

Estava instalando e testando o WDS do Windows Server 2008 quando ao tentar usar uma imagem preparada com sysprep o computador não inicializava e apresentava uma mensagem como a abaixo

O Windows não pôde concluir a configuração do sistema. Para tentar retomar a configuração, reinicie o computador.

Pesquisando verifiquei que é necessário instalar esse hotfix aqui que disponibilizei para download bem como desativar o antivírus antes de executar o sysprep.

Após isso recriei a imagem e daí então funcionou normalmente.

Espero ter ajudado.

Dúvidas deixem um comentário.

Configurando o Failover Cluster para o Hyper-V (Parte 1)


A virtualização de servidores permite que os recursos do Hardware devam ser melhores aproveitados, mas a virtualização também aumenta os efeitos e riscos de falha de hardware. Esta série de artigos vai discutir por que o Failover Cluster pode ajudar a resolver este problema, e que também irá guia-lo através do processo de criação de um Failover Cluster para o Hyper-V.

Introdução

Ao longo dos últimos anos, a tecnologia de virtualização de servidores transformou completamente a área de TI. Apesar de tudo o que esta extraordinária tecnologia tem realizado, sempre houve uma grande desvantagem para virtualização de servidores. Para ser franco, ambiente virtualizados aumenta as apostas em caso de falha de hardware.

Pense nisso por um momento. Em um ambiente não virtualizado, se um servidor sofrer uma falha catastrófica de hardware seria mais provável ser um inconveniente. Claro, seria importante resolver o problema rapidamente, mas a falha de um único servidor, provavelmente não irá trazer um impacto brusco no negócio de uma organização. Mesmo se o servidor não esta funcionando, uma aplicação de missão critica, os usuários finais ao menos seria capaz de acessar recursos de rede, tais como e-mail, compartilhamento de arquivos e outras aplicações. Enquanto o problema está sendo corrigido.

Os servidores virtuais têm regras diferentes. Vários servidores virtuais normalmente residem em um único host físico. Como tal, se o host físico tiver alguma falha de hardware, então o resultado final seria equivalente à falha de várias máquinas em um ambiente não virtualizado.

É claro que os perigos de hospedar várias máquinas virtuais em um único servidor pode ser um problema, mesmo se uma falha de hardware não ocorrer. Por exemplo, recentemente ouvi falar de alguém que estava com algumas máquinas virtuais em um único host físico. O administrador decidiu que esse host precisava de mais memória, mas descobri u que para agendar uma parada nesse servidor que detém uma série de máquinas virtuais, e que algumas dessas máquinas virtuais fazem parte das regras de negocio do ambiente e não pode ficar fora sem um planejamento e sem informar as áreas envolvidas pode ser um grande problema.

Felizmente, a Microsoft criou o Windows Server 2008 R2 de uma forma que permite que o Hyper-V trabalhe com o Failover Cluster. O Failover Clustering para o Hyper-V pode ajudar a resolver todos os problemas que descrevi acima.

O melhor de tudo, um novo recurso chamado Live Migration permite mover máquinas virtuais entre nós do cluster sem ter que parar a máquina virtual (offline). Dessa forma, se você precisar parar um servidor para fazer algum tipo de manutenção, você pode simplesmente mover todas as máquinas virtuais para um nó diferente e realizar a manutenção necessária sem necessidade de agendar uma parada no seu ambiente.

O processo de instalação e configuração é relativamente simples, existem algumas dicas. Também constatamos que existem vários tutorias na Internet que estão incompletas. Então resolvi escrever esta série de artigos, como forma de oferecer à comunidade de TI a orientação e o processo de configuração.

Planejamento do Hardware.

Antes mesmo de começar a construir o Failover Cluster, você deve garantir que você tenha o hardware propriamente dito. Uma coisa que eu preciso dizer é que a Microsoft não dará suporte ao Hyper-V em Failover Clustering ao menos que todo o hardware que você for usar seja certificado para Windows Server 2008 R2. Isso não significa que você não pode usar um hardware não homologado. Quando iniciei a construção do meu Hyper-V em Failover Cluster no meu ambiente de laboratório, usei um hardware que fosse acessível ao meu orçamento, que certamente não é um hardware certificado para o uso do Windows Server 2008 R2, mas atendeu muito bem as minhas necessidades. No entanto, eu nunca iria recomendar a utilização desse tipo de hardware para um ambiente de produção, porque isso faria com que o se houvesse um problema certamente não teríamos o suporte da Microsoft.

Tenha em mente que não basta simplesmente comprar servidores que tenham sido certificados para a utilização com o Windows Server 2008 R2. O site da Microsoft diz que “a Microsoft suporta uma solução de Failover Cluster somente se todos os recursos de hardware forem marcados como “Certified for Windows Server 2008 R2”. O Site passa a indicar que mesmo as placas de rede que você usa devem ser certificadas para Windows Server 2008. Como tal, você pode inadvertidamente colocar seu cluster em um estado sem suporte a menos que você esteja atento para garantir que você está comprando apenas hardware certificado. A Microsoft fornece uma lista de hardware certificado.

http://www.windowsservercatalog.com/

Com isso em mente, os servidores que você irá usar como nós do cluster não tem que ser exatamente iguais, mas devem ter capacidades semelhantes. No mínimo, os servidores devem ter processadores de 64 bits e suporte a virtualização assistida por hardware. Além disso, você deve usar a mesma arquitetura de processadores para todos os nós do cluster (todos os processadores devem ser AMD ou Intel). Os servidores também devem ter suporte ao Data Execution Prevention, através do Intel XD bit ou AMD NX bit.

Os requisitos de rede para os nós do cluster vão variar dependendo do tipo de armazenamento que você está usando para o cluster. Nesta série de artigos, estarei mostrando como usar o armazenamento iSCSI, mas você também tem a opção de conectar os nós do cluster a uma SAN.

Minha recomendação geral seria a disposição de cada nó de cluster com três NICS (ou duas placas de rede e uma placa Fiber Channel se vocês forem usar um armazenamento com base em Fiber Channel). Uma dessas placas de rede é usada para comunicação entre o servidor (e as máquinas virtuais que residem nele). A segunda NIC é reservada para comunicação de Heartbeat entre os nós do cluster. A terceira NIC é dedicada a comunicação iSCSI com o volume de armazenamento compartilhado.

Em alguns casos, você pode achar que seus servidores simplesmente não podem acomodar três NICs. Por exemplo, o hardware que usei para o meu laboratório tinha apenas uma NIC e um slot de expansão, que usei para instalar uma segunda NIC. Este tipo de configuração é inferior a ideal, mas se você é forçado a usá-lo, então eu recomendo usar uma placa de rede para acesso à rede e usar a outra placa de rede para a comunicação do heartbeat e de tráfego iSCSI.

Também é possível que os servidores possam ter espaço para NICs adicionais. NICs adicionais podem ser úteis neste tipo de ambiente, por exemplo, você pode dedicar uma das placas de rede adicional para gerenciar o servidor físico (colocando o tráfego do servidor virtual em uma NIC separada). Da mesma forma, você pode ser capaz de dedicar uma placa de rede separada para cada maquina virtual. Outa abordagem é usar NICs de reposição para fornecer um grau de redundância. Eu não estou usando mais de três placas de rede por servidor neste artigo, mas você deve pelo menos estar ciente de que você pode usar placas de rede adicionais.

Conclusão

Agora que falei sobre alguns requisitos básicos de hardware, é hora de começar a construção do nosso failover clustering. Na parte 2 desta série de artigos, vou mostrar um método para a criação de armazenamento compartilhado entre os nós do cluster.