Hello barátok DesdeLinux, amit ígértek, az adósság és itt egy bejegyzés arról hogyan lehet maximalizálni a Linux rendszerek védelmét és maradjon így biztonságos a behatolóktól, valamint védi a szerverein, számítógépein vagy laptopjain található információkat !!!!
kiindulási
Fail2ban: egy Python-ba írt alkalmazás, amely megakadályozza a rendszerbe való behatolást, amely büntetéssel vagy blokkolással távoli kapcsolatokat próbál meg durva erővel elérni.
Telepítés:
Fedora, RHEL, CentOS:
yum install fail2ban
Debian, Ubuntu:
apt-get install fail2ban
Beállítás:
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local nano /etc/fail2ban/jail.local
A [DEFAULT] nevű részben kommenteljük és módosítjuk a #bantime = 3600 parancsot, így hagyva:
#bantime = 3600 bantime = 604800
Az [sshd] részben bemutatjuk az enable = true lehetőséget, így hagyjuk:
# engedélyezve = igaz engedélyezve = igaz
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Elindítjuk a szolgáltatást:
Fedora, RHEL, CentOS:
systemctl engedélyezi a fail2ban.service systemctl indítását a fail2ban.service
Debian, Ubuntu:
szolgáltatás fail2ban indítás
A root hozzáférés megtagadása az ssh használatával:
Gépünk védelme érdekében megtagadjuk az ssh-t a root felhasználóval. Ehhez az alábbiak szerint szerkesztjük az / etc / ssh / sshd_config fájlt:
cp sshd_config sshd_config.bck nano / etc / ssh / sshd_config
Kommenteljük és változunk
# 2.protokol 2. protokoll
Kommenteljük és változunk
#PermitRootLogin igen EngedélyRootLogin nem
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Elindítjuk a szolgáltatást:
Fedora, RHEL, CentOS:
systemctl engedélyezése sshd.service systemctl indítás sshd.service
Debian, Ubuntu:
service sshd start
Jelszó használatával tiltsa meg az ssh-kiszolgálóhoz való hozzáférést, és csak az RSA kulcsokkal engedélyezze az ssh-t
Ha a PC1-gyel a Server1-hez akarunk csatlakozni, akkor az első dolog a kulcs létrehozása a PC1-en. Felhasználónkkal és root nélkül a PC1-en végrehajtjuk:
ssh-keygen -t rsa -b 8192 (ez több mint biztonságos kulcsot generál, mivel az 1024 és 2048 közötti kulcsokat szokták használni)
Miután megvan a jelszavunk, feltöltjük a Server1-re:
ssh-copy-id felhasználó @ kiszolgáló_ip
Ha ez megtörtént, csatlakozni fogunk a Server1-hez és módosítani a nano / etc / ssh / sshd_config fájlt root jogosultságokkal:
ssh felhasználó @ Server1 nano / etc / ssh / sshd_config
Megváltoztatjuk a #PasswordAuthentication igent mondó sort erre:
#PasswordAuthentication igen
JelszóHitelesítés sz
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Indítjuk újra az ssh szolgáltatást:
Fedora, RHEL, CentOS:
systemctl indítsa újra az sshd.service szolgáltatást
Debian, Ubuntu:
szolgáltatás sshd újraindítása
Változtassa meg az ssh hallgatási portot
Ismét szerkesztjük az / etc / ssh / sshd_config fájlt, és a portra utaló részben így hagyjuk:
# 22. port Port 2000 (vagy bármely más, 2000-nél nagyobb szám. Példáinkban ezt fogjuk használni.)
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Indítjuk újra az ssh szolgáltatást:
Fedora, RHEL, CentOS:
systemctl indítsa újra az sshd.service szolgáltatást
Debian, Ubuntu:
szolgáltatás sshd újraindítása
Ha a fail2ban-t használják, meg kell változtatni a konfigurációt az sshd port beállításához.
nano /etc/fail2ban/jail.local [sshd] port = ssh, 2000 [sshd-ddos] port = ssh, 2000 [dropbear] port = ssh, 2000 [selinux-ssh] port = ssh, 2000
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Megújítjuk a szolgáltatást:
Fedora, RHEL, CentOS:
systemctl indítsa újra a fail2ban.service fájlt
Debian, Ubuntu:
szolgáltatás fail2ban újraindítás
tűzfal
Fedora, RHEL, CentOS:
A Selinux és az Iptables alapértelmezés szerint aktiválva van ezeken a rendszereken, és ezt javasoljuk. Hogyan lehet portot nyitni az iptables segítségével? Nézzük meg, hogyan lehet megnyitni az ssh port új, 2000-es portját, amelyet korábban megváltoztattunk:
Nyisd ki:
nano / etc / sysconfig / iptables
és módosítjuk az alapértelmezett 22 ssh portra utaló sort, és így hagyjuk:
# -A BEMENET -m állapot --állapot ÚJ -m tcp -p tcp --port 22 -j ELFOGADÁS -A BEMENET -p tcp -m állapot --állapot ÚJ -m tcp --dport 2000 -j ELFOGADÁS
A CTRL + O billentyűvel mentünk, a CTRL + X billentyűkombinációval zárunk
Újraindítjuk a szolgáltatást:
systemctl indítsa újra az iptables alkalmazást
Debian, Ubuntu:
A Debianban vagy az Ubuntuban és a derivatívákban van egy UFW tűzfalunk, amely megkönnyíti az életünket, mivel nagyon egyszerűen kezeli a Netfiltert.
Telepítés:
apt-get install ufw ufw engedélyezés
A végrehajtott nyitott portok állapotának megtekintéséhez:
ufw állapot
Port megnyitása (példánkban ez az új ssh port 2000 lesz):
ufw 2000 engedélyezése
Port megtagadása (esetünkben ez lesz az ssh alapértelmezett 22. portja):
ufw deny 22 ufw törlés deny 22
És kész barátok. Így biztonságban tartják a gépeit. Ne felejtsen el hozzászólni, és legközelebb: D.
és egy titkosítási rendszert, például: https://www.dyne.org/software/tomb/
És az otthoni ketrecben lévő felhasználókat is, ha tty-vel csatlakoznak:
http://olivier.sessink.nl/jailkit/index.html#intro
https://operativoslinux.wordpress.com/2015/02/21/enjaular-usuarios-en-linux/ (a könnyű út)
Sokkal jobb és biztonságosabb az egész fájlrendszer titkosítása.
A következő, a Linux biztonságával kapcsolatos oktatóanyagnál figyelembe veszem: D.
Jó lenne beszélni arról is, hogy a rendszermagot a sysctl segítségével meg kell keményíteni, aktiválni kell a véletlenszerű kupacot és az azt támogató kernelben található Exec-Shield programot, lehetővé kell tenni a dmesg és a / proc fájlrendszer elérését, futtatni egy audit démonot, engedélyezni a TCP védelmet , korlátozza a / dev / mem hozzáférést, tiltsa le a TCP / IP verem opcióit, amelyek veszélyesek vagy nem biztonságosak a rendszerben (átirányítás, visszhang, forrás útválasztás), a pam_cracklib használatával erős jelszavakat generálhat, a MAC rendszer használatának fontosságát, mint például a Tomoyo , AppArmor és SELinux.
Nagyon hasznos!!!! csak amit kerestem köszönöm 🙂
Szívesen barátom :).
Ha apache-t használunk, nem árt szabályokat adni a mod_rewrite paranccsal a botok elkerülése érdekében. Nagyon hasznos
http://perishablepress.com/eight-ways-to-blacklist-with-apaches-mod_rewrite/
és az nginx esetében van valami trükk vagy konfiguráció?
A debian 8-ban az / etc / ssh / sshd_config fájlban már aktív a 2. protokoll, a PermitRootLogin függvény pedig jelszó nélküli opcióval rendelkezik (root-t csak a hitelesítési kulccsal adhat meg, és a privát kulccsal rendelkező számítógépről)
Megérkezett a debian 8 tűzfal pd-je, ami kicsiben hagyja az ufw-t
Láttál fermet? Tetszik, hogyan vannak meghatározva a szabályok.
http://ferm.foo-projects.org/download/examples/webserver.ferm
Nos, örülök, hogy a Debian 8 tűzfalat használ, mivel nagyon-nagyon jó ...
Vigyázzon a fail2ban, hogy egy támadó csomagokat gyárt a helyi pc ip-jével, és nagyon megkönnyíti a DOS-t.
Az ember, a helyi PC IP és a visszacsatolt IP ki van zárva a Fail2ban listából.
Ha nem, akkor lehetnek hamis pozitívumaink.
Jó és nagyon hatékony ajánlások ... Természetesen a kiszolgálói környezetben, és ha egy webhelyet tárolunk, további lépésekkel jár. Jelenleg egy JackTheStripper nevű projektet tartunk fenn, amely nem más, mint egy bash szkript, amely előkészíti és biztonságos szervert készít a GNU / Linux rendszerrel a legjobb biztonsági gyakorlatok szerint, webes alkalmazásokhoz ... http://www.jsitech.com/jackthestripper ....
Szép szkript, bár szeretem megtartani a kernel.randomize_va_space = 2 értékét
A jó dolog az, hogy mielőtt futtatná, kissé módosíthatja az igényei szerint ..... A Hello ...
Helló, természetesen a bejegyzésem egy alapbiztosítottal foglalkozik, és mindegyiket többé-kevésbé védeni kell, attól függően, hogy milyen szolgáltatásokat telepítettek a rendszereikbe, például LAMP vagy FTP, SFTP, BIND és egy hosszú stb.:)
A biztonságról szóló következő bejegyzésben ezeket a kérdéseket fogom tárgyalni.
Köszönöm a pozitív visszajelzéseket :).
@petercheco, az útmutatóid kiválóak, jó lenne egy titkosítási útmutató a FreeeBSD rendszerhez, nem tudom, mikor fogod elkészíteni a FreeBSD-ről, az asztali gépek konfigurálásáról és testreszabásáról, a tűzfalról, a létrehozásról és a második részről. vezeték nélküli hálózat konfigurálása.
Szia barátom,
Kicsit elfoglalt vagyok, ahogy a ritka posztolás is mutatja, de ezt a következő FreeBSD bejegyzésnél szem előtt tartom.
Üdvözlet :).
Ez a kommentekben eljutott, fogalmam sincs miről beszélsz, senki xD
Remek cikk!
Ez a biztonsági intézkedés a berendezés bármilyen korlátozását jelenti?
Nem ... A rendszer normál használata egyáltalán nincs korlátozva.
És a vicces (tragikus) az, hogy ahogyan a Lenovo gépeinél láttuk, ha a BIOS firmware-t rosszindulatú programokkal manipulálják, akkor semmi sem számít.
Mindaddig, amíg a gyártó által előre telepített Windows rendszert használja ...
hiba: ne felejtsük el, hogy a bios firmware-be telepítették, vagyis minden egyes újraindításkor a rendszerrel kezdődik, mindenekelőtt az operációs rendszer előtt, a démonok előtt, és nem enged semmit tenni ellenük. meg lehet csinálni, ezért az uefi ötlet elvileg jó.
Érdekes cikk, ma délután figyelmesebben elolvasom. Köszönöm.
Szívesen :). Örülök.
Kiváló cikk, egész délután szórakoztattam magam, elolvastam. Nagyra értékeljük azt az időt, amire mindent nagyon gondosan elmagyaráz,
Üdvözlet Chile
Carlos
Szia Carlos,
Nagyon köszönöm :).
Ha úgy tűnik, hogy a Lenovo gépei rosszindulatú programokkal vannak beavatkozva, a gépeket (Laptop PC-asztali számítógép) a gyártó mindig a Windows rendszerrel együtt telepíti, a fentiekre való tekintettel ... a post…. Petercheco?
Mindezek nélkül is működik, mivel a rosszindulatú program a Windows számára készült, nem pedig a Linux számára.
Sok dolog és trükk hiányzik az iptables-ből, például a szédítő nmap úgy, hogy az összes nyitott port közül hazudik, hogy ez egy Windows pc, amely a ttl-t és az ablak méretét használja, scanlogd, apache mod security, grsec, selinux vagy valami hasonló. Cserélje az ftp-t sftp-re, korlátozza az egyes portok IP-kapcsolatainak számát az X-portban, hogy elkerülje, hogy egy DDoS előtt szolgáltatás nélkül hagyjanak minket, valamint blokkolja azokat az IP-ket, amelyek annyi UDP-t küldenek ennyi másodpercre.
Az Ön által bemutatott példákkal egy új felhasználó megbolondulna, ha elolvassa ... Nem lehet mindent egy posztba tenni. Több bejegyzést teszek :).
Ezen a ponton hibaüzenetet kapok az archlinux-ban, amikor megadom a start szolgáltatást, státuszt adok neki, és ez kiderül:
sudo systemctl állapot fail2ban
● fail2ban.service - Fail2Ban szolgáltatás
Betöltve: betöltve (/usr/lib/systemd/system/fail2ban.service; engedélyezve; szállítói előre beállított: letiltva)
Aktív: sikertelen (Eredmény: start-limit) 2015-03-20 péntek óta 01:10:01 CLST; 1 másodperccel ezelőtt
Dokumentumok: man: fail2ban (1)
Folyamat: 1695 ExecStart = / usr / bin / fail2ban-client -x start (kód = kilépett, állapot = 255)
20. március 01:10:01 Gundam systemd [1]: Nem sikerült elindítani a Fail2Ban szolgáltatást.
20. március 01:10:01 Gundam systemd [1]: Az egység fail2ban.service hibás állapotba lépett.
20. március 01:10:01 Gundam systemd [1]: fail2ban.service sikertelen.
20. március 01:10:01 Gundam systemd [1]: az indítási kérés túl gyorsan megismétlődik a fail2ban… ice esetén
20. március 01:10:01 Gundam systemd [1]: Nem sikerült elindítani a Fail2Ban szolgáltatást.
20. március 01:10:01 Gundam systemd [1]: Az egység fail2ban.service hibás állapotba lépett.
20. március 01:10:01 Gundam systemd [1]: fail2ban.service sikertelen.
Tipp: Néhány sor ellipszis volt, a -XNUMX jelzéssel teljes megjelenítéshez.
segítség? D:
Üdvözlet! Ha engedélyezte a fail2ban funkciót a systemctl engedélyezésével a fail2ban.service és a systemctl start fail2ban.service szolgáltatással, akkor a probléma a börtönök konfigurációjában lesz. Kérjük, ellenőrizze börtönét és ellenőrizze, hogy minden rendben van-e.
Az üdvözlő
cseh Péter
Először is jó bemutató. Sok minden hiányzik, de az alapokra koncentráltál.
shini-kire, ellenőrizze a /var/log/fail2ban.log fájlt
Üdvözlet.
Köszönöm @Maykel Franco :).
Jó,
fail2ban kellene telepíteni egy otthoni pc-re vagy inkább a szerverekre ???
Köszönöm.
Inkább a szerverekhez, de ha olyan wifi-n van, ahol többen vannak, mint te, akkor jó ...
Helló barátom, azt hiszem, ez egy jó biztonsági bejegyzés a Gnu / Linux disztribúcióiban bekövetkezett rövid tűzeset során. Azért írom ezt a megjegyzést, mert egy Ubuntu 14.04 terjesztésben teszem, tudván, hogy már 15.04-ben van, ami történik a következő problémát adom meg: nano /etc/fail2ban/jail.local root-ként, és nincs megjelenítésem az sshd részben, és elmentem. Az [DEFAULT] nevű részben nem kommentáljuk és módosítjuk #bantime = 3600 és
Az [sshd] részben bemutatjuk az enable = true lehetőséget, így hagyjuk:
# engedélyezve = igaz
engedélyezve = igaz
Nem úgy tűnik, hogy az sshd lehet, mert köszönöm, hogy az előző verziót dolgozom