Phenquestions
Az SSH-kiszolgáló biztonságának mértéke az alapszinttől a haladóig terjed, és mint korábban említettük, felveheti azokat a szükséges biztonsági szintnek megfelelően. Kihagyhatja az előírt intézkedések bármelyikét, ha megfelelő ismeretekkel rendelkezik a következményekről, és ha megfelelő helyzetben van azokkal szemben. Azt sem mondhatjuk, hogy egyetlen lépés biztosítja a 100% -os biztonságot, vagy egy bizonyos lépés jobb, mint a másik.
Minden attól függ, hogy milyen típusú biztonságra van szükségünk valójában. Ezért ma nagyon mély betekintést kívánunk nyújtani az SSH-kiszolgáló biztonságának alapvető és haladó lépéseibe az Ubuntu 20-ban.04. Ezen módszerek mellett néhány további tippet is megosztunk Önnel az SSH-kiszolgáló bónuszként történő védelméről. Kezdjük tehát a mai érdekes beszélgetéssel.
Az SSH-kiszolgáló biztonságának módja az Ubuntu 20-ban.04:
Az összes SSH-konfigurációt az / etc / ssh / sshd_config fájlban tárolja. Ezt a fájlt nagyon fontosnak tartják az SSH-kiszolgáló normális működése szempontjából. Ezért a fájl bármilyen módosítása előtt javasoljuk, hogy készítsen biztonsági másolatot a fájlról a következő parancs futtatásával a terminálon:
sudo cp / etc / ssh / sshd_config / etc / ssh / sshd_config.bak
Ha ezt a parancsot sikeresen végrehajtják, akkor nem jelenik meg semmilyen kimenet, amint az az alábbi képen látható:
A fájl biztonsági másolatának létrehozása után ez a lépés opcionális, és akkor hajtódik végre, ha meg szeretné ellenőrizni a konfigurációs fájlban jelenleg engedélyezett összes beállítást. A következő parancs futtatásával ellenőrizheti a terminálon:
Az SSH konfigurációs fájl jelenleg engedélyezett beállításai az alábbi képen láthatók. Az összes lehetőség megtekintéséhez görgessen lefelé ebben a listában.
Most megkezdheti az SSH-kiszolgáló biztonságának biztonságát, miközben az Ubuntu 20 alapvető lépéseiről halad a haladó lépésekre.04.
Az SSH-kiszolgáló biztonságának alapvető lépései az Ubuntu 20-ban.04:
Az SSH-kiszolgáló biztonságának alapvető lépései az Ubuntu 20-ban.04 a következők:
1. lépés: Az SSH konfigurációs fájl megnyitása:
Az SSH konfigurációs fájlt az terminálon alább megadott parancs futtatásával nyithatja meg:
sudo nano / etc / ssh / sshd_config
Az SSH konfigurációs fájl a következő képen látható:
2. lépés: A jelszó alapú hitelesítés letiltása:
Ahelyett, hogy jelszavakat használna hitelesítéshez, az SSH kulcsokat biztonságosabbnak tekintik. Ezért, ha az SSH kulcsokat generálta a hitelesítéshez, akkor le kell tiltania a jelszó alapú hitelesítést. Ehhez meg kell keresnie a „PasswordAuthentication” változót, törölni kell a megjegyzést, és „nem” értékre kell állítania, amint azt az alábbi kép kiemeli:
3. lépés: Az üres jelszavak elutasítása / megtagadása:
Időnként a felhasználók rendkívül kényelmesek üres jelszavakat létrehozni, hogy megmentsék magukat az összetett jelszavak memorizálásától. Ez a gyakorlat károsnak bizonyulhat az SSH-kiszolgáló biztonságára. Ezért el kell utasítania az összes hitelesítési kísérletet üres jelszavakkal. Ehhez meg kell keresnie a „PermitEmptyPasswords” változót, és csak törölni kell a megjegyzést, mivel az értéke alapértelmezés szerint már „nem”, amint azt a következő kép kiemeli:
4. lépés: A root bejelentkezés tiltása:
Szigorúan meg kell tiltania a gyökér bejelentkezést annak megakadályozása érdekében, hogy a behatolók gyökérszintű hozzáférést kapjanak a szerverhez. Ezt úgy teheti meg, hogy megtalálja a „PermitRootLogin” változót, törölje a megjegyzést, és állítsa „nem” értékre, amint az az alábbi képen látható:
5. lépés: Az SSH 2. protokoll használata:
Az SSH szerver két különböző protokollon működhet, azaz.e., 1. és 2. jegyzőkönyv. A 2. protokoll fejlettebb biztonsági szolgáltatásokat valósít meg, ezért előnyben részesíti az 1. protokollal szemben. Az 1. protokoll azonban az SSH alapértelmezett protokollja, és ezt nem említi kifejezetten az SSH konfigurációs fájl. Ezért, ha az 1. protokoll helyett a 2. protokollal szeretne dolgozni, akkor kifejezetten hozzá kell adnia a „2. protokoll” sort az SSH konfigurációs fájljához, amint azt a következő kép kiemeli:
6. lépés: Munkamenet időkorlátjának beállítása:
Időnként a felhasználók nagyon sokáig felügyelet nélkül hagyják számítógépüket. Eközben bármely betolakodó átjöhet, és hozzáférhet a rendszeréhez, miközben sérti annak biztonságát. Itt lép életbe a session timeout koncepciója. Ezt a funkciót a felhasználó kijelentkezéséhez használják, ha sokáig inaktív marad, így egyetlen felhasználó sem férhet hozzá a rendszeréhez.
Ezt az időtúllépést úgy állíthatjuk be, hogy megkeresjük az „ClientAliveInterval” változót, töröljük a megjegyzést és hozzáadunk tetszőleges értéket (másodpercben). Esetünkben „300 másodperc” vagy „5 perc” értéket rendeltünk hozzá. Ez azt jelenti, hogy ha a felhasználó „300 másodpercre” marad távol az SSH szervertől, akkor automatikusan kijelentkezik az alább látható képen kiemelve:
7. lépés: Bizonyos felhasználók hozzáférésének engedélyezése az SSH-kiszolgálóhoz:
Az SSH-kiszolgáló nem olyan szerver, amelynek hozzáférését minden más felhasználó megköveteli. Ezért hozzáférését csak azokra a felhasználókra lehet korlátozni, akiknek valóban szüksége van rá. Ahhoz, hogy bizonyos felhasználók hozzáférhessenek az SSH-kiszolgálóhoz, hozzá kell adni egy „AllowUsers” nevű változót az SSH-konfigurációs fájlhoz, majd meg kell írni azoknak a felhasználóknak a nevét, akiknek teret kell választaniuk az SSH-kiszolgálóhoz. Esetünkben csak egy felhasználót akartunk engedélyezni az SSH-kiszolgálóhoz. Ezért csak a nevét adtuk hozzá, amint azt a következő kép kiemeli:
8. lépés: A hitelesítési kísérletek számának korlátozása:
Amikor egy felhasználó megpróbál hozzáférni egy szerverhez, és nem tudja először hitelesíteni magát, megpróbálja újra megtenni. A felhasználó mindaddig folytatja ezeket a kísérleteket, amíg sikeresen nem tudja hitelesíteni magát, így hozzáférést kap az SSH-kiszolgálóhoz. Ez nagyon bizonytalan gyakorlatnak számít, mivel egy hacker elindíthat egy Brute Force Attack-et (egy olyan támadást, amely többször is megpróbálja kitalálni a jelszót, amíg a megfelelő mérkőzést megtalálja). Ennek eredményeként hozzáférhet az SSH-kiszolgálóhoz.
Ezért erősen ajánlott korlátozni a hitelesítési kísérletek számát a jelszó kitaláló támadások megelőzése érdekében. Az SSH szerver hitelesítési kísérleteinek alapértelmezett értéke „6”. Megváltoztathatja azonban a kívánt biztonsági szinttől függően. Ehhez meg kell keresse a „MaxAuthTries” változókat, törölje a megjegyzést, és állítsa be az értékét bármely kívánt számra. A hitelesítési kísérleteket „3” -ra akartuk korlátozni, amint azt az alábbi kép kiemeli:
9. lépés: Az SSH-kiszolgáló futtatása teszt módban:
Mostanra megtettük az összes alapvető lépést az SSH-kiszolgáló biztonságossá tételére az Ubuntu 20-on.04. Azonban még mindig meg kell győződnünk arról, hogy az imént konfigurált opciók megfelelően működnek-e. Ehhez először elmentjük és bezárjuk a konfigurációs fájlt. Ezt követően megpróbáljuk teszt módban futtatni az SSH-kiszolgálónkat. Ha teszt módban sikeresen fut, akkor ez azt jelenti, hogy a konfigurációs fájlban nincsenek hibák. Az alábbi parancs futtatásával futtathatja SSH-kiszolgálóját teszt módban:
sudo sshd -t
A parancs sikeres végrehajtása után nem jelenít meg kimenetet a terminálon, amint az az alábbi képen látható. Ha azonban hibát észlel a konfigurációs fájlban, akkor a parancs futtatásával ezek a hibák a terminálon jelennek meg. Ezután javítania kell ezeket a hibákat. Csak ezután lesz képes továbblépni.
10. lépés: Az SSH-kiszolgáló újratöltése új konfigurációkkal:
Most, amikor az SSH szerver sikeresen futott teszt módban, újra kell töltenünk, hogy el tudja olvasni az új konfigurációs fájlt, azaz.e., az SSH konfigurációs fájlban a fenti lépésekben végrehajtott változtatások. Az SSH-kiszolgáló új konfigurációkkal történő újratöltéséhez a következő parancsot kell futtatnia a terminálon:
sudo service sshd reload
Ha az SSH szerver sikeresen újraindul, a terminál nem jelenít meg kimenetet, amint az az alábbi képen látható:
Haladó lépések az SSH-kiszolgáló biztonságához az Ubuntu 20-ban.04:
Miután elvégezte az SSH-kiszolgáló biztonságának minden alapvető lépését az Ubuntu 20-ban.04, végre folytathatja a haladó lépéseket. Ez csak egy lépés az SSH-kiszolgáló biztonságának megőrzéséhez. Ha azonban csak mérsékelt szintű biztonságot kíván elérni, akkor a fent leírt lépések elegendőek lesznek. De ha kicsit messzebbre akarsz jutni, akkor kövesd az alábbiakban ismertetett lépéseket:
1. lépés: A ~ / megnyitása.ssh / Authorized_keys fájl:
Az SSH szerver biztonságának alapvető lépéseit az SSH konfigurációs fájl tartalmazza. Ez azt jelenti, hogy ezek a házirendek minden felhasználó számára megfelelőek lesznek, akik megpróbálnak hozzáférni az SSH-kiszolgálóhoz. Ez azt is jelenti, hogy az alapvető lépések az SSH-kiszolgáló biztonságának általános módszerét jelentik. Ha azonban megpróbáljuk figyelembe venni a „Defence in Depth” elvét, akkor rájövünk, hogy minden egyes SSH-kulcsot külön kell rögzítenünk. Ezt úgy tehetjük meg, hogy minden egyes kulcshoz meghatározunk explicit biztonsági paramétereket. Az SSH kulcsokat a ~ /.ssh / authorised_keys fájlt, ezért először hozzáférünk ehhez a fájlhoz a biztonsági paraméterek módosításához. A következő parancsot futtatjuk a terminálban a ~ / eléréséhez.ssh / Authorized_keys fájl:
sudo nano ~ /.ssh / engedéllyel_kulcsokA parancs futtatásával megnyílik a megadott fájl a nano szerkesztővel. Ennek a fájlnak a megnyitásához azonban tetszőleges más szövegszerkesztőt is használhat. Ez a fájl tartalmazza az összes SSH-kulcsot, amelyet eddig generált.
2. lépés: Specifikus konfigurációk meghatározása adott kulcsokhoz:
A magas szintű biztonság eléréséhez a következő öt lehetőség áll rendelkezésre:
- ügynök nélküli továbbítás
- port nélküli továbbítás
- no-pty
- no-user-rc
- no-X11-forwarding
Ezeket az opciókat bármelyik általad választott SSH-kulcs előtt fel lehet írni, hogy elérhetővé váljanak az adott kulcshoz. Még egynél több opció is konfigurálható egyetlen SSH-kulcshoz. Például letiltja a portátirányítást bármely adott kulcsnál, vagy más szavakkal, a port nélküli továbbítást kíván végrehajtani egy adott kulcshoz, akkor a szintaxis a következő lesz:
port nélküli továbbítás DesiredSSHKeyItt a DesiredSSHKey helyett egy tényleges SSH kulcs lesz a ~ /.ssh / Authorized_keys fájl. Miután ezeket az opciókat alkalmazta a kívánt SSH kulcsokhoz, el kell mentenie a ~ /.ssh / authorised_keys fájlt, és zárja be. Jó ebben a speciális módszerben, hogy nem szükséges az SSH-kiszolgáló újratöltése a módosítások elvégzése után. Inkább ezeket a változásokat az SSH-kiszolgáló automatikusan elolvassa.
Így a fejlett biztonsági mechanizmusok alkalmazásával minden egyes SSH-kulcsot alaposan rögzíthet.
Néhány további tipp az SSH-kiszolgáló biztonságához az Ubuntu 20-ban.04:
A fenti alapvető és haladó lépéseken kívül van néhány további tipp is, amelyek nagyon jónak bizonyulhatnak az SSH-kiszolgáló biztonságában az Ubuntu 20-ban.04. Ezeket a további tippeket az alábbiakban tárgyaltuk:
Tartsa titkosított adatait:
Az SSH-kiszolgálón található adatokat, valamint azokat, amelyeket továbbra is szállítanak, titkosítani kell, és ezeket is erős titkosítási algoritmussal. Ez nemcsak az adatok integritását és titkosságát védi, hanem megakadályozza az egész SSH-kiszolgáló biztonságának veszélyeztetését.
Tartsa naprakészen a szoftvert:
Az SSH-kiszolgálón futó szoftvernek naprakésznek kell lennie. Ez annak biztosítására szolgál, hogy a szoftverében egyetlen biztonsági hiba sem maradjon felügyelet nélkül. Inkább időben kell őket jól foltozni. Ez hosszú távon megmenti az esetleges károktól, és megakadályozza a szerver leállását vagy biztonsági problémák miatt nem elérhető.
Győződjön meg arról, hogy a SELinux engedélyezve van:
A SELinux az a mechanizmus, amely a Linux alapú rendszerek biztonságának alapkövét rakja le. A kötelező hozzáférés-vezérlés (MAC) megvalósításával működik. Ezt a hozzáférés-ellenőrzési modellt úgy hajtja végre, hogy biztonsági szabályzatában meghatározza a hozzáférési szabályokat. Ez a mechanizmus alapértelmezés szerint engedélyezve van. A felhasználók azonban bármikor megváltoztathatják ezt a beállítást. Ez azt jelenti, hogy bármikor letilthatják a SELinuxot. Mindazonáltal erősen ajánlott, hogy mindig tartsa bekapcsolva a SELinux programot, hogy ez megakadályozza az SSH-kiszolgálót az összes lehetséges kárban.
Szigorú jelszószabályok használata:
Ha jelszavakkal védte SSH-kiszolgálóját, akkor erős jelszószabályzatot kell létrehoznia. Ideális esetben a jelszavaknak 8 karakternél hosszabbaknak kell lenniük. Meg kell változtatni egy meghatározott idő után, mondjuk 2 havonta. Nem tartalmazhatnak szótári szavakat; inkább ábécék, számok és speciális karakterek kombinációjának kell lenniük. Hasonlóképpen megadhat további szigorú intézkedéseket is a jelszó-házirendekhez annak biztosítására, hogy azok elég erősek legyenek.
Az SSH-kiszolgáló naplóinak figyelése és karbantartása:
Ha bármi baj történik az SSH-kiszolgálóval, akkor az első segítője lehet az ellenőrzési naplók. Ezért fenn kell tartania ezeket a naplókat, hogy visszavezethesse a probléma kiváltó okát. Sőt, ha folyamatosan figyelemmel kíséri az SSH-kiszolgáló állapotát és működését, akkor ez is megakadályozza, hogy minden fontosabb probléma eleve felmerüljön.
Az adatok rendszeres biztonsági mentésének fenntartása:
Végül, de nem utolsósorban mindig tartson biztonsági másolatot a teljes SSH szerverről. Ezzel nemcsak megmenti adatait a sérülésektől vagy teljes elveszéstől; inkább ezt a biztonsági szervert is használhatja, amikor a fő szerver leáll. Ez a szerver leállását is korlátozza, és biztosítja annak elérhetőségét.
Következtetés:
A cikkben előírt összes intézkedés végrehajtásával könnyen biztonságossá teheti vagy megkeményítheti SSH-kiszolgálóját az Ubuntu 20-ban.04. Ha azonban információbiztonsági háttérrel rendelkezik, akkor tisztában kell lennie ezzel a ténnyel, hogy nincs semmi hasonló a 100% -os biztonsághoz. Csak annyit kaphatunk, hogy a legjobb erőfeszítést ígérjük, és ez a legjobb erőfeszítés csak addig lesz biztonságban, amíg meg nem ütik azt is. Ezért még ezen intézkedések megtétele után sem mondhatja el, hogy az SSH-kiszolgálója 100% -osan biztonságos; inkább még mindig vannak olyan sérülékenységei, amelyekre eszedbe sem jutott volna. Az ilyen biztonsági résekről csak akkor lehet gondoskodni, ha élénk figyelemmel kísérjük az SSH-kiszolgálónkat és folyamatosan frissítjük, amikor arra szükség van.
