Habilitando a lixeira do AD

terça-feira, 17 de outubro de 2017
Posted by Rafael Holanda

Limitar largura de banda no Microsoft Azure Backup

Procedimentos:

  • 01- Acesse o cliente do Microsoft Azure Backup
                       
  • 02- Clique em propriedades

  • 03-  Navegue até “Limitação” e selecione o Check Box “Habilitar limitação de recurso de banda” e configure como deseja e pressione ok.


      Observações: 
  • O tempo de backup e restauração são proporcionais á largura de banda.
  • A largura mínima de banda da rede para o backup é 1 MB por segundo. O backup pode apresentar falha com erros de tempo limite se a largura de banda for inferior a 1 MB por segundo.
  • A hora da restauração também é proporcional à latência de rede, especialmente se você estiver tentando restaurar um arquivo de uma região do Windows Azure geograficamente diferente da instância do SQL Server que você está tentando restaurar. 


Uma opção muita útil devido algumas situações em que o ambiente possui um provedor com limite de utilização de upload.
quarta-feira, 14 de junho de 2017
Posted by Rafael Holanda

Power BI (desktop) - Data Gateway Pessoal - Instalando e agendando atual...







sexta-feira, 9 de junho de 2017
Posted by Rafael Holanda

Criando alta disponibilidade no Linux com heartbeat (HA)




Dois servidores:

SERVER01 192.168.10.1
SERVER02 192.168.10.2
IP Virtual: 192.168.10.10

Aqui vamos usar como nome dos servidores: “SERVER01” e “SERVER02”. Os nomes devem corresponder aos nomes das próprias máquinas (hostname).

O IP Virtual corresponde ao ip que será compartilhado entre os dois servidores. Através do IP Virtual na verdade estaremos acessando o servidor que estiver como master no momento do acesso. Esse comportamento será controlado pelo heartbeat.

Insira as linhas abaixo no arquivo /etc/hosts nos dois servidores:

192.168.10.1 SERVER01
192.168.10.2 SERVER02

Para configurar o heartbeat de forma eficaz, dedique uma interface de rede nos dois servidores que serão conectados diretamente através de um crossover. É através dessa interface que o heartbeat determinará a disponiblidade dos nós.

Instalando heartbeat

A instalação do heartbeat em sistemas baseados em debian é bem simples:

$ sudo apt-get install heartbeat

Configuração do hearbeat

1. Arquivo /etc/ha.d/ha.cf

O conteúdo deve ser idêntico nos dois servidores:

use_logd yes
keepalive 1
deadtime 10
warntime 5
initdead 120
bcast eth4
node SERVER01
node SERVER02
auto_failback off

Descrição dos parâmetros:

use_logd yes – habilita log do heartbeat.
keepalive 1 – tempo em segundos entre um “heartbeat” e outro.
deadtime 10 – Tempo que o heartbeat aguarda por uma resposta até determinar que o nó esta morto.
warntime 5 – Tempo que o hearbeat aguarda por uma resposta para disparar um aviso de atraso (late warning).
initdead 120 – Quando você reinicia todas as máquinas do cluster ao mesmo tempo, pode haver uma diferença de tempo entre as máquinas até que subam todos os serviços. Esse parâmetro cuida dessa situação. Esse tempo é contado somente quando o heartbeat inicia o seu serviço.
bcast eth4 – eth4 seria a interface usada pelo heartbeat para o envio de broadcast. É através dessa interface que o heartbeat ficará “pingando” os outros nós do cluster. Normalmente esta interface é cross. Pode ser que o valor desse parâmetro mude de servidor para servidor dependendo do nome da interface que foi usada no cross.
node – nomes dos servidores presentes no cluster.
auto_failback off – Com o auto_failback on, quando ocorre uma queda no primeiro nó (master neste momento), o segundo nó assume como master. Quando o primeiro nó voltar da queda, o segundo nó passa o master para o nó 1 novamente. Com a opção off, o primeiro nó ao voltar da queda sobe como slave.

2. Arquivo /etc/ha.d/authkeys

Este arquivo deve ser idêntico para todos os servidores no cluster. Ele controla a autenticação do heartbeat. O dono do arquivo deve ser o root com a permissão 600. No exemplo abaixo, “qualquertexto” pode ser qualquer string da sua escolha, com tanto que esteja idêntica em todos servidores. Além do sha1, outros tipos de autenticação podem ser md5 e crc.

auth 1
1 sha1 qualquertexto

3. Arquivo /etc/ha.d/haresources

SERVER01 192.168.10.10 apache2

Este arquivo também deve ser idêntico em todos os servidores do cluster. O primeiro parâmetro é o hostname do nó que você considera como master primário. Ao subir o heartbeat na primeira vez, esse será o nó que assumirá como master.

O segundo parâmetro é o ip Virtual do cluster, ou o ip “compartilhado” que estará sempre ativo independente do nó que estiver como master. Esse é o ip que você passará para outros servidores/serviços que irão acessar o “cluster”.

O terceiro e consequentes parâmetros são os nomes dos serviços que o heartbeat irá controlar. No caso apache2, como mostra o exemplo abaixo, estará ligado somente no nó master. Nos outros nós estarão desligados. Neste caso, quem controla o start/stop do serviço não será mais o linux através do rc.d e sim o heartbeat. Portanto, todos os serviços configurados no heartbeat devem ser eliminados da inicialização do Linux (rc.d).

PS: O script start/stop do serviço continua no init.d, deve ser removido somente da inicialização (rc.d).
Exemplo:

# update-rc.d -f apache2 remove

Você pode adicinar quantos serviços forem necessários para o devido funcionamento do cluster. Uma exemplo de serviço, seria um script que fica sincronizando arquivos de configuração entre os nós do cluster através de rsync. Quando você muda a configuração em um nó ele automaticamente replica para o outro nó. Exemplo:

SERVER01 192.168.10.10 apache2 synconfig

No caso você deve criar um serviço chamado synconfig em /etc/init.d ! Ele irá chamar um daemon que fica sincronizando arquivos através de rsync. O serviço deve receber pelo menos os parâmetros start e stop.


via
segunda-feira, 5 de junho de 2017
Posted by Rafael Holanda
Posted by Rafael Holanda

Teste de vulnerabilidade - WannaCry MS17-010 | Utilizando Zenmap - Windows


Para realizar um teste de vulnerabilidade do Wanna Cry (MS17-010) utilizando o Zenmap, baixe esse arquivo e coloque na pasta de script do Zenmap

Comando para testar:

Teste em um determinado IP
nmap -sC -p 445 -d --max-hostgroup 3 --open --script smb-vuln-ms17-010.nse X.X.X.X/X

Teste maquina local
nmap -sC -p 445 -d --max-hostgroup 3 --open --script smb-vuln-ms17-010.nse localhost

Equipamento vulnerável:




Equipamento protegido: 







terça-feira, 23 de maio de 2017
Posted by Rafael Holanda

Nmap Network Scanning



Um dos primeiros passos em qualquer missão de reconhecimento de uma rede é reduzir um conjunto (às vezes enorme) de faixas de endereços IP, em uma lista de hosts ativos e interessantes. Escanear cada porta de cada endereço IP é vagaroso e normalmente desnecessário. É claro que o que torna um host interessante depende muito do propósito do scan. Administradores de rede podem estar apenas interessados em hosts que executam um determinado serviço, enquanto os auditores de segurança podem se importar com cada dispositivo que possuir um endereço IP. Um administrador pode se sentir à vontade em usar o ping ICMP para localizar os hosts na rede interna, enquanto um profissional externo de análise de vulnerabilidades (penetration tester) pode utilizar um conjunto diversificado de dezenas de sondagens em uma tentativa de burlar as restrições do firewall.

As necessidades para o descobrimento de host são muito diversas e, por isso, o Nmap oferece uma ampla variedade de opções para customizar as técnicas utilizadas. A descoberta de host às vezes é chamada de ping scan, mas ela vai muito além dos simples pacotes ICMP de echo request associados com a ferramenta onipresente conhecida como ping. Os usuários podem pular a etapa do ping inteiramente com uma lista de scan (-sL) ou desabilitanto o ping (-P0), ou enfrentar a rede com combinações arbitrárias de sondagens multi-portas TCP SYN/ACK, UDP e ICMP. O objetivo dessas sondagens é solicitar respostas que mostrem que um endereço IP está realmente ativo (é utilizado por um host ou dispositivo de rede). Em muitas redes, apenas uma pequena percentagem dos endereços IP está ativa em um dado momento. Isso é particularmente comum com o espaço de endereçamento privativo abençoado pela RFC1918 como, por exemplo, 10.0.0.0/8. Essa rede tem 16 milhões de IPs, mas eu já a vi sendo utilizado em empresas com menos de mil máquinas. A descoberta de hosts pode encontrar essas máquinas escassamente alocadas em um mar de endereços IP.

Se nenhuma opção de descoberta de hosts for dada, o Nmap envia um pacote TCP ACK destinado a porta 80 e uma procura ICMP Echo Request a cada máquina-alvo. Uma exceção a isso é que um scan ARP é utilizado para cada alvo localizado na rede ethernet local. Para usuários Unix sem privilégios, com shell, um pacote SYN é enviado ao invés do ack utilizando a chamada de sistema connect(). Esses valores padrão equivalem às opções -PA -PE. Esta descoberta de host freqüentemente é suficiente para escanear redes locais, mas um conjunto de sondagens mais abrangentes é recomendado para auditoria de segurança.

As opções -P* (que selecionam tipos de ping) podem ser combinadas. Você pode aumentar as chances de penetrar em um firewall rígido enviando muitos tipos de sondagens, utilizando diferentes portas/flags TCP e códigos ICMP. Note também que a descoberta por ARP (-PR) é feita por padrão contra alvos na rede ethernet local mesmo que você especifique outras opções -P* , porque é quase sempre mais rápida e eficiente.

Por definição, o Nmap faz a descoberta de host e então executa um escaneamento de portas contra cada host que ele determina que está ativo. Isto é verdade mesmo que você especifique tipos de busca não-padronizadas de hosts, tais como sondagens UDP (-PU). Leia sobre a opção -sP para saber como executar apenas uma descoberta de hosts, ou utilize -P0 para pular a descoberta de hosts e escanear as portas de todos os hosts-alvo. As seguintes opções controlam a descoberta de hosts:

-sL (Scan Listagem)
O scan listagem é uma forma degenerada de descoberta de hosts que simplesmente lista cada host da rede especificada, sem enviar nenhum pacote aos hosts-alvos. Por padrão o Nmap fará a resolução de DNS reverso dos hosts para descobrir seus nomes. Ainda é surpreendente a quantidade de informações úteis que simples nomes de hosts podem dar. Por exemplo, fw.chi.playboy.com é o firewall do escritório de Chicago da Playboy Enterprises. Nmap também reporta o número total de endereços IP ao final. O scan listagem é um bom teste de sanidade para assegurar que você está com a lista correta de endereços IP dos seus alvos. Se os hosts mostrarem nomes de domínios que você não reconhece, vale a pena investigar melhor para evitar scanear a rede da empresa errada.

Uma vez que a idéia é apenas mostrar uma lista dos hosts-alvos, as opções de funcionalidade de nível mais alto tais como scan de portas, detecção de SO, ou scan utilizando ping, não podem ser combinadas com esta opção. Se você deseja desabilitar o scan utilizando ping enquanto executa funções de nível elevado, leia a opção -P0.

-sP (Scan usando Ping)
Esta opção diz ao Nmap para somente executar um scan usando o ping (descoberta de hosts), e então mostrar os hosts disponíveis que responderam ao scan. Nenhum teste adicional (tais como escaneamento de portas e deteção de SO) é executado. Isto é um pouco mais intrusivo que o scan listagem, e pode ser usado para os mesmos propósitos. Permite um reconhecimento leve de uma rede-alvo sem chamar muita atenção. Saber quantos hosts estão ativos é mais valioso para invasores que a lista fornecida pelo scan listagem com cada endereço IP e seu nome de host.

Administradores de sistemas frequentemente acham esta opção valiosa. Ela pode ser facilmente utilizada para contar o número de máquinas disponíveis em uma rede ou monitorar a disponibilidade dos servidores. Isto é normalmente chamado de varredura com ping (ping sweep), e é mais confiável do que fazer um ping em um endereço de broadcast, pois muitos hosts não respondem a pesquisas com broadcast.

A opção -sP envia um ICMP echo request e um pacote TCP para a porta 80 por padrão. Quando executada por um usuário sem privilégios, um pacote SYN é enviado (usando uma chamada connect()) para a porta 80 no alvo. Quando um usuário privilegiado tenta escanear alvos na rede ethernet local, requisições ARP (-PR) são utilizadas, a menos que --send-ip tenha sido especificado. A opção -sP pode ser combinada com qualquer um dos tipos de sondagens de descobrimento (as opções -P* , excluindo -P0) para maior flexibilidade. Se qualquer uma dessas opções de tipos de sondagens e número de porta for utilizada, as sondagens padrão (ACK e echo request) são sobrepostas. Quando firewalls restritivos estão posicionados entre o host de origem que executa o Nmap e a rede-alvo, utilizar essas técnicas avançadas é recomendado. Do contrário, hosts podem ser perdidos quando o firewall ignorar as sondagens ou as respostas delas.

-P0 (Sem ping)
Esta opção pula completamente o estágio de descoberta do Nmap. Normalmente o Nmap utiliza este estágio para determinar as máquinas ativas para escaneamento mais agressivo. Por padrão, o Nmap apenas executa sondagens agressivas tais como escaneamento de portas, detecção de versões, ou detecções do SO contra hosts que foram verificados como ativos. Desabilitar a descoberta de hosts com -P0 faz com que o Nmap teste as funções de escaneamento solicitadas contra todos os endereços IP alvos especificados. Portanto se um espaço de endereçamento alvo do tamanho de uma classe B (/16) for especificado na linha de comando, todos os 65.536 endereços IP serão escaneados. O segundo caracter da opção -P0 é um zero e não a letra O. A descoberta de hosts apropriada é desconsiderada como no scan listagem, mas ao invés de parar e mostrar a lista de alvos, o Nmap continua a executar as funções solicitadas como se cada alvo IP estivesse ativo.

-PS [listadeportas] (Ping usando TCP SYN)
Esta opção envia um pacote TCP vazio com a flag SYN marcada. A porta de destino padrão é a 80 (configurada em tempo de compilação pela variável DEFAULT_TCP_PROBE_PORT no nmap.h), mas uma porta alternativa pode ser especificada como um parâmetro. Até uma lista de portas separadas por vírgula pode ser especificada (p.ex. -PS22,23,25,80,113,1050,35000), nesse caso as sondagens serão tentadas contra cada porta em paralelo.

A flag SYN sugere aos sistemas remotos que você está tentando estabelecer uma comunicação. Normalmente a porta de destino estará fechada e um pacote RST (reset) será enviado de volta. Se acontecer de a porta estar aberta, o alvo irá dar o segundo passo do cumprimento-de-três-vias (3-way-handshake) do TCP respondendo com um pacote TCP SYN/ACK TCP. A máquina executando o Nmap então derruba a conexão recém-nascida respondendo com um RST ao invés de enviar um pacote ACK que iria completar o cumprimento-de-três-vias e estabelecer uma conexão completa. O pacote RST é enviado pelo kernel da máquina que está executando o Nmap em resposta ao SYN/ACK inesperado, e não pelo próprio Nmap.

O Nmap não se importa se a porta está aberta ou fechada. Tanto a resposta RST ou SYN/ACK discutidas anteriormente dizem ao Nmap se o hosts está disponível e responsivo.

Em caixas UNIX, apenas o usuário privilegiado root é capaz, normalmente, de enviar e receber pacotes TCP em estado bruto. Para usuários não privilegiados um contorno é automaticamente empregado em concordância com a chamada de sistema connect() iniciada contra cada porta-alvo. Isso tem o efeito de enviar um pacote SYN ao host alvo, em uma tentativa de se estabelecer uma conexão. Se o connect() retornar com sucesso rápido ou com uma falha ECONNREFUSED, a pilha TCP subjacente deve ter recebido um SYN/ACK ou RST e o host é marcado como disponível. Se a tentativa de conexão for deixada largada até que um timeout ocorra, o host é marcado como indisponível. Esse contorno também é usado para conexões IPv6, pois o suporte a construção de pacotes IPv6 em estado bruto ainda não está disponível no Nmap.

-PA [listadeportas] (Ping usando TCP ACK)
O ping usando TCP ACK é muito similar ao recém-discutido ping usando SYN. A diferença, como você poderia imaginar, é que a flag TCP ACK é marcada ou invés da flag SYN. Tal pacote ACK finge reconhecer dados de uma conexão TCP estabelecida, quando nenhuma conexão existe de fato. Então os hosts remotos deveriam sempre responder com pacotes RST, revelando sua existência no processo.

A opção -PA utiliza a mesma porta padrão que a sondagem SYN (80) e pode também obter uma lista de portas destino no mesmo formato. Se um usuário privilegiado tenta isto, ou se um alvo IPv6 é especificado, o contorno connect() discutido anteriormente é utilizado. Esse contorno é imperfeito pois o connect() está realmente enviando um pacote SYN ao invés de um ACK.

O motivo para oferecer ambas as sondagens ping, que utilizam SYN e ACK, é maximizar as chances de passar por firewalls. Muitos administradores configuram roteadores e outros firwalls simples para bloquear pacotes SYN entrantes exceto aqueles destinados a serviços públicos como o site web da empresa ou servidor de correio eletrônico. Isso evita as demais conexões entrantes na organização, permitindo aos usuários fazer conexões desobstruidas à Internet. Essa aproximação não-orientada à conexão (non-stateful ou stateless) consome uns poucos recursos no firewall/roteador e é amplamente suportada por filtros de hardware e software. O firewall de software Netfilter/iptables do Linux oferece a conveniência da opção --syn para implementar essa abordagem stateless. Quando regras stateless do firewall tais como essas são implementadas, sondagens de ping usando SYN (-PS) muito provavelmente serão bloqueadas quando forem enviadas à portas fechadas. Em tais casos, a sondagem ACK se destaca pois ela simplesmente passa por essas regras.

Outro tipo comum de firewall utiliza regras orientadas a conexão que descartam pacotes inesperados. Esta característica era encontrada inicialmente apenas em firewalls de alto-nível, embora tenha se tornado mais comum com o passar dos anos. O sistema Netfilter/iptables do Linux suporta esta característica através da opção --state, que categoriza os pacotes baseados no estado da conexão. Uma sondagem SYN tem maiores chances de funcionar contra um sistema assim, pois pacotes ACK inesperados são normalmente reconhecidos como falsos e descartados. Uma solução para esse dilema é enviar ambas as sondagens SYN e ACK especificando -PS e -PA.

-PU [listadeportas] (Ping usando UDP)
Outra opção de descoberta de hosts é o ping usando UDP, que envia um pacote UDP vazio (a menos que --data-length seja especificado) para as portas informadas. O argumento "listadeportas" tem o mesmo formato que os discutidos anteriormente nas opções -PS e -PA. Se nenhuma porta for especificada, o padrão é 31338. Esse padrão pode ser configurado em tempo de compilação alterando DEFAULT_UDP_PROBE_PORT no nmap.h. Uma porta alta incomum é utilizada como padrão porque enviar para portas abertas normalmente é indesejado para este tipo particular de scan.

Ao bater contra uma porta fechada na máquina-alvo, a sondagem UDP deve causar um pacote ICMP de porta inalcançável como resposta. Isso diz ao Nmap que a máquina está ativa e disponível. Muitos outros tipos de erros ICMP, tais como host/rede inalcançável ou TTL excedido são indicativos de um host inativo ou inalcançável. A falta de resposta também é interpretada dessa forma. Se uma porta aberta é alcançada, a maioria dos serviços simplesmente ignoram o pacote vazio e falham em retornar qualquer resposta. É por isso que a porta de sondagem padrão é 31338, que pouco provavelmente estará em uso. Uns poucos serviços, tal como o chargen, irá responder a um pacote UDP vazio, e com isso revelará ao Nmap que a máquina está disponível.

A principal vantagem deste tipo de scan é que ele passa por firewalls e filtros que apenas examinam o TCP. Por exemplo, uma vez eu tive um roteador broadband sem-fio Linksys BEFW11S4. A interface externa desse dispositivo filtrava todas as portas TCP por padrão, mas as sondagens UDP ainda causavam mensagens de porta inalcançável, entregando assim o dispositivo.

-PE; -PP; -PM (Tipos de Ping do ICMP)
Além dos tipos incomuns de descoberta de hosts TCP e UDP discutidos anteriormente, o Nmap pode enviar os pacotes-padrão que normalmente são enviados pelo onipresente programa ping. O Nmap envia um pacote ICMP do tipo 8 (echo request) ao endereço IP alvo, esperando como resposta um tipo 0 (Echo Reply) do host disponível. Infelizmente para muitos exploradores de rede, muitos hosts e firewalls atualmente bloqueiam esses pacotes, ao invés de responder como é requerido pela RFC 1122. Por essa razão, scans puramente ICMP são raramente confiáveis o suficiente contra alvos desconhecidos na Internet. Mas para administradores de sistemas monitorando uma rede interna eles podem ser uma abordagem prática e eficiente. Utilize a opção -PE para ativar esse comportamento echo request.

Embora o echo request seja a pesquisa padrão de um ping ICMP, o Nmap não pára aqui. A padronização do ICMP (RFC 792) também especifica timestamp request, information request, e pacotes address mask request como códigos 13, 15, e 17, respectivamente. Apesar do propósito ostensivo dessas pesquisas seja obter informações tais como a máscara do endereço e hora corrente, eles podem ser facilmente utilizados para descoberta de hosts. Um sistema que responda está ativo e disponível. O Nmap não implementa atualmente os pacotes de requisição de informações, pois eles não são amplamente suportados. A RFC 1122 insiste que “um host NÃO DEVERIA implementar essas mensagens”. Pesquisas de marcação de hora (Timestamp) e máscara de endereço podem ser enviadas com as opções -PP e -PM , respectivamente. Uma resposta timestamp reply (código ICMP 14) ou uma resposta address mask reply (código 18) revela que o host está disponível. Essas duas pesquisas podem ser valiosas quando os administradores bloqueiam pacotes echo request especificamente e esquecem que outras pesquisas ICMP podem ser usadas com o mesmo propósito.

-PR (Ping usando ARP)
Um dos cenários de uso mais comuns do Nmap é escanear a LAN ethernet. Na maioria das LANs, especialmente aquelas que utilizam a faixa de endereçamento privativo abençoado pela RFC1918, a vasta maioria dos endereços IP não são utilizados nunca. Quando o Nmap tenta enviar um pacote IP em estado bruto, tal como um ICMP echo request, o sistema operacional deve determinar o endereço físico de destino (ARP) correspondente ao IP-alvo de forma que ele possa endereçar adequadamente o frame ethernet. Isso normalmente é lento e problemático, pois os sistemas operacionais não foram escritos com a expectativa de que precisariam fazer milhões de requisições ARP contra hosts indisponíveis em um curto período de tempo.

O scan ARP encarrega o Nmap e seus algoritmos otimizados de fazer as requisições ARP. E se ele conseguir uma resposta de volta, o Nmap não precisa nem se preocupar com os pacotes ping baseados em IP, uma vez que ele já sabe que o host está ativo. Isso torna o scan ARP muito mais rápido e mais confiável que os scans baseados em IP. Portanto isso é feito por padrão quando se escaneia hosts ethernet que o Nmap detecta estarem posicionados em uma rede ethernet local. Mesmo se tipos diferentes de ping (tais como -PI ou -PS) seja especificados, o Nmap usa o ARP no lugar para cada um dos alvos que estiverem na mesma LAN. Se você não quiser de forma nenhuma fazer um scan ARP, especifique --send-ip.

-n (Não faça resolução DNS)
Diz ao Nmap para nunca fazer uma resolução DNS reversa nos endereços IP ativos que ele encontrar. Uma vez que o DNS é normalmente lento, isso acelera as coisas.

-R (resolução DNS para todos os alvos)
Diz ao Nmap para sempre fazer uma resolução DNS reversa nos endereços IP-alvos. Normalmente isto apenas é executado quando uma máquina está ativa.

--system-dns (Usa a resolução DNS do sistema)
Por padrão, o Nmap resolve o endereço IP através do envio de pesquisas (queries) diretamente aos servidores de nome configurados em seu host, e então escuta as respostas. Muitas das pesquisas (dezenas) são executadas em paralalo para um melhor desempenho. Especifique esta opção se desejar utilizar a resolução DNS do seu sistema (um endereço IP por vez, através da chamada getnameinfo()). Isto é mais lente e raramente útil, a não ser que haja um bug no código de DNS do Nmap -- por favor, entre em contato conosco se for o caso. A resolução DNS do sistema é sempre usada em escaneamento IPv6.

--dns-servers <servidor1[,servidor2],...> (Servidores a utilizar para a pesquisa DNS reversa)
Por padrão o Nmap irá tentar determinar os seus servidores DNS (para a resolução DNS reversa) através do arquivo resolv.conf (UNIX) ou do registry (Win32). Opcionalmente você pode usar esta opção para especificar servidores alternativos. Esta opção não é honrada se você estiver usando --system-dns ou um escaneamento IPv6. Utilizar múltiplos servidores DNS é, normalmente, mais rápido e mais furtivo do que pesquisar apenas em um servidor. O melhor desempenho é frequentemente obtido especificando-se todos os servidores que tem autoridade sobre a faixa de endereços IP.
sexta-feira, 27 de janeiro de 2017
Posted by Rafael Holanda

Sincronização de Horário NTP externo - Windows


O horário em uma rede de computadores Windows é mantido pelo PDC do domínio, quando o mesmo não é sincronizado com um NTP externo é utilizado o horário do computador local (BIOS).
Efetuando a sincronização com um NTP externo no Windows 2008 R2.
Acessar o PDC é parar o serviço "Windows Time":
C:\>net stop w32time

Configurando com o NTP externo a.ntp.br, b.ntp.br, c.ntp.br:
C:\>w32tm /config /manualpeerlist:a.ntp.br,b.ntp.br,c.ntp.br,0x8, /syncfromflags:manual

Iniciando o serviço:
C:\>net start w32time
---
Comandos Interessantes:

Verificando a configuração:
C:\>w32tm /query /configuration
Informar o horário da última sincronização.
C:\>w32tm /query /status
Define que o computador é uma fonte confiável de horário.
C:\>w32tm /config /reliable:yes

Cancelar o registro do serviço.
C:\>w32tm /unregister
Registra o serviço.
C:\>w32tm /register

As configurações do W32Time ficam armanezadas na chave de registro abaixo:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters


sexta-feira, 20 de janeiro de 2017
Posted by Rafael Holanda

Configuração do servidor SSH



Você pode configurar várias opções relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo "/etc/ssh/sshd_config". Assim como no caso da configuração do cliente, a maior parte das opções dentro do arquivo podem ser omitidas (pois o servidor simplesmente utiliza valores default para as opções que não constarem no arquivo), mas, de qualquer forma, é saudável especificar todas as opções que conhece: além de evitar enganos, é uma forma de praticar e memorizar as opções.

Porta: Uma das primeiras linhas é a:

Port 22

Esta é a porta que será usada pelo servidor SSH. O padrão é usar a porta 22. Ao mudar a porta do servidor aqui, você deverá usar a opção "-p" ao conectar a partir dos clientes para indicar a porta usada, como em:

# ssh -p 2222 morimoto@gdhn.com.br

Outra opção é editar o arquivo "/etc/ssh/ssh_config" (nos clientes) e alterar a porta padrão usada por eles. Mudar a porta padrão do SSH é uma boa idéia se você está preocupado com a segurança. Muitos dos ataques "casuais" (quando o atacante simplesmente varre faixas inteiras de endereços, sem um alvo definido), começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, procurando por servidores com portas conhecidas abertas, como a 21, a 22 e a 80. Isso torna o teste mais rápido, permitindo localizar rapidamente um grande volume de hosts com portas abertas. A partir daí, os ataques vão sendo refinados e direcionados apenas para os servidores vulneráveis encontrados na primeira varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvável como a porta 32456 ou a 54232 reduz sua exposição.

Controle de acesso: Logo abaixo vem a opção "ListenAddress", que permite limitar o SSH a uma única interface de rede (mesmo sem usar firewall), útil em casos de micros com duas ou mais placas; o típico caso em que você quer que o SSH fique acessível apenas na rede local, mas não na Internet, por exemplo. Digamos que o servidor use o endereço "192.168.0.1" na rede local e você queira que o servidor SSH não fique disponível na Internet. Você adicionaria a linha:

ListenAddress 192.168.0.1

Note que especificamos nesta opção o próprio IP do servidor na interface escolhida, não a faixa de IP's da rede local ou os endereços que terão acesso a ele.

Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira versão do protocolo. Por padrão, o servidor SSH aceita conexões de clientes que utilizam qualquer um dos dois protocolos, o que é indicado na linha:

Protocol 2,1

O protocolo SSH 1 tem alguns problemas fundamentais de segurança, por isso é recomendável desativar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas:

Protocol 2

Restringir a versão do protocolo ajuda a melhorar a segurança, pois evita que usuários utilizando clientes SSH antigos abram brechas para ataques. Existem, por exemplo, muitos clientes SSH para uso em celulares que suportam apenas o SSH 1 e utilizam algoritmos fracos de encriptação. Desativando a compatibilidade com o SSH 1 você corta o mal pela raiz.

Usuários e senhas: Outra opção interessante, geralmente colocada logo abaixo, é a:

PermitRootLogin yes

Esta opção determina se o servidor aceitará que usuários se loguem como root. Do ponto de vista da segurança, é melhor deixar esta opção como "no", pois assim o usuário precisará primeiro se logar usando um login normal e rodar comandos como root usando o "sudo" ou "su -":

PermitRootLogin no

Dessa forma, é preciso saber duas senhas, ao invés de saber apenas a senha do root, eliminando a possibilidade de algum atacante obstinado conseguir adivinhar a senha de root e, assim, obter acesso ao servidor.

Por padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas você pode refinar isso através da opção "AllowUsers", que especifica uma lista de usuários que podem usar o SSH. Quem não estiver na lista, continua usando o sistema localmente, mas não consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usuários que não têm necessidade de acessar o servidor remotamente coloquem a segurança do sistema em risco. Para permitir que apenas os usuários "joao" e "maria" possam usar o SSH, por exemplo, adicione a linha:

AllowUsers joao maria

Você pode ainda inverter a lógica, usando a opção "DenyUsers". Neste caso, todos os usuários cadastrados no sistema podem fazer login, com exceção dos especificados na linha, como em:

DenyUsers ricardo manuel

Outra opção relacionada à segurança é a:

PermitEmptyPasswords no

Esta opção faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que alguém consiga se conectar ao servidor "por acaso" ao descobrir a conta desprotegida. Lembre-se de que a senha é justamente o ponto fraco do SSH. De nada adianta usar 2048 bits de encriptação se o usuário escreve a senha em um post-it colado no monitor, ou deixa a senha em branco.

Banner: Alguns servidores exibem mensagens de advertência antes do prompt de login, avisando que todas as tentativas de acesso estão sendo monitoradas ou coisas do gênero. A mensagem é especificada através da opção "Banner", onde você indica um arquivo de texto com o conteúdo a ser mostrado, como em:

Banner = /etc/ssh/banner.txt

X11 Forwarding: Além de ser usada na configuração dos clientes, a opção "X11Forwarding" pode ser também incluída na configuração do servidor:

X11Forwarding yes

Ela determina se o servidor permitirá que os clientes executem aplicativos gráficos remotamente. Se o servidor for acessado via Internet ou se possui um link lento, você pode deixar esta opção como "no" para economizar banda. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto. Note que ao usar "X11Forwarding no" o encaminhamento é recusado pelo próprio servidor, de forma que o usuário não consegue rodar aplicativos gráficos mesmo que a opção esteja ativa na configuração do cliente.


- SFTP: O SSH inclui um módulo de transferência de arquivos (o SFTP), que veremos em detalhes a seguir. Ele é ativado através da linha:

Subsystem sftp /usr/lib/sftp-server

É realmente necessário que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se você realmente deseja desativá-lo.


Via: hardware.com.br
sexta-feira, 13 de janeiro de 2017
Posted by Rafael Holanda

Como alterar o device name do CentOS7 para eth0



Alterar o arquivo /etc/default/grub, incluindo os parâmetros no kernel para que seja habilitada a opção de renomear a placa de rede para eth0:

net.ifnames=0 biosdevname=0

Edite com o Vi o arquivo de configuração do GRUB (/etc/default/grub) e procure pela linha "GRUB_CMDLINE_LINUX", adicione depois da opção "quiet" os seguintes parâmetros:

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap crashkernel=auto  rd.lvm.lv=centos/root vconsole.font=latarcyrheb-sun16 vconsole.keymap=br-abnt2 rhgb quiet net.ifnames=0 biosdevname=0"

Depois execute o comando abaixo para que seja efetivada a alteração no GRUB:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file
Found linux image: /boot/vmlinuz-3.10.0-121.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-121.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-df30d92ad3eb414583d85bb471003eb4
Found initrd image: /boot/initramfs-0-rescue-df30d92ad3eb414583d85bb471003eb4.img done

Alterar o nome do adaptador de rede:

# mv /etc/sysconfig/network-scripts/ifcfg-enp0s3 /etc/sysconfig/network-scripts/ifcfg-eth0

Confira se o parâmetro "NAME" no arquivo eth0 está como ETH0, se não estiver, altere-o:

NAME=ETH0

Reinicie a máquina para efetivar a alteração do device name para eth0:

# shutdown -r now

Depois de reiniciar, confira com o ifconfig se o nome foi alterado corretamente:

# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.100  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::a00:27ff:feb5:cdb5  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:b5:cd:b5  txqueuelen 1000  (Ethernet)
        RX packets 3363  bytes 268445 (262.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 155  bytes 19560 (19.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Via: VoL
sexta-feira, 6 de janeiro de 2017
Posted by Rafael Holanda

BAD_SYSTEM_CONFIG




1.  Reinicie o computador e pressione repetidamente a tecla F8 durante a inicialização.

Nota: se não for possível, tente desligar e ligar o computador algumas vezes seguidas até aparecer o inicializador de reparação.

2. Entre no Prompt de Comando (cmd).
Nos Windows Vista e 7, selecione Prompt de Comando.
Nos Windows 8, 8.1 e 10, selecione Solução de Problemas > Opções Avançadas > Prompt de Comando.

3.  No Prompt de Comando, digite: 
bcdedit /deletevalue {default} numproc
Aperte <Enter>.
bcdedit /deletevalue {default} truncatememory  
Aperte <Enter>.
Nota: cuidado com erros de digitação, incluindo os espaços entre as palavras.

4.  Feche o Prompt de Comando.

5.  Reinicie.
Desligue o computador. Em seguida, ligue-o novamente.
quarta-feira, 9 de novembro de 2016
Posted by Rafael Holanda

Desativar animação First Sign-in do Windows 10 via Diretiva de Grupo

  1. Navegue para  Configuração do computador>  Modelos administrativos> Sistema
     
  2. Selecione Logon
     

     
  3. Clique duas vezes em Mostrar primeiro login animação
     
  4. No Mostrar primeiro sinal-na janela de animação , selecione Desativado e clique em OK
     

     
  5. Feche o  Editor de Políticas de Grupo Local
quinta-feira, 20 de outubro de 2016
Posted by Rafael Holanda

Instalando programas .exe no domínio por script .bat

Via: https://www.profissionaisti.com.br/2016/10/instalando-programas-exe-no-dominio-por-script-windows-server/

Para solucionar este problema iremos trabalhar com as seguintes etapas:

  1. Iremos descobrir o formato de instalação via comando do software
  2. Após descobrir o formato, iremos instalar em uma estação
  3. Após instalar em uma estação, iremos copiar o software para uma estação/servidor e montaremos o script.
  4. Após montado o script, iremos copiar para a pasta sysvol do servidor
  5. Depois de ter copiado para a pasta sysvol do servidor, iremos vincular a algum usuário específico com permissões elevadas(de instalação).
  6. Logar na estação com o usuário específico.

1 – Iremos descobrir o formato de instalação via comando do software.

Essa descoberta pode ser feita com o comando “/?”. Para isso iremos trabalhar com o software MGLTools,no qual está no formato .exe.
Caso deseje baixá-lo para testar junto com o artigo, clique aqui!
Abriremos o prompt de comando para verificar a instalação silenciosa. Com o prompt de comando aberto digite o nome do software como está salvo na estação + /?, conforme imagem abaixo.
Após ter digitado irá aparecer uma janela com as informações do software, como a figura abaixo.
Notamos acima que a instalação silenciosa do software se da pelo /s (run the installer in silent mode) e usando o comando /y (accept all defaults and run the installer). Ou seja, através do comando /s iremos instalar o software e o /y será para aceitarmos os termos.
Caso ainda tem dúvidas de como descobrir a instalação silenciosa de programa, segue este link para saber mais: eduardosena.blog.br/como-descobrir-comando-para-instalacao-silenciosa-de-programas/

2 – Após descobrir o formato, iremos instalar em uma estação

Com os comandos descobertos, digitaremos no prompt de comando:
Note que depois de digitado o comando o software irá instalar sem interação com o usuário.
Após ter instalado, aparecerá somente uma tela para clicar em Finish. Notamos que aqui está tudo ocorrendo como queremos, ou seja, o programa instalando via linha de comando sem a necessidade de clicar em next/next/next…
Clicando em Finish, veja que o programa foi instalado:
Para confirmar iremos em programas instalados.
Veja acima que o software foi instalado. Agora iremos desinstalar o programa da estação, já que iremos instalá-lo via script. Não esqueça de desinstalar o programa!
Agora iremos para a 3º etapa somente após ter desinstalado o programa (caso for fazer o teste do script na mesma estação).

3 – Após instalar em uma estação, iremos copiar o software para uma estação/servidor e montaremos o script

Para que copiar para o servidor o software? A ideia é que o script que montaremos faça uma cópia desse software para a estação cliente e da própria estação ele execute o software e instale.
No meu caso irei copiar o software para o meu servidor. Com isso irei fazer uma pasta no disco local C:\ chamada softwares. A ideia é que quando executarmos os script ele copie o software para o disco local C:\ da estação cliente. Então vamos lá:
Criamos uma pasta chamada softwares no diretório C:\ do servidor. A pasta em criamos, ou que irá fazer nos seus testes, tem que estar compartilhada para o(s) usuário(s) que serão vinculados ao script e com as permissões necessárias. Veja a pasta criada abaixo:
Dentro dela está uma cópia do software MGLTools.
Agora iremos na estação cliente e tentaremos acessar o diretório onde está a cópia do software. O por que disso? Justamente para verificarmos se o(s) usuário(s) estão conseguindo “enxergar” o arquivo e já podemos aqui verificar se as permissões estão OK.
Da estação cliente, logado com o usuário (diego.gouveia) em que iremos vincular o script, tentaremos acessar o compartilhamento: \\diego-dc\c$\Softwares. Caso você deseja acessar o compartilhamento criado, digite \\nomedaestação\
Veja acima que consegui acessar a pasta criada no servidor pelo \\ e consigo visualizar o arquivo. Aqui já sei que, quando começar a montar o script, já não irão acontecer erros em relação a acesso/permissões. Uma dica que dou é copiar o arquivo para alguma pasta e verificar se o usuário consegue copiar. Sabendo que as permissões estão Ok, iremos começar a montar o script:
Abra o bloco de notas na estação cliente e com o usuário que será vinculado o script digite:
cd\
md Softwares
copy "\\endereçodecompartilhamentodapasta\*.*",  "c:\Softwares"
cd Softwares
start nomedoexecutavel /comandodeinstalaçãoviaprompt
No meu exemplo ficou:
O comando cd\ é para que o usuário logado consiga com script voltar para o diretório C:\ da estação para criar uma pasta chamada Softwares (md Softwares). Após criada a pasta Softwares dentro do diretório c:\ da estação cliente, ele irá copiar TUDO (*.*) que está dentro da pasta Softwares do endereço “\\diego-dc\c$\Softwares\*.*”,  e jogar na pasta Softwares da estação cliente. Depois, ele irá entrar no diretório Softwares (cd Softwares) da estação cliente e executa o comando instalação do programa: start…
Com o script montado, iremos salvá-lo na área de trabalho do usuário no formato.bat e executarei para verificar se o mesmo executa.
Veja acima que salvei com o nome ScriptSoftware.bat na área de trabalho do usuário. Agora iremos executá-lo e verificaremos se o mesmo consegue fazer tudo que foi prometido:
Executando o script:
Veja que o programa foi instalado via Script. 
PRONTO. Aqui já sei que meu script está funcionando e sei que ele está fazendo tudo como eu quero. Agora iremos deletar a pasta criada (Softwares) no disco local C:\ e mais uma vez desinstalar o programa. Porque novamente? Por que na primeira que instalamos e desinstalamos foi quando estávamos montando o script (descobrindo a instalação via linha de comando) e agora instalamos pelo script feito. Então, vou deletar a pasta criada e desinstalar o programa por que vamos para o teste oficial (com o usuário logando)

4 – Após montado o script, iremos copiar para a pasta sysvol do servidor

A pasta sysvol é responsável pelo armazenamento de scripts usados por GPOs. Dentro da pasta há outra chamada scripts e é nesta que colocaremos nosso script feito na estação cliente. Então copie o script feito na estação de teste e cole dentro da pasta Windows\SYSVOL\sysvol\nomedoseudominio\scripts. Veja abaixo como ficou:
Com o script copiado iremos para o próximo passo:

5 – Depois de ter copiado para a pasta sysvol do servidor, iremos vincular a algum usuário específico com permissões elevadas (de instalação)

Irei abrir meu ADDS e irei nas propriedades do usuário que será vinculado (o mesmo que usei de teste, Diego Gouveia). Nas propriedades do user, irei na aba Perfil e em script de logon digitarei conforme o NOME que está nomeado o script + .bat no final. Veja abaixo:
Agora irei verificar as permissões do usuário:
Note que o mesmo está no grupo Admins do domínio. Ou seja, assim que logar na estação ele terá permissão necessária de instalação. Próximo passo:

6. Logar na estação com o usuário específico.

Agora iremos logar com o Diego Gouveia e verificaremos que irá copiar o executável para o diretório c:\softwares e irá instalar o programa MGTools sem a interação, isto é, de forma automática.
Logando:
PROGRAMA INSTALADO COM SUCESSO! Pronto galera, depois disso podemos agora retirar tudo que foi feito para da próxima vez que o usuário logar não ficar instalando as coisas:
Excluindo o ScriptSoftware.bat
E lembre-se de ir depois na aba perfil e apagar o nome dado em script de logon.
Bom galera, eu quis demonstrar como fazer a instalação de programas .exe em seu domínio. Muitos aqui podem falar: “mas o usuário tem que ter permissões, mas blá, blá…”
Imagina você ter que instalar um software indo em next/next/, copiando do servidor tudo de forma manual e em muitas estações? Chato demais. Essa é uma boa técnica e também podemos melhorar o script, colocando para a instalação de outros programas depois do primeiro e tudo de forma automática. Eu desenvolvi isso depois de ter que instalar um software em 50 estações. Terminei tudo dentro de 10 minutos. Façam proveito e melhorem, caso haja necessidade
Este artigo também pode ser visto no site: www.diegogouveia.com.br
quarta-feira, 19 de outubro de 2016
Posted by Rafael Holanda

Popular Post

Rafael Holanda. Tecnologia do Blogger.

Seguidores

Pesquisar este blog

Publicidade

- Copyright © Casa do Holanda -Casa do Holanda- Powered by Blogger - Designed by Rafael Holanda -

Google+