InfoFAQ

InfoFAQ

segunda-feira, 8 de agosto de 2016

Linux – Resolvendo erro: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Passei por isso e resolvi compartilhar com vocês.

Caso apareça uma mensagem parecida com esta para você:/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
fsck died with exit status 4.
Isso ocorre devido um erro na consistência de arquivos causados por uma ma atualização do sistemas ou desligamento repentino incorreto do sistema, para resolver execute esse comando como root:
# fsck.ext4 /dev/sda1
ou
# fsck.ext3 /dev/sda1
ou
# fsck.reiserfs /dev/sda1
e reinicie a máquina.
Sendo sda1 é a partição problemática citada por sua mensagem.


sexta-feira, 29 de julho de 2016

Migração do Servidor de Arquivos com as Ferramentas de Migração do Windows Server - Além do Robocopy

Para quem trabalha com infra-estrutura sabe o quanto é trabalhoso e “perigoso” migrar o servidor de arquivos, pois a migração deve envolver a transferência dos dados, bem como o controle de acesso (permissões), ou seja, quem tinha acesso antes da migração deve continuar a ter acesso, e quem não tinha acesso deve continuar a não ter.
Para ajudar nesse processo a Microsoft incluiu no Windows Server 2012 um módulo do Windows PowerShell que contém 5 cmdlets, esses cmdlets são chamados de Ferramentas de Migração do Windows Server. Existem dois cmdlets (Send-SmigServerData e Receive-SmigServerData) que trabalhando em conjunto permitem migrar “ao vivo” os compartilhamentos de arquivos e suas permissões para outro servidor.
No exemplo desse artigo o servidor origem é o Windows Server 2003 SP2 e o servidor de destino é o Windows Server 2012. Vou assumir que as Ferramentas de Migração já estejam instaladas em ambos os servidores.
Obs.: A instalação das ferramentas de migração são abordadas no meu artigo: Instalação das Ferramentas de Migração do Windows Server.
Vamos migrar o compartihamento Home Users, esse compartilhamento contém uma sub-pasta privativa para cada usuário. Veja a estrutura na imagem abaixo.
Img0
Observe a guia Segurança da pasta User1. Veja que somente os Administradores do domínio, o sistema, e o próprio usuário possuem acesso a pasta.
Img1
Supondo que as Ferramentas de Migração do Window Server já estejam instaladas no servidor de origem e no servidor de destino, siga os procedimentos a seguir:
1. No servidor de origem clique em: Iniciar >Ferramentas de Administrativas >Ferramentas de Migração do Windows Server >Windows Server Migration Tools.
image
2. A  transferência dos dados é criptografada por uma senha, por isso vamos criar um objeto de senha do Windows PowerShell:
$pwd = (Read-Host “Digite a Senha” –AsSecureString)
[image%255B35%255D.png]
3. Agora vamos enviar os dados, as configurações de compartilhamento, e as permissões NTFS para o computador SRV-2012.
Send-SmigServerData -include All -Computername SRV-2012 -SourcePath "C:\Home Users" -DestinationPath "H:\Home Users" -Recurse -Password $pwd -V
Img2
4. No servidor de destino Abra as Ferramentas de Migração do Windows Server
image
5. Crie um objeto de senha do Windows PowerShell com a mesma senha utilizada na etapa de envio. (Informe a mesma senha utilizada no envio dos dados.)
$pwd = (Read-Host “Digite a Senha” –AsSecureString)
Receive-SmigServerData –Password $pwd
image
Após o termino do processo de migração, verifique no servidor de destino as pastas, os dados, e as configurações de compartilhamento e NTFS.
Img4
Img5
6. Após a confirmação de que a migração ocorreu com sucesso, desconecte o servidor antigo da rede e refaça os mapeamentos de rede para apontarem para o novo servidor.
Obs.: Não copie e cole os comandos. Ao invés disso digite-os (a formatação pode invalidar o comando)



Que tal vocês testarem os seus conhecimentos hacker?

O pessoal que mantêm o www.100security.com.br/ acaba de lançar um wargame, uma ambiente controlado, vulnerável liberado para galera testar os seus conhecimentos hacker.
Mais detalhes poderão ser obtidos na seguinte URL www.100security.com.br/wargame



Pensar fora da caixa é fundamental, as vezes o que você acha improvável pode revelar segredos valiosos.

quarta-feira, 27 de julho de 2016

Windows – Onde o Usuário Logou ou está Logado?

Saber em qual Computador ou Servidor um determinado Usuário Logou ou está Logado pode ser necessário em um processo de Auditoria, e como já é de conhecimento de todos temos inúmeras formas de fazer isso, há muitas ferramentas que podem auxiliar neste levantamento.
Meu objetivo com este artigo é mostrar algumas das formas mais básicas e funcionais de se fazer isso em um ambiente de rede.
// Espero que possa ajudar alguém, deixe seus comentários sobre as formas ou soluções que você utiliza para ajudar outras pessoas.
Cenário:
Para facilitar o entendimento montei o cenário abaixo onde o objetivo é localizar onde os usuário 100SECURITY\marcos logou ou esta logado.
ul01

OPÇÃO 01 – PsLoggedon

Utilizando a ferramenta PsLoggedon.exe da SysInternals você pode saber quais usuários estão logados em um determinado host.
01 Passo
Após descompactar o arquivo PSTools.zip entre no diretório PsTools e execute o comando:
C:\>cd PsTools
C:\PsTools>PsLoggedon.exe -x \\SRV-2008
ul02
Resultado:
Os usuários abaixo estão logados no Servidor SRV-2008:
SRV-2008\Administrator
100SECURITY\marcos


OPÇÃO 02 – qwinsta e rwinsta

Você pode utilizar o comando responsável por exibir as informações sobre as sessões dos Serviços de Área de Trabalho Remota: qwinsta
01 Passo
Execute o comando qwinsta seguido do parâmetro /SERVER:<HOST>
C:\>qwinsta /SERVER:SRV-2008
ul03
Resultado:
São exibidas as sessões remotas que estão ativas no servidor SRV-2008
ul04
02 Passo
Caso você queira finalizar uma das sessões ativas basta utilizar o ID da sessão.
Execute o comando rwinsta
C:\>rwinsta 1 /SERVER:SRV-2008
ID 1 – Corresponde ao usuário Administrator
Em seguida execute o comando qwinsta novamente para certificar que a sessão foi finalizada.
ul05
Confirmando no Servidor: SRV-2008
ul06

OPÇÃO 03 – Active Directory | EventViewer | PowerShell

Quando um usuário loga no domínio o acesso é registrado no evento 4624 do Log Security e através deste evento é possível identificar em qual o ip do computador que o usuário esta ou estava utilizando no momento deste logon.
01 Passo
Dentro do servidor de Active Directory no exemplo DC-2012 acesse o Event Viewer > Windows Logs > Security e clique na coluna EventIDpara filtrar todos os eventos, em seguida localize o evento 4624
ul07
02 Passo
Escolha uma data e de um duplo-clique no evento 4624 para visualizar todo seu conteúdo.
Observe as linhas:
Account Name: marcos – Exibe o usuário que se logon no domínio.
Source Network Address: 192.168.1.201 – Informa em qual host o usuário marcos se logon, este IP refere-se ao servidor SRV-2008.
ul08
03 Passo
Utilizando o Power Shell você pode extrair todos os logons realizados pelo usuário marcos, basta executar o script abaixo:
// Crie a pasta auditoria para centralizar os relatórios.
PS C:\>cd .\auditoria
PS C:\auditoria>Get-EventLog -LogName Security -InstanceID 4624 | Where {$_.Message -match “Account Name:\s+marcos“}
ul09
Resultado:
Mostra que o usuário marcos se logou no domínio através do host 192.168.1.201
ul10

OPÇÃO 04 – Relatório de Conexões RDP em um Servidor

Este script em Power Shell vai ajudá-lo a identificar todos os LOGON/LOGOFF que foram realizados em um ou mais servidores incluindo o computador que foi utilizado para o acesso.
01 Passo
Realize o download do script: clique aqui em seguida execute-o.
PS C:\>.cd .\auditoria
PS C:\auditoria>.\relatorio_rdp.ps1
u11
Resultado:
data esta no formato americano mas você pode customizar o script como quiser.
ul12

Veja mais em: http://www.100security.com.br


quinta-feira, 21 de julho de 2016

MELHORES PRÁTICAS PARA PROTEGER O ACTIVE DIRECTORY

Conforme o tempo vai passando os domínios vão se modernizando, com novas estações, usuários e aplicativos inseridos. Mas com a atualização dos domínios, outras partes da infraestrutura vão sendo esquecidas e acabam dando brechas para ataques. Os invasores aproveitam destas lacunas para se inserirem no domínio e conseguirem senhas e privilégios de usuários importantes no seu Active Directory através de keylogger instalados na estação.
E é por causa da demanda cada vez maior, que temos que ter noção de como os invasores atacam o AD e saber quais são as melhores práticas recomendadas pela Microsoft.
active-directory-ad-microsoft
Algumas das partes da infraestrutura que acabam sendo “esquecidas” com o passar do tempo e acabam dando brechas para ataques, são:
  • S.O e aplicativos obsoletos: sistemas em que os fornecedores não dão mais suporte aos mesmos, acabando não surgindo novos upgrades para corrigir falhas;
  • Antivírus: não fazer a atualização dos antivírus nas estações e nos servidores, dando mais vulnerabilidade ao seu ambiente;
  • Dispositivos de funcionários pessoais ligados em rede: o uso compromete o seu domínio, uma vez que não sabemos quais programas estão instalados nestes dispositivos;
  • Utilização de ambientes mistos: é o uso de sistemas Microsoft e não Microsoft em seu ambiente, uma vez que acabam dando mais atenção à um e esquecendo do outro.
Algumas das práticas recomendadas para proteger seu AD são:
  • Monitorar Logs referentes ao Active Directory;
  • Fazer a desativação do usuário administrador local nas estações. (Caso precise utilizar o administrador local, podemos habilitá-lo no modo de segurança por uma GPO em que ative o mesmo temporariamente ou utilizar grupos restritos para este fim);
  • Não acessar estações não confiáveis com usuários que sejam administradores de empresa, domínio, etc;
  • Usar o mínimo privilégio possível aos usuários do AD (Ou seja, o usuário só deve ter permissão ao que ele irá fazer. Não dando nenhuma permissão a mais);
  • Reduzir os usuários dos Grupos Administradores do domínio, empresa, etc do seu AD;
  • Fazer a delegação de poderes administrativos. (Delegar poderes em relação a tarefa específica. Por exemplo: usuários que trabalham necessitando instalar impressoras em rede, atribua ao grupo Operadores de impressão e não um grupo mais elevado);

Apesar destas falhas não estarem diretamente ligadas ao Active Directory, elas são porta de entrada para o comprometimento do mesmo, uma vez que o invasor se aproveita dessas falhas para se proliferar na estação e depois obter senhas de usuários importantes no AD, tais como: Administradores do domínio, Administradores de empresa e Administradores de esquema.
Usuários estes em que podem comprometer todo seu domínio com alterações inadequadas. Outros usuários bastante vistos pelo invasores são os usuários VIPs. Estes usuários são aqueles que tem acessos importantes como a documentação da empresa e a dados sigilosos que podem consequentemente levar a senha dos usuários administradores do Active Directory.
Há outras importantes recomendações para o seu AD que serão postadas mais para frente. Caso tenha algo a complementar, por favor, deixe seu comentário abaixo!
Este artigo também pode ser visto em: https://diegogouveiace.wordpress.com

segunda-feira, 13 de junho de 2016

Convertendo Windows 2000 com o VMware Converter

Tradução: https://translate.google.com.br


Convertendo uma máquina Windows 2000 tem um monte de ressalvas e problemas quando se passa de físico para virtual (P2V), usando o VMware vCenter Converter Standalone. 


requisitos: 

  • VMware Standalone Converter versão 4.0.1 (ver informações adicionais no final)
  • Update Rollup 1 para o Windows 2000 SP4 ( KB891861 )
  • Windows 2000 ferramentas Sysprep ( Q257813 )
  • Um LiveCD Windows ou Linux. Eu recomendo Knoppix (6.4+ - Linux) ou Hiren (Windows). 
    Se você precisar modificar chaves de registro, use Hiren.

Procedimento:
  1. Instalar VMware Standalone Converter versão 4.0.1
  2. Extraia ferramentas Sysprep e colocá-los em C: \ Documents and Settings \ All Users \ Application Data \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k 
    Isso deve ser na mesma máquina que tem VMware Converter, não o servidor Windows 2000. 
    * No Windows 2008, o local é C: \ Users \ All Users \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k (! Graças anónimo para a ponta) 
    ou C: \ ProgramData \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k (! graças Ben)
  3. Quer aplicar o pacote cumulativo de atualizações para o servidor ou extrair o conjunto de actualizações e substituí-lo com as SCSIPORT.SYS arquivo em C: \ WINNT \ system32 \ drivers. Aplicando a atualização é recomendada se o sistema é estável.
  4. Se você estiver usando um IP estático no servidor Windows 2000, consulte este artigo da Base de Conhecimento .
  5. Execute o Converter e implantar o agente. Se você for solicitado para reiniciar, reinicie, em seguida, iniciar o serviço VMware Converter manualmente antes de executar o conversor novamente, caso contrário ele vai lhe pedir para implantar o agente novamente.
  6. Na Etapa 3: Veja Opções / Editar, clique no painel de dispositivos e alterar o controlador de disco para BusLogic SCSI.
  7. Manter o número de processadores como está, porque se você alterá-lo, Windows 2000 não irá dar auto-detectar novos CPUs e você precisa atualizar a camada de abstração de hardware (HAL) sobre ele manualmente. Veja KB234558 e KB249694 para obter mais detalhes.
  8. No painel Redes, desmarque a opção de se conectar a alimentação.
  9. No painel Opções avançadas, não selecione as opções para desligar a fonte e selecione a opção para ligar o alvo (VM). Não instalar ferramentas VMware. 
    Não selecione "configurar as preferências dos hóspedes para a máquina virtual"
Com isso, você deve ser definido para converter essa máquina. Após a conversão for concluída, a VM vai começar, instalar ferramentas de VMware, em seguida, reinicie. Depois que ele vem até você deve aplicar as configurações de rede adequadas, em seguida, desligar e permitir que o NIC para ligar ao ligar.

Problemas e Soluções:
  • "Disco de leitura de erro" ao iniciar a máquina virtual. 
    Isso acontece porque você selecionou o controlador de disco como "Preserve Fonte" ou "IDE" - você deve selecionar "SCSI" - depois de fazer isso, você vai precisar para reconverter a máquina.
  • "Kmode_Exception_Not_Handled" tela azul da morte (BSOD) durante a inicialização. 
    Isso acontece porque o Windows 2000 está usando o driver SCSI de idade (SCSIPORT.SYS). 
    Você deve inicializar em um LiveCD e substituir o arquivo no local mencionado acima. 
    Isto aconteceu-me mesmo depois de eu copiou os SCSIPORT.SYS para a máquina de destino antes de converter.
  • Depois de instalar o agente Converter, você enfrenta problemas e reiniciar o servidor Windows 2000, em seguida, ao executar o conversor novamente, ele pede-lhe para re-implantar o agente. 
    Isso acontece porque quando o sistema Windows 2000 surge novamente, o serviço do agente Converter não é iniciado novamente. 
    Abra o console de serviços (services.msc na pista) e clique com o botão direito VMware Converter em seguida, escolha Iniciar. Depois que o serviço é iniciado, executar VMware Converter e ele deve se conectar.
  • Não é possível comunicar ao agente. 
    O tráfego de rede provavelmente está bloqueada por firewalls que estão na máquina Converter, a máquina de destino Windows 2000 ou no meio. Verifique se os firewalls estão desativados ou porta 9089 é permitido passar.
  • "Dispositivo de arranque inacessível" tela azul da morte (BSOD) durante a inicialização. 
    Isso acontece devido a algum erro de configuração dos motoristas no Registro. 
    Para corrigir isso, execute o programa Converter novamente e fazer uma reconfiguração máquina só (não reconverter). Deixá-lo instalar o VMware Tools, selecione "máquina virtual de destino Reconfigurar" e não selecionar "Configurar preferências dos hóspedes para a máquina virtual" 
    Se isso não resolver o seu problema, leia esta lista de discussão .

Usando O LiveCD Linux:
Se você é novo no Linux, então aqui estão alguns passos para ajudá-lo a substituir arquivos em máquinas virtuais.

  1. Inicializar a máquina virtual a partir do LiveCD, por qualquer anexando o arquivo ISO do armazenamento de dados, a sua máquina, ou queimar a ISO em um CD (como uma imagem!) E inicializando-lo da sua unidade de CD.
  2. No prompt de inicialização do Knoppix, apenas pressione Enter para inicializar a interface gráfica.
  3. Agora precisamos anexar rígido da VM para o sistema Linux: abra um shell de root / terminal.
  4. Tipo: fdisk -l 
    Isto irá listar todos os discos em sua VM. Identifique o seu disco rígido do sistema operacional (por capacidade, se possível). Se não for possível, então prosseguir com os próximos passos até encontrar a sua partição desejada por olhar para o seu conteúdo. 
    Você vai ver coisas como: / dev / sda, / dev / sda1, / dev / sda2, ... etc. sda é o seu primeiro disco rígido. sdb é o seu segundo disco rígido. sda1 é a primeira partição no seu primeiro disco rígido.
  5. Tipo: mkdir / mnt / os
  6. Se o seu sistema operacional (OS) é instalado no primeiro disco rígido, primeira partição, em seguida, digite: mount / dev / sda1 / mnt / os
  7. Agora você pode abrir um gerenciador de arquivos na interface gráfica e ir para este diretório: / mnt / os - você verá o conteúdo da partição. 
    Se isso não é sua partição desejado, passe para a etapa 10, em seguida, tentar montar outra partição. 

    Nota: Certifique-se de montar uma partição e não um disco! 
    mount / dev / sda1 é correto. mount / dev / sda não é.
  8. Para copiar um arquivo através da rede a partir de um compartilhamento do Windows em outra máquina, abrir um gerenciador de arquivos e no tipo de guia endereço: smb: // ip 
    Exemplo: smb: //192.168.0.1, onde o IP é da máquina que você deseja acessar através da rede para copiar um arquivo de.
  9. Botão direito do mouse e copiar o arquivo, em seguida, ir para / mnt / os e colá-lo lá.
  10. Você está quase pronto. Agora você só precisa desmontar a partição, então feche a janela do gerenciador de arquivos que abre / mnt / os e, em seguida, no tipo de shell de root: umount / mnt / os
  11. Reinicie o VM e Solte o CD / ISO.

Informação adicional:
  • Knoppix é como qualquer sistema * nix: maiúsculas e minúsculas quando se trata de nomes de arquivos. Então você pode ter que apagar o arquivo original manualmente copie o novo arquivo .SYS, devido à diferença no caso de letra.
  • As ferramentas Sysprep será usado pelo conversor VMware para preparar uma nova cópia do Windows. É requerido para o processo de clonagem.
  • Suporte para Windows 2000 tiver caído no VMware Converter versão 4.3.
  • VMware Converter Standalone é gratuito. VMware exige que você se registrar para poder fazer o download, mas os seus servidores são lentos (pelo menos na minha experiência). Eu tenho a minha cópia do 4shared, então basta procurá-lo e verificar o MD5 checksum. 
    Do Windows: VMware-converter-4.0.1-161434.exe - 35f22a3b40b114d70cdbda2d5056c10f 
    Linux: VMware-converter-4.0.1-161434.tar.gz - 90ce68a9f75af91aed9119d419a98b3c
  • Seleção LiveCD: você pode escolher qualquer coisa que funciona para você, desde que ele tem drivers de disco SCSI, caso contrário você não será capaz de ver os discos da VM (que é por isso recebendo Damn Small Linux foi uma perda de tempo ...) e pode ler e escrever para o sistema de arquivos NTFS.

Fonte: http://mbhtech.blogspot.com.br