Instale o MySQL no CentOS 7




Com o lançamento do CentOS 7 MySQL, o sistema de gerenciamento de banco de dados relacional de código aberto mais popular do mundo não está mais disponível nos repositórios do CentOS e o MariaDB se tornou o sistema de banco de dados padrão. O MariaDB é um substituto drop-in binário compatível com versões anteriores do MySQL.

Neste tutorial, mostraremos como instalar o MySQL em uma máquina CentOS 7.

Pré-requisitos
Antes de iniciar este tutorial, verifique se você está conectado ao servidor com uma conta de usuário com privilégios sudo ou com o usuário root. É uma prática recomendada executar comandos administrativos como usuário do sudo, em vez de root, se você não tiver um usuário do sudo no sistema, poderá criar um seguindo estas instruções .
Como mencionamos na introdução, o MySQL não está disponível nos repositórios padrão do CentOS 7, portanto instalaremos os pacotes do MySQL Yum Repository, abaixo, mostraremos como instalar o MySQL 8.0 e o MySQL 5.7.

Você deve instalar apenas uma versão do MySQL no seu servidor CentOS 7. Se você não tiver certeza de qual versão instalar, consulte a documentação dos aplicativos que você implantará em seu servidor.

Instale o MySQL 8.0 no CentOS 7
Nesse momento, a versão mais recente do MySQL é a versão 8.0. Para instalá-lo no servidor CentOS 7, siga as etapas abaixo:

Ative o repositório do MySQL 8.0 com o seguinte comando:

sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm

Instale o pacote MySQL 8.0 com o yum:

sudo yum install mysql-community-server

Durante a instalação, o yum pode solicitar que você importe a chave GPQL do MySQL. Digite Y clique Enter.

Instale o MySQL 5.7 no CentOS 7
Para instalar a versão estável anterior do MySQL, MySQL versão 5.7 em um servidor CentOS 7, siga as etapas abaixo:

Habilite o repositório MySQL 5.7 com o seguinte comando:

sudo yum localinstall https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm

Instale o pacote MySQL 5.7 com:

Instale o MySQL como qualquer outro pacote usando o yum:

sudo yum install mysql-community-server

As seções abaixo são relevantes para o MySQL 8.0 e o MySQL 5.7.

Iniciando o MySQL
Quando a instalação estiver concluída, inicie o serviço MySQL e ative-o automaticamente na inicialização com:

sudo systemctl enable mysqld
sudo systemctl start mysqld

Podemos verificar o status do serviço MySQL digitando:

sudo systemctl status mysqld

● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-05-23 11:02:43 UTC; 14min ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 4293 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 4310 (mysqld)
   Status: "SERVER_OPERATING"
   CGroup: /system.slice/mysqld.service
           └─4310 /usr/sbin/mysqld

Protegendo o MySQL

Quando o servidor MySQL é iniciado pela primeira vez, uma senha temporária é gerada para o usuário root do MySQL. Você pode encontrar a senha executando o seguinte comando:

sudo grep 'temporary password' /var/log/mysqld.log

A saída deve ser algo como isto:

2018-05-23T10:59:51.251159Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: ppdlvfsL

Anote a senha, porque o próximo comando solicitará que você digite a senha raiz temporária.
Execute o mysql_secure_installation comando para melhorar a segurança da nossa instalação do MySQL:

sudo mysql_secure_installation

Saída:

Securing the MySQL server deployment.

Enter password for user root:

Após inserir a senha temporária, você será solicitado a definir uma nova senha para a raiz do usuário. A senha precisa ter pelo menos 8 caracteres e conter pelo menos uma letra maiúscula, uma letra minúscula, um número e um caractere especial.

The existing password for the user account root has expired. Please set a new password.

New password:

Re-enter new password:

O script também solicitará que você remova o usuário anônimo, restrinja o acesso do usuário root à máquina local e remova o banco de dados de teste. Você deve responder "Y" (sim) a todas as perguntas.

Conectando ao MySQL a partir da linha de comando

Para interagir com o MySQL através do terminal, usaremos o cliente MySQL, que é instalado como uma dependência do pacote do servidor MySQL.
Para efetuar login no servidor MySQL como o usuário root, digite:

mysql -u root -p

Você será solicitado a inserir a senha raiz que você definiu anteriormente quando o mysql_secure_installation script foi executado.

Depois de digitar a senha, você verá o shell do mysql como mostrado abaixo:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 11
Server version: 8.0.11 MySQL Community Server - GPL

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Criar um banco de dados

Depois de conectar-se ao shell do MySQL, você pode criar um novo banco de dados digitando o seguinte comando:

CREATE DATABASE new_database;

Query OK, 1 row affected (0.00 sec)

Criar tabelas

Agora que criamos um banco de dados, podemos criar uma tabela para armazenar alguns dados.
Antes de executar as instruções SQL para criar uma tabela, precisamos nos conectar ao banco de dados:

use new_database;

Neste exemplo, criaremos uma tabela simples denominada contacts com três campos id, name e email:

CREATE TABLE contacts (
  id INT PRIMARY KEY,
  name VARCHAR(30),
  email VARCHAR(30)
);

Query OK, 1 row affected (0.00 sec)


segunda-feira, 2 de setembro de 2019
Posted by Rafael Holanda

Instalando Unifi Controller no CentOS 7

Instalando Unifi Controller no CentOS 7



Atualizando o Ambiente & Sistema Operacional:
yum -y update

Desativando SELinux:
vim /etc/selinux/config

Altere a linha 7 de “enforcing” para “disabled”.

SELINUX=disabled

Agora vamos desativar o Firewalld:
systemctl stop firewalld
systemctl disable firewalld

Após isso, vamos reiniciar o servidor.
init 6

Depois do reboot instale o repositório EPEL no Linux CentOS 7.
yum -y install epel-release

Vamos criar um usuário para gerenciar o diretório do Ubiquiti dentro do sistema Linux.
useradd -r ubnt

Instalando o MongoDB Server e Java para implementação do controller.
yum -y install mongodb-server java-1.8.0-openjdk

Vamos precisar instalar o UnZip e o Waget também:
yum -y install unzip wget

O próximo passo é baixar os arquivos de configuração e instalação do Contoller.
cd /tmp
wget http://dl.ubnt.com/unifi/5.6.39/UniFi.unix.zip
unzip -q UniFi.unix.zip -d /opt
chown -R ubnt:ubnt /opt/UniFi

Criando o serviço que será gerenciado e executado pelo systemd:
vim /etc/systemd/system/unifi.service

# Systemd unit file for UniFi Controller
 [Unit]
 Description=UniFi AP Web Controller
 After=syslog.target network.target
 #
 [Service]
 Type=simple
 User=ubnt
 WorkingDirectory=/opt/UniFi
 ExecStart=/usr/bin/java -Xmx1024M -jar /opt/UniFi/lib/ace.jar start
 ExecStop=/usr/bin/java -jar /opt/UniFi/lib/ace.jar stop
 SuccessExitStatus=143
 #
 [Install]
 WantedBy=multi-user.target

Após isso, salve o arquivo e vamos habilitar o serviço para inicializar junto ao sistema operacional, e também iremos iniciar o serviço:
systemctl enable unifi.service
systemctl start unifi.service

Feito, isso reinicie o server.
init 6

Depois do reboot acesse em seu navegador o https://enderecoip:8443 

terça-feira, 27 de agosto de 2019
Posted by Rafael Holanda

Instalação do Zabbix 3.0



Download do pacote Zabbix 3.0:
wget http://repo.zabbix.com/zabbix/3.0/debian/pool/main/z/zabbix-release/zabbix-release_3.0-1+jessie_all.deb
dpkg -i zabbix-release_3.0-1+jessie_all.deb
apt-get update

Instalação Zabbix Server + Frontend + Agente (Recomendo para monitorar o próprio Server Zabbix)
apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent

Confguração da senha Root do MYSQL
Vamos agora continuar a instalação via interface Web.
Acesse seu ip/zabbix. Se não apareceu a interface do Zabbix 3.0, digite /etc/init.d/apache restart no console para reiniciar o apache.

Depois, deve aparecer o seguinte:
Clique em Next Step. Agora veremos uma tela com as configurações do PHP – pré requisito para o funcionamento do Zabbix.

Vamos alterar o timezone, no caminho: /etc/zabbix/apache.conf na linha # php_value date.timezone Europe/Riga

Altere conforme sua localidade e reinicie o apache: /etc/init.d/apache restart

Vamos agora para as configurações de banco de dados, mas, antes disso, vamos fazer as devidas configurações, se não teremos erros!
Como boa prática, use o usuário Zabbix para conexão e NÃO o ROOT.
Criando usuário Zabbix e especificando senha:

CREATE USER ‘zabbix’@’localhost’ IDENTIFIED BY ‘1234@mudar';

Validando que o usuario foi criado:
SELECT User,Host FROM mysql.user;

Criando database:
create database zabbix character set utf8 collate utf8_bin;

Permissão para usuário e base zabbix:
grant all privileges on zabbix.* to zabbix identified by ‘1234@mudar’

Download do source para pegarmos o banco
cd /tmp

wget <a href="http://ufpr.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/3.0.0/zabbix-3.0.0.tar.gz">http://ufpr.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/3.0.0/zabbix-3.0.0.tar.gz</a>

Extrair
tar -xzvf zabbix-3.0.0.tar.gz

Acessar o diretorio /tmp/zabbix-3.0.0/database/mysql

Importando…
mysql -uzabbix -p zabbix &lt; schema.sql
mysql -uzabbix -p zabbix &lt; images.sql
mysql -uzabbix -p zabbix &lt; data.sql

Depois de realizado os procedimentos acima, pode dar next na conexão com o banco. Se tudo foi realizado corretamente, vai continuar para os próximos procedimentos, que são o resumo de informações e nome/porta do seu Zabbix Server, no qual é opcional e como estamos fazendo Zabbix e um único servidor, não vamos mexer.

Agora, vamos finalizar com as configurações de banco de dados no arquivo /etc/zabbix/zabbix_server.conf
Alterando dbuser e dbpassword, conforme criamos nos procedimentos anteriores.

Feito isso, aplique o comando /etc/init.d/zabbix-server restart.

Vamos logar na interface ip/zabbix:

Usuário: Admin
Senha: zabbix
terça-feira, 5 de dezembro de 2017
Posted by Rafael Holanda

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

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+