Maximitza la seguretat en GNU / Linux

Hola amics de DesdeLinux, el promès és deute i aquí va un post de com maximitzar la protecció de sistemes Linux i mantenir-se així fora de perill d'intrusos a més de protegir la informació en els seus servidors, PC o portàtils !!!!

Començant

fail2ban: és una aplicació escrita en Python per a la prevenció d'intrusos en un sistema, que actua penalitzant o bloquejant les connexions remotes que intenten accessos per força bruta.

Instal · lació:

Fedora, RHEL, CentOS:

yum install fail2ban

Debian, Ubuntu:

apt-get install fail2ban

Configuració:

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

A la part anomenada [DEFAULT] descomentem i modifiquem #bantime = 3600 deixant així:

#bantime = 3600 bantime = 604800

A la part [sshd] introduïm enabled = true deixant així:

#enabled = true enabled = true

Guardem amb CTRL + O i tanquem amb CTRL + X

Iniciem el servei:

Fedora, RHEL, CentOS:

systemctl enable fail2ban.service systemctl start fail2ban.service

Debian, Ubuntu:

service fail2ban start

Denegar accés root usant ssh:

Per protegir la nostra màquina anem a denegar ssh mitjançant l'usuari root. Per a això editem l'arxiu / etc / ssh / sshd_config de la següent manera:

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

Descomentem i canviem

#Protocol 2 Protocol 2

Descomentem i canviem

#PermitRootLogin yes PermitRootLogin no

Guardem amb CTRL + O i tanquem amb CTRL + X

Iniciem el servei:

Fedora, RHEL, CentOS:

systemctl enable sshd.service systemctl start sshd.service

Debian, Ubuntu:

service sshd start

Denegar accés a un servidor ssh usant clau i permetre ssh només amb claus RSA

Si volem connectar-nos amb el PC1 a l'Servidor1 el primer que hem de fer és generar la nostra clau en el PC1. Amb el nostre usuari i sense root al PC1 executem:

ssh-keygen -t rsa -b 8192 (això genera una clau més que segura ja que normalment es fan servir claus de 1024-2048)

Un cop tenim la nostra clau la vam pujar a l'Servidor1:

ssh-copy-id usuari @ ip_del_servidor

En aquest punt anem a connectar-nos al nostre Servidor1 i modifiquem amb permisos de root l'arxiu nano / etc / ssh / sshd_config:

ssh usuari @ Servidor1 nano / etc / ssh / sshd_config

La línia que posa #PasswordAuthentication yes la canviem a això:

#PasswordAuthentication yes
PasswordAuthentication no

Guardem amb CTRL + O i tanquem amb CTRL + X

Reiniciem el servei ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

service sshd restart

Canviar el port d'escolta ssh

Novament vam editar / etc / ssh / sshd_config i en la part referent a l'port la deixem així:

# Port 22 Port 2000 (o qualsevol altre nombre més gran que 2000. En els nostres exemples farem servir aquest.)

Guardem amb CTRL + O i tanquem amb CTRL + X

Reiniciem el servei ssh:

Fedora, RHEL, CentOS:

systemctl restart sshd.service

Debian, Ubuntu:

service sshd restart

Si fan servir fail2ban cal canviar la configuració referent a sshd ajustant el port.

nano /etc/fail2ban/jail.local

[sshd]
port    = ssh, 2000

[sshd-ddos]
port    = ssh, 2000

[dropbear]
port    = ssh, 2000

[selinux-ssh]
port    = ssh, 2000

Guardem amb CTRL + O i tanquem amb CTRL + X

Reniciamos el servei:

Fedora, RHEL, CentOS:

systemctl restart fail2ban.service

Debian, Ubuntu:

service fail2ban restart

Firewall

Fedora, RHEL, CentOS:

En aquests sistemes es troben SELinux i Iptables activats per defecte i jo recomano que segueixi així. Com obrir un port amb Iptables? Anem a veure com obrir el nou port 2000 del port ssh que vam canviar anteriorment:

obrir:

nano / etc / sysconfig / iptables

i modifiquem la línia referent a port ssh per defecte 22 i la deixem així:

# -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 2000 -j ACCEPT

Guardem amb CTRL + O i tanquem amb CTRL + X

Reiniciem el servei:

systemctl restart iptables

Debian, Ubuntu:

A Debian o Ubuntu i derivats disposem de UFW tallafocs el qual ens farà la vida fàcil ja que gestiona a Netfilter molt fàcil.

Instal · lació:

apt-get install ufw ufw enable

Per veure l'estat de ports oberts executem:

ufw status

Per obrir un port (en el nostre exemple serà el nou port 2000 de ssh):

ufw allow 2000

Per denegar un port (en el nostre cas serà el port per defecte 22 de ssh):

ufw deny 22 ufw delete deny 22

I llest amics. D'aquesta manera mantindran les vostres màquines fora de perill. No us oblideu comentar i fins la propera: D.


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   pecador va dir

    i un sistema d'encriptació com ara: https://www.dyne.org/software/tomb/

    1.    pecador va dir

      I també engabiar usuaris en el seu home si es connecten per tty:
      http://olivier.sessink.nl/jailkit/index.html#intro
      https://operativoslinux.wordpress.com/2015/02/21/enjaular-usuarios-en-linux/ (La manera fàcil)

    2.    Yukiteru va dir

      És molt millor i més segur encriptar tot el sistema d'arxius.

    3.    petxec va dir

      Per al següent tut referent a la seguretat en Linux ho tindré en compte: D.

      1.    Yukiteru va dir

        També seria bo parlar de hardening de el nucli per mitjà de sysctl, activar el random heap i Exec-Shield en els nuclis que el suporten, capar l'accés a dmesg i a el sistema de fitxers / proc, executar un dimoni audit, habilitar la protecció TCP SYN, restringir els accés a / dev / mem, desactivar opcions de la pila TCP / IP que poden ser perilloses o resten seguretat a sistema (redirect, trobo, source routing), usar pam_cracklib perquè els usuaris generin contrasenyes fortes, la importància de l' ús de sistema MAC com Tomoyo, AppArmor i SELinux.

  2.   Maluc va dir

    molt utíl !!!! just el que buscava gràcies 🙂

    1.    petxec va dir

      De res amic :).

  3.   angelblade va dir

    Si es fa servir apatxe, no està de més afegir regles amb mod_rewrite per evitar-se els brossa. molt útil

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

    1.    rolo va dir

      i per Nginx hi ha algun truc o configuració ??

  4.   rolo va dir

    en debian 8 l'arxiu / etc / ssh / sshd_config ja porta actiu Protocol 2 i la funció PermitRootLogin aquesta amb l'opció without-password (només es pot ingressar a root amb la clau d'autenticació i des computador que té la clau privada)

    pd en debian 8 ia arribo firewalld que el deixa petitó a ufw

    1.    caçador va dir

      Has vist ferm? M'agrada com es defineixen les regles.

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

    2.    petxec va dir

      Doncs me n'alegro que Debian 8 usi firewalld ja que és molt molt molt bo ...

  5.   caçador va dir

    Compte amb fail2ban que un atacant fabrica paquets amb el ip de la pc local i fa un DUES molt fàcil.

    1.    Hery va dir

      Home, la IP de l'ordinador local i la de bucle s'exclouen de la llista de fail2ban.
      Si no, podríem tenir falsos positius.

  6.   Jason Soto va dir

    Bones Recomanacions i molt efectives ... És clar que en l'ambient de servidors i si estem hosteando un web comporta passos addicionals .... Actualment mantenim un projecte anomenat JackTheStripper que no és mes que un Script en bash que prepara i assegura un servidor amb GNU / Linux seguint les millors pràctiques de seguretat, per a aplicacions web ... poden conèixer el projecte en http://www.jsitech.com/jackthestripper ....

    1.    Yukiteru va dir

      Bon script encara que m'agrada mantenir el valor de kernel.randomize_va_space = 2

      1.    Jason Soto va dir

        El millor és que abans de córrer, pots modificar una mica a les teves necessitats ... ..un Salutació ...

    2.    petxec va dir

      Hola, és clar que el meu post tracta d'un assegurat base i cadascú ha de protegir-se més o menys depenent dels serveis que té instal·lat en els seus sistemes com ho pot ser LAMP o FTP, SFTP, BIND i un llarg etcètera:) ...

      En el proper post sobre seguretat tractaré aquests temes.

      Gràcies per l'opinió positiva :).

  7.   annex va dir

    @petercheco, els teus guies són excel·lents, seria bo una guia d'encriptació per al sistema de FreeeBSD, no quan vagis a fer la segona part sobre FreeBSD, sobre configuració i personalització d'escriptoris, sobre Firewall, sobre crear i configurar xarxa sense fils.

    1.    petxec va dir

      Hola amic,
      camino una mica ocupat com demostra la poca freqüència de publicació, però ho tindré en compte per al proper post per FreeBSD.

      Una salutació :).

  8.   Solrak Rainbowarrior va dir

    Que anivellat en els comentaris, no tinc ni idea o que parleu, ningú xD
    Gran article!

  9.   xunil va dir

    Aquesta acció de seguretat implica limitar d'alguna forma l'equip ??

    1.    petxec va dir

      No ... No es limita en res l'ús normal de sistema.

  10.   pecador va dir

    I el curiós (tràgic) és que, com recentment hem vist amb les màquines Lenovo, si el microprogramari de l'bios està intervingut amb malware, res del que facis importa.

    1.    petxec va dir

      Sempre i quan facis servir el Windows preinstal·lat pel fabricant ...

      1.    pecador va dir

        error: recorda que el van instal·lar en el microprogramari de l'bios, o sigui que s'inicia amb el sistema en cada reinici, abans que el sistema operatiu, abans que els dimonis, primer de tot, i no et deixa fer res en contra.Ante aquests atacs poc es pot fer.Per això la idea de l'UEFI és bona en principi.

  11.   Pau va dir

    Interessant article, el llegiré amb més deteniment en aquesta tarda. Gràcies.

    1.    petxec va dir

      De res :). M'alegro.

  12.   Carlos Millor va dir

    Excel·lent article, em vaig entretenir tota la tarda llegint-lo. S'agraeix el temps que et prens per explicar tot molt detingudament,

    Salutacions des de Xile
    Carlos

    1.    petxec va dir

      Hola Carles,
      Moltes gràcies :).

  13.   Bryon va dir

    Les màquines Lenovo, si el microprogramari de l'bios sembla estar intervingut amb malware, les maquines (PC Portatils-Computer de taula) sempre ve instal·lat amb Windows pel fabricant, davant l'exposat ... serveix el de l'post ... .petercheco ?.

    1.    Yukiteru va dir

      Fins i tot sense fer tot això serveix, ja que el malware està fet per a Windows no per a Linux.

  14.   SynFlag va dir

    Falten moltes coses i trucs d'iptables, com marejar nmap perquè de tots els port oberts, mentir que és una pc windows mitjançant el ttl i la mida de finestra, scanlogd, apatxe mod security, grsec, selinux o alguna cosa d'això. Substitueix ftp per sftp, limitar la quantitat de connexions per IP a cada servei en X port per evitar que davant d'un DDoS ens deixin sense serveis, així com bloquejar les IP que envien més de tanta quantitat d'UDP per tants segons.

    1.    petxec va dir

      Amb els exemples que vas exposar un usuari novell es tornaria boig a l'llegir-lo ... No es pot posar tot en un post. Hare diverses entrades :).

  15.   Shini-Kire va dir

    em dóna error en ArchLinux en aquest punt a el donar el servei start, li dono a l'estat i això surt:
    suo systemctl estatus fail2ban
    ● fail2ban.service - fail2ban Service
    Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; habilitat; vendor preset: disabled)
    Active: failed (Result: start-limit) since div 2015 03:20:01 CLST; 10s ago
    Docs: man: fail2ban (1)
    Process: 1695 ExecStart = / usr / bin / fail2ban-client -x start (code = exited, status = 255)

    mar 20 01:10:01 Gundam systemd [1]: Failed to start fail2ban Service.
    mar 20 01:10:01 Gundam systemd [1]: Unit fail2ban.service Entered failed state.
    mar 20 01:10:01 Gundam systemd [1]: fail2ban.service failed.
    mar 20 01:10:01 Gundam systemd [1]: start request repeated too quickly for fail2ban ... ice
    mar 20 01:10:01 Gundam systemd [1]: Failed to start fail2ban Service.
    mar 20 01:10:01 Gundam systemd [1]: Unit fail2ban.service Entered failed state.
    mar 20 01:10:01 Gundam systemd [1]: fail2ban.service failed.
    Hint: Some lines were ellipsized, utilitzeu -l to show in full.
    alguna ajuda? D:

    1.    petxec va dir

      Hola, si habilitaste fail2ban amb systemctl enable fail2ban.service i systemctl start fail2ban.service, el problema estarà en la configuració de jails que has fet. Si us plau revisa la teva jail i verifica que tot estigui bé.

      una salutació
      Petertxec

      1.    Maykel Franco va dir

        Abans de res bon tutorial. Falten moltes coses però t'has centrat en el bàsic.

        Shini-Kire, revisa la teva /var/log/fail2ban.log

        Salutacions.

      2.    petxec va dir

        Gràcies @Maykel Franco :).

  16.   jony127 va dir

    bones,

    fail2ban haurien instal·lar-lo en un pc domèstic o això és més aviat per servers ???

    Gràcies.

    1.    petxec va dir

      Més aviat per als servidors però si aquestes en una wifi accessible per més gent que tu ve bé ...

  17.   Rodrigo va dir

    Hola amic em sembla un bon post de seguretat a la part d'un curta foc a les distros GNU / Linux t'escric aquest comentari perquè ho estic fent en una distribució d'ubuntu 14.04 sabent que ja està en la 15.04 el que passa és el següent problema entro en nano /etc/fail2ban/jail.local com a root i no tinc visualització en la part de la sshd i guardo a la part anomenada [DEFAULT] descomentem i modifiquem #bantime = 3600 i
    A la part [sshd] introduïm enabled = true deixant així:
    #enabled = true
    habilitat = cert
    No apareix això de la sshd que pot ser serà perquè estic treballant la versió anterior gràcies