Maximize a segurança em GNU / Linux

Olá amigos de DesdeLinux, o que foi prometido é uma dívida e aqui está um post sobre como maximizar a proteção dos sistemas Linux e ficar assim seguro de intrusos além de proteger as informações em seus servidores, PCs ou laptops !!!!

começando

Falha2ban: é um aplicativo escrito em Python para evitar a intrusão em um sistema, que age penalizando ou bloqueando conexões remotas que tentam acesso de força bruta.

instalação:

Fedora, RHEL, CentOS:

yum install fail2ban

Debian, Ubuntu:

apt-get install fail2ban

ambiente:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local nano /etc/fail2ban/jail.local

Na parte chamada [DEFAULT], descomentamos e modificamos #bantime = 3600 deixando assim:

#bantime = 3600 bantime = 604800

Na parte [sshd], apresentamos enabled = true deixando assim:

#enabled = true enabled = true

Salvamos com CTRL + O e fechamos com CTRL + X

Começamos o serviço:

Fedora, RHEL, CentOS:

systemctl enable fail2ban.service systemctl start fail2ban.service

Debian, Ubuntu:

serviço fail2ban start

Negar acesso root usando ssh:

Para proteger nossa máquina, vamos negar o ssh por meio do usuário root. Para fazer isso, editamos o arquivo / etc / ssh / sshd_config da seguinte maneira:

cp sshd_config sshd_config.bck nano / etc / ssh / sshd_config

Nós descomentamos e mudamos

#Protocol 2 Protocolo 2

Nós descomentamos e mudamos

#PermitRootLogin sim PermitRootLogin não

Salvamos com CTRL + O e fechamos com CTRL + X

Começamos o serviço:

Fedora, RHEL, CentOS:

systemctl enable sshd.service systemctl start sshd.service

Debian, Ubuntu:

serviço sshd start

Negar acesso a um servidor ssh usando senha e permitir ssh apenas com chaves RSA

Se quisermos conectar do PC1 ao Server1, a primeira coisa que devemos fazer é gerar nossa chave no PC1. Com nosso usuário e sem root no PC1, executamos:

ssh-keygen -t rsa -b 8192 (isso gera uma chave mais do que segura, já que chaves de 1024 a 2048 são normalmente usadas)

Assim que tivermos nossa senha, faremos o upload para o Server1:

ssh-copy-id user @ server_ip

Depois de fazer isso, vamos conectar ao nosso Server1 e modificar o arquivo nano / etc / ssh / sshd_config com permissões de root:

usuário ssh @ Server1 nano / etc / ssh / sshd_config

Mudamos a linha que diz #PasswordAuthentication yes para isto:

#PasswordAuthentication sim
PasswordAuthentication não

Salvamos com CTRL + O e fechamos com CTRL + X

Reiniciamos o serviço ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

reiniciar serviço sshd

Mudar a porta de escuta ssh

Novamente editamos / etc / ssh / sshd_config e na parte referente à porta deixamos assim:

# Porta 22 Porta 2000 (ou qualquer outro número maior que 2000. Em nossos exemplos, usaremos isso.)

Salvamos com CTRL + O e fechamos com CTRL + X

Reiniciamos o serviço ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

reiniciar serviço sshd

Se eles usarem fail2ban, é necessário alterar a configuração referente ao sshd ajustando a porta.

nano /etc/fail2ban/jail.local

[sshd]
port    = ssh, 2000

[sshd-ddos]
port    = ssh, 2000

[dropbear]
port    = ssh, 2000

[selinux-ssh]
port    = ssh, 2000

Salvamos com CTRL + O e fechamos com CTRL + X

Renovamos o serviço:

Fedora, RHEL, CentOS:

systemctl restart fail2ban.service

Debian, Ubuntu:

serviço fail2ban restart

firewall

Fedora, RHEL, CentOS:

Selinux e Iptables são ativados por padrão nesses sistemas e eu recomendo que você continue assim. Como abrir uma porta com iptables? Vamos ver como abrir a nova porta 2000 da porta ssh que alteramos anteriormente:

Aberto:

nano / etc / sysconfig / iptables

e modificamos a linha referente à porta SSH padrão 22 e deixamos assim:

# -A INPUT -m state --state NOVO -m tcp -p tcp --dport 22 -j ACEITAR -A INPUT -p tcp -m state --state NOVO -m tcp --dport 2000 -j ACEITAR

Salvamos com CTRL + O e fechamos com CTRL + X

Reiniciamos o serviço:

systemctl restart iptables

Debian, Ubuntu:

No Debian ou Ubuntu e derivados, temos um firewall UFW que vai facilitar a nossa vida, pois gerencia o Netfilter muito facilmente.

instalação:

apt-get install ufw ufw enable

Para ver o status das portas abertas, executamos:

ufw status

Para abrir uma porta (em nosso exemplo, será a nova porta ssh 2000):

ufw allow 2000

Para negar uma porta (em nosso caso, será a porta padrão 22 do ssh):

ufw deny 22 ufw delete deny 22

E amigos prontos. Dessa forma, eles manterão suas máquinas seguras. Não esqueça de comentar e até a próxima: D.


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   pecador dito

    e um sistema de criptografia, como: https://www.dyne.org/software/tomb/

    1.    pecador dito

      E também prenda os usuários em sua casa se eles se conectarem por tty:
      http://olivier.sessink.nl/jailkit/index.html#intro
      https://operativoslinux.wordpress.com/2015/02/21/enjaular-usuarios-en-linux/ (O caminho fácil)

    2.    yukiteru dito

      É muito melhor e mais seguro criptografar todo o sistema de arquivos.

    3.    Petercheco dito

      Para o seguinte tutorial sobre segurança no Linux, vou levar isso em consideração: D.

      1.    yukiteru dito

        Também seria bom falar sobre como proteger o kernel através do sysctl, ativar o heap aleatório e Exec-Shield nos kernels que o suportam, habilitar o acesso ao dmesg e ao sistema de arquivos / proc, rodar um daemon de auditoria, habilitar a proteção TCP SYN, restrinja o acesso a / dev / mem, desative as opções de pilha TCP / IP que podem ser perigosas ou inseguras para o sistema (redirecionar, echo, roteamento de origem), use pam_cracklib para que os usuários gerem senhas fortes, a importância de uso de sistema MAC como Tomoyo, AppArmor e SELinux.

  2.   Kuk dito

    muito útil!!!! apenas o que eu estava procurando, obrigado 🙂

    1.    Petercheco dito

      De nada amigo :).

  3.   lâmina de anjo dito

    Se o apache for usado, não faz mal adicionar regras com mod_rewrite para evitar bots. Muito útil

    http://perishablepress.com/eight-ways-to-blacklist-with-apaches-mod_rewrite/

    1.    Rolo dito

      e para nginx existe algum truque ou configuração?

  4.   Rolo dito

    No debian 8 o arquivo / etc / ssh / sshd_config já tem o protocolo 2 ativo e a função PermitRootLogin está com a opção sem senha (você só pode entrar root com a chave de autenticação e do computador que possui a chave privada)

    pd no debian 8 firewalld já chegou, o que o deixa pequeno para ufw

    1.    caçador dito

      Você viu Ferm? Gosto de como as regras são definidas.

      http://ferm.foo-projects.org/download/examples/webserver.ferm

    2.    Petercheco dito

      Bem, estou feliz que o Debian 8 use firewalld, pois é muito, muito bom ...

  5.   caçador dito

    Cuidado com o fail2ban que um invasor fabrica pacotes com o ip do pc local e torna o DOS muito fácil.

    1.    Hery dito

      Cara, o IP do PC local e o de loopback estão excluídos da lista Fail2ban.
      Caso contrário, podemos ter falsos positivos.

  6.   Jason soto dito

    Recomendações boas e muito eficazes… Claro, no ambiente de servidor e se estivermos hospedando um site, isso envolve etapas adicionais…. Atualmente mantemos um projeto chamado JackTheStripper que nada mais é do que um script bash que prepara e protege um servidor com GNU / Linux seguindo as melhores práticas de segurança, para aplicações web ... você pode conhecer o projeto em http://www.jsitech.com/jackthestripper ....

    1.    yukiteru dito

      Bom script, embora eu goste de manter o valor de kernel.randomize_va_space = 2

      1.    Jason soto dito

        O bom é que antes de executá-lo, você pode modificá-lo um pouco de acordo com suas necessidades… ..A Saudações…

    2.    Petercheco dito

      Olá, claro que meu post trata de um segurado básico e cada um deve se proteger mais ou menos dependendo dos serviços que tem instalado em seus sistemas como LAMP ou FTP, SFTP, BIND e um longo etcetera:)…

      Na próxima postagem sobre segurança, tratarei dessas questões.

      Obrigado pelo feedback positivo :).

  7.   nex dito

    @petercheco, seus guias são excelentes, seria um bom guia de criptografia para o sistema FreeeBSD, não sei quando você fará a segunda parte sobre FreeBSD, sobre configuração e customização de desktops, sobre Firewall, sobre como criar e configurar uma rede wireless.

    1.    Petercheco dito

      Olá amigo,
      Estou um pouco ocupado com a raridade de postagens, mas vou manter isso em mente na próxima postagem do FreeBSD.

      Uma saudação :).

  8.   Solrak Guerreiro Arco-Íris dito

    Isso nivelou nos comentários, não tenho ideia do que você está falando, ninguém xD
    Ótimo artigo!

  9.   xunil dito

    Essa ação de segurança implica em limitar o equipamento de alguma forma?

    1.    Petercheco dito

      Não ... O uso normal do sistema não é limitado de forma alguma.

  10.   pecador dito

    E o engraçado (trágico) é que, como acabamos de ver nas máquinas Lenovo, se o firmware do BIOS for adulterado com malware, nada do que você fizer importa.

    1.    Petercheco dito

      Contanto que você use o Windows pré-instalado pelo fabricante ...

      1.    pecador dito

        erro: lembre-se que eles instalaram no firmware da bios, ou seja, ele começa com o sistema a cada reinicialização, antes do sistema operacional, antes dos demônios, em primeiro lugar, e não deixa você fazer nada contra isso. ataca pouco pode ser feito, então a ideia de uefi é boa em princípio.

  11.   Paul dito

    Artigo interessante, vou lê-lo com mais atenção esta tarde. Obrigado.

    1.    Petercheco dito

      De nada :). Me alegro.

  12.   Carlos Best dito

    Excelente artigo, passei a tarde inteira lendo-o. O tempo que você gasta para explicar tudo com muito cuidado é apreciado,

    Saudações do Chile
    Carlos

    1.    Petercheco dito

      Olá, Carlos,
      Muito obrigado :).

  13.   Bryon dito

    As máquinas Lenovo, se o firmware do bios parece estar interferido com malware, as máquinas (Laptop PC-Desktop) vêm sempre instaladas com Windows pelo fabricante, tendo em vista o exposto… o post… .petercheco?

    1.    yukiteru dito

      Mesmo sem fazer tudo isso ele funciona, já que o malware é feito para Windows, não para Linux.

  14.   SinFlag dito

    Muitas coisas e truques estão faltando no iptables, como tonto nmap para que de todas as portas abertas, mentindo que é um pc com windows usando o ttl e o tamanho da janela, scanlogd, apache mod security, grsec, selinux ou algo parecido. Substitua ftp por sftp, limite o número de conexões por IP para cada serviço na porta X para evitar que antes de um DDoS nos deixem sem serviços, bem como bloqueie os IPs que enviam mais de tantos UDP por tantos segundos.

    1.    Petercheco dito

      Com os exemplos que você apresentou, um novo usuário enlouqueceria ao lê-lo ... Você não pode colocar tudo em um post. Vou fazer várias entradas :).

  15.   Shini-kire dito

    Eu recebo um erro no archlinux neste ponto ao fornecer o serviço de início, eu dou o status e sai:
    status sudo systemctl fail2ban
    ● fail2ban.service - Serviço Fail2Ban
    Carregado: carregado (/usr/lib/systemd/system/fail2ban.service; ativado; predefinição do fornecedor: desativado)
    Ativo: falhou (Resultado: limite de início) desde Sex. 2015-03-20 01:10:01 CLST; 1s atrás
    Documentos: man: fail2ban (1)
    Processo: 1695 ExecStart = / usr / bin / fail2ban-client -x start (código = saiu, status = 255)

    20 de março 01:10:01 Gundam systemd [1]: Falha ao iniciar o serviço Fail2Ban.
    20 de março 01:10:01 Gundam systemd [1]: A unidade fail2ban.service entrou em estado de falha.
    20 de março 01:10:01 Gundam systemd [1]: fail2ban.service falhou.
    20 de março 01:10:01 Gundam systemd [1]: solicitação de início repetida muito rapidamente para fail2ban ... ice
    20 de março 01:10:01 Gundam systemd [1]: Falha ao iniciar o serviço Fail2Ban.
    20 de março 01:10:01 Gundam systemd [1]: A unidade fail2ban.service entrou em estado de falha.
    20 de março 01:10:01 Gundam systemd [1]: fail2ban.service falhou.
    Dica: algumas linhas foram reticuladas, use -l para mostrar por completo.
    alguma ajuda? D:

    1.    Petercheco dito

      Olá, se você habilitou fail2ban com systemctl enable fail2ban.service e systemctl start fail2ban.service, o problema estará na configuração das jaulas que você fez. Verifique sua prisão e verifique se está tudo bem.

      Uma saudação
      PeterCzech

      1.    maykel franco dito

        Em primeiro lugar, um bom tutorial. Muitas coisas estão faltando, mas você se concentrou no básico.

        shini-kire, verifique seu /var/log/fail2ban.log

        Saudações.

      2.    Petercheco dito

        Obrigado @Maykel Franco :).

  16.   jony127 dito

    bom,

    fail2ban deve instalá-lo em um pc doméstico ou é mais para servidores ??

    Obrigado.

    1.    Petercheco dito

      Antes para os servidores, mas se você estiver em um wi-fi acessível por mais pessoas do que você, é bom ...

  17.   Rodrigo dito

    Olá amigo, me parece um bom post de segurança na parte de um curto incêndio nas distros Gnu / Linux. Estou escrevendo este comentário porque estou fazendo isso em uma distribuição do Ubuntu 14.04 sabendo que já está no 15.04 o que acontece é o seguinte problema Eu entro nano /etc/fail2ban/jail.local como root e não tenho visualização na parte sshd e salvo na parte chamada [DEFAULT] nós descomentamos e modificamos #bantime = 3600 e
    Na parte [sshd], apresentamos enabled = true deixando assim:
    #habilitado = verdadeiro
    ativado = verdadeiro
    Não parece que do sshd pode ser porque estou trabalhando na versão anterior obrigado