Maximera säkerheten på GNU / Linux

Hej vänner från DesdeLinux, lo prometido es deuda y aquí va un post de hur man maximerar skyddet av Linux-system och stanna så säker från inkräktare såväl som att skydda informationen på dina servrar, datorer eller bärbara datorer !!!!

utgångs

Fail2ban: är en applikation skriven i Python för att förhindra intrång i ett system, som agerar genom att straffa eller blockera fjärranslutningar som försöker brute force access.

installation:

Fedora, RHEL, CentOS:

yum install fail2ban

Debian, Ubuntu:

apt-get install fail2ban

Miljö:

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

I den del som heter [DEFAULT] tar vi bort och ändrar #bantime = 3600 och lämnar det så här:

#bantime = 3600 bantime = 604800

I [sshd] -delen introducerar vi enabled = true och lämnar det så här:

#enabled = true enabled = true

Vi sparar med CTRL + O och stänger med CTRL + X

Vi startar tjänsten:

Fedora, RHEL, CentOS:

systemctl aktivera fail2ban.service systemctl start fail2ban.service

Debian, Ubuntu:

service fail2ban start

Neka root-åtkomst med ssh:

För att skydda vår maskin kommer vi att förneka ssh genom root-användaren. För att göra detta redigerar vi filen / etc / ssh / sshd_config enligt följande:

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

Vi kommenterar och förändrar

#Protocol 2 Protokoll 2

Vi kommenterar och förändrar

#PermitRootLogin ja PermitRootLogin nej

Vi sparar med CTRL + O och stänger med CTRL + X

Vi startar tjänsten:

Fedora, RHEL, CentOS:

systemctl aktivera sshd.service systemctl starta sshd.service

Debian, Ubuntu:

service sshd start

Neka åtkomst till en ssh-server med lösenord och tillåt ssh endast med RSA-nycklar

Om vi ​​vill ansluta med PC1 till Server1 är det första vi måste göra att skapa vår nyckel på PC1. Med vår användare och utan root på PC1 kör vi:

ssh-keygen -t rsa -b 8192 (detta genererar en mer än säker nyckel eftersom nycklar från 1024 till 2048 normalt används)

När vi väl har lösenordet laddar vi upp det till Server1:

ssh-copy-id-användare @ server_ip

När detta är klart kommer vi att ansluta till vår Server1 och ändra nano / etc / ssh / sshd_config-filen med rotbehörigheter:

ssh-användare @ Server1 nano / etc / ssh / sshd_config

Vi ändrar raden som säger #PasswordAuthentication ja till detta:

#PasswordAuthentication ja
PasswordAuthentication no

Vi sparar med CTRL + O och stänger med CTRL + X

Vi startar om ssh-tjänsten:

Fedora, RHEL, CentOS:

systemctl starta om sshd.service

Debian, Ubuntu:

service sshd starta om

Ändra ssh-lyssningsport

Återigen redigerar vi / etc / ssh / sshd_config och i den del som hänvisar till porten lämnar vi den så här:

# Port 22 Port 2000 (eller något annat nummer som är större än 2000. I våra exempel kommer vi att använda detta.)

Vi sparar med CTRL + O och stänger med CTRL + X

Vi startar om ssh-tjänsten:

Fedora, RHEL, CentOS:

systemctl starta om sshd.service

Debian, Ubuntu:

service sshd starta om

Om de använder fail2ban är det nödvändigt att ändra konfigurationen angående sshd-justering av porten.

nano /etc/fail2ban/jail.local

[sshd]
port    = ssh, 2000

[sshd-ddos]
port    = ssh, 2000

[dropbear]
port    = ssh, 2000

[selinux-ssh]
port    = ssh, 2000

Vi sparar med CTRL + O och stänger med CTRL + X

Vi förnyar tjänsten:

Fedora, RHEL, CentOS:

systemctl startar om fail2ban.service

Debian, Ubuntu:

tjänsten fail2ban omstart

brandvägg

Fedora, RHEL, CentOS:

Selinux och Iptables är aktiverade som standard på dessa system och jag rekommenderar att du fortsätter på det här sättet. Hur öppnar jag en port med iptables? Låt oss se hur man öppnar den nya porten 2000 för ssh-porten som vi ändrade tidigare:

Öppet:

nano / etc / sysconfig / iptables

och vi ändrar raden som hänvisar till standard ssh-port 22 och lämnar den så här:

# -A INPUT -m-tillstånd --stat NYTT -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --stat NEW -m tcp --dport 2000 -j ACCEPT

Vi sparar med CTRL + O och stänger med CTRL + X

Vi startar om tjänsten:

systemctl starta om iptables

Debian, Ubuntu:

I Debian eller Ubuntu och derivat har vi en UFW-brandvägg som gör livet enkelt för oss eftersom det hanterar Netfilter väldigt enkelt.

installation:

apt-get install ufw ufw aktivera

För att se statusen för öppna portar utför vi:

ufw-status

För att öppna en port (i vårt exempel blir det den nya ssh-porten 2000):

ufw tillåta 2000

För att neka en port (i vårt fall kommer det att vara standardport 22 för ssh):

ufw neka 22 ufw ta bort neka 22

Och redo vänner. På så sätt håller de dina maskiner säkra. Glöm inte att kommentera och tills nästa gång: D.


41 kommentarer, lämna din

Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   syndare sade

    och ett krypteringssystem såsom: https://www.dyne.org/software/tomb/

    1.    syndare sade
    2.    yukiteru sade

      Det är mycket bättre och säkrare att kryptera hela filsystemet.

    3.    Petercheco sade

      För följande handledning om säkerhet i Linux tar jag hänsyn till det: D.

      1.    yukiteru sade

        Det skulle också vara bra att prata om att härda kärnan genom sysctl, aktivera den slumpmässiga heapen och Exec-Shield i de kärnor som stöder den, möjliggöra åtkomst till dmesg och / proc-filsystemet, köra en revisionsdemon, aktivera TCP-skydd SYN, begräns tillgång till / dev / mem, inaktivera TCP / IP-stackalternativ som kan vara farliga eller osäkra för systemet (omdirigering, eko, källrutt), använd pam_cracklib för användare att generera starka lösenord, vikten av att använda MAC-system som Tomoyo, AppArmor och SELinux.

  2.   kuk sade

    mycket användbart!!!! precis vad jag letade efter tack 🙂

    1.    Petercheco sade

      Du är välkommen min vän :).

  3.   ängelblad sade

    Om du använder apache skadar det inte att lägga till regler med mod_rewrite för att undvika bots. Mycket användbart

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

    1.    Rolo sade

      och för nginx finns det något trick eller konfiguration?

  4.   Rolo sade

    I debian 8 har filen / etc / ssh / sshd_config redan protokoll 2 aktivt och funktionen PermitRootLogin är med alternativet utan lösenord (du kan bara ange root med autentiseringsnyckeln och från datorn som har den privata nyckeln)

    pd i debian 8 firewalld har anlänt som lämnar den liten till ufw

    1.    djägare sade

      Har du sett ferm? Jag gillar hur reglerna definieras.

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

    2.    Petercheco sade

      Jag är glad att Debian 8 använder firewalld eftersom det är väldigt mycket väldigt bra ...

  5.   djägare sade

    Se upp för fail2ban att en angripare tillverkar paket med ip på den lokala datorn och gör DOS väldigt enkelt.

    1.    Hery sade

      Man, den lokala datorns IP och loopback-IP utesluts från Fail2ban-listan.
      Om inte, kan vi ha falska positiva resultat.

  6.   Jason soto sade

    Bra och mycket effektiva rekommendationer ... Naturligtvis i servermiljön och om vi är värd för en webbplats innebär det ytterligare steg .... Vi upprätthåller för närvarande ett projekt som heter JackTheStripper, vilket är inget annat än ett bash-skript som förbereder och säkrar en server med GNU / Linux enligt de bästa säkerhetsmetoderna för webbapplikationer ... du kan känna till projektet på http://www.jsitech.com/jackthestripper ....

    1.    yukiteru sade

      Trevligt skript även om jag vill behålla värdet på kernel.randomize_va_space = 2

      1.    Jason soto sade

        Det fina är att innan du kör den kan du ändra den lite efter dina behov ..... A Hej ...

    2.    Petercheco sade

      Hej, naturligtvis handlar mitt inlägg med en försäkrad bas och var och en måste skydda sig mer eller mindre beroende på de tjänster som den har installerat i sina system som LAMP eller FTP, SFTP, BIND och en lång etcetera:) ...

      I nästa inlägg om säkerhet kommer jag att ta upp dessa frågor.

      Tack för den positiva feedbacken :).

  7.   nex sade

    @petercheco, dina guider är utmärkta, det skulle vara bra en krypteringsguide för FreeeBSD-systemet, jag vet inte när du ska göra den andra delen om FreeBSD, om konfiguration och anpassning av skrivbord, om brandvägg, om att skapa och konfigurera ett trådlöst nätverk.

    1.    Petercheco sade

      Hej vän,
      Jag är lite upptagen som den sällsynta postningen visar, men jag kommer att ha det i åtanke för nästa FreeBSD-inlägg.

      En hälsning :).

  8.   Solrak Rainbow Warrior sade

    Det som planerades i kommentarerna, jag har ingen aning om vad du pratar om, ingen xD
    Bra artikel!

  9.   xunil sade

    Denna säkerhetsåtgärd innebär att du begränsar utrustningen på något sätt?

    1.    Petercheco sade

      Nej ... Den normala användningen av systemet är inte begränsad alls.

  10.   syndare sade

    Och det roliga (tragiska) är att, som vi just såg med Lenovo-maskiner, om bios-firmware manipuleras med skadlig kod, så spelar ingenting du gör någon roll.

    1.    Petercheco sade

      Så länge du använder Windows förinstallerat av tillverkaren ...

      1.    syndare sade

        fel: kom ihåg att de installerade det i bios firmware, det vill säga det börjar med systemet vid varje omstart, innan operativsystemet, innan demonerna, först och främst, och det låter dig inte göra någonting mot det. attackerar lite kan göras, varför uefi-idén i princip är bra.

  11.   Paul sade

    Intressant artikel, jag kommer att läsa den mer noggrant i eftermiddags. Tack.

    1.    Petercheco sade

      Varsågod :). Jag är glad.

  12.   Carlos bäst sade

    Utmärkt artikel, jag underhöll mig själv hela eftermiddagen när jag läste den. Tiden du tar för att förklara allt mycket noggrant uppskattas,

    Hälsningar från Chile
    Carlos

    1.    Petercheco sade

      Hola Carlos,
      Tack så mycket :).

  13.   brion sade

    Lenovo-maskiner, om bio-firmware verkar ingripa med skadlig programvara, kommer maskinerna (bärbar PC-stationär dator) alltid installeras med Windows av tillverkaren, med tanke på ovanstående ... gör inlägget ... .petercheco?

    1.    yukiteru sade

      Även utan att göra allt detta fungerar det, eftersom skadlig kod är gjord för Windows, inte Linux.

  14.   SynFlagga sade

    Det finns många saker och knep som saknas i iptables, såsom yr nmap så att av alla öppna portar, ljuger att det är en Windows-dator som använder ttl och fönsterstorlek, scanlogd, apache mod säkerhet, grsec, selinux eller något liknande . Ersätt ftp med sftp, begränsa antalet anslutningar per IP till varje tjänst i X-port för att undvika att innan en DDoS lämnar oss utan tjänster, samt blockera IP-adresserna som skickar mer än så många UDP i så många sekunder.

    1.    Petercheco sade

      Med de exempel du presenterade skulle en ny användare bli galen när han läste den ... Du kan inte lägga allt i ett inlägg. Jag kommer att göra flera bidrag :).

  15.   shini kire sade

    Jag får ett fel i archlinux vid denna tidpunkt när jag ger starttjänsten, jag ger status och detta kommer ut:
    sudo systemctl status fail2ban
    ● fail2ban.service - Fail2Ban Service
    Laddad: laddad (/usr/lib/systemd/system/fail2ban.service; aktiverad; leverantörsförinställning: inaktiverad)
    Aktiv: misslyckades (Resultat: startgräns) sedan fre 2015-03-20 01:10:01 CLST; För 1s sedan
    Dokument: man: fail2ban (1)
    Process: 1695 ExecStart = / usr / bin / fail2ban-client -x start (kod = avslutad, status = 255)

    20 mars 01:10:01 Gundam systemd [1]: Det gick inte att starta Fail2Ban Service.
    20 mars 01:10:01 Gundam systemd [1]: Enheten fail2ban.service in i misslyckat tillstånd.
    20 mars 01:10:01 Gundam systemd [1]: fail2ban.service misslyckades.
    20 mars 01:10:01 Gundam systemd [1]: startförfrågan upprepas för snabbt för fail2ban ... is
    20 mars 01:10:01 Gundam systemd [1]: Det gick inte att starta Fail2Ban Service.
    20 mars 01:10:01 Gundam systemd [1]: Enheten fail2ban.service in i misslyckat tillstånd.
    20 mars 01:10:01 Gundam systemd [1]: fail2ban.service misslyckades.
    Tips: Vissa linjer var ellipsiserade, använd -l för att visa i sin helhet.
    lite hjälp? D:

    1.    Petercheco sade

      Hej, om du aktiverade fail2ban med systemctl aktiverar fail2ban.service och systemctl startar fail2ban.service, kommer problemet att finnas i den konfiguration du har gjort. Kontrollera ditt fängelse och kontrollera att allt är bra.

      hälsningar
      Peter Tjeckiska

      1.    maykel franco sade

        Först och främst bra handledning. Många saker saknas men du har fokuserat på grunderna.

        shini-kire, kolla din /var/log/fail2ban.log

        Hälsningar.

      2.    Petercheco sade

        Tack @Maykel Franco :).

  16.   jony127 sade

    bra,

    fail2ban ska de installera den på en hemdator eller är det mer för servrar ???

    Tack.

    1.    Petercheco sade

      Snarare för servrarna men om du använder en wifi som är tillgänglig för fler än du, är det bra ...

  17.   Rodrigo sade

    Hej vän, jag tycker att det är ett bra säkerhetsinlägg i den del av en kort brand i Gnu / Linux-distributionerna, jag skriver den här kommentaren eftersom jag gör det i en Ubuntu 14.04-distribution med vetskap om att det redan är 15.04 vad som händer är följande problem anger jag nano /etc/fail2ban/jail.local som root och jag har ingen visualisering i sshd-delen och sparar I den del som heter [DEFAULT] avkommenterar vi och ändrar #bantime = 3600 och
    I [sshd] -delen introducerar vi enabled = true och lämnar det så här:
    #aktiverat = sant
    aktiverad = sant
    Det verkar inte som av sshd som kan bero på att jag arbetar med den tidigare versionen tack