Nos, erre a bejegyzésre készültem a blogom egy ideig azt javasolták nekem DesdeLinux, és időhiány miatt nem volt képes vagy hajlandó. Ha kissé lusta vagyok ????. De most sztrájkolnak, ahogy Kubában mondjuk ...
0- Tartsa rendszerünket naprakészen a legújabb biztonsági frissítésekkel.
0.1- Kritikus frissítések Levelezőlisták [Slackware biztonsági tanácsadó, Debian biztonsági tanácsadó, esetemben]
1- Nulla fizikai hozzáférés a szerverekhez illetéktelen személyzet által.
1.1- Jelszó alkalmazása a következőre: BIOS szervereink közül
1.2- Nincs indítás CD / DVD-vel
1.3- Jelszó GRUB / Lilo-ban
2- Jó jelszó irányelv, alfanumerikus karakterek és mások.
2.1- A jelszavak elöregedése [Password Aging] a „chage” paranccsal, valamint a jelszó megváltoztatása és az utolsó változtatás dátuma közötti napok száma.
2.2- Kerülje a korábbi jelszavak használatát:
az /etc/pam.d/common-password fájlban
password sufficient pam_unix.so use_auth ok md5 shadow remember 10
Így változtatja meg a jelszót, és emlékeztet a felhasználó utolsó 10 jelszavára.
3- Hálózatunk [útválasztók, kapcsolók, vlans] és tűzfal jó kezelési / szegmentálási politikája, valamint az INPUT, OUTPUT, FORWARD [NAT, SNAT, DNAT] szűrési szabályok
4- Engedélyezze a héjak használatát [/ etc / shells]. Azoknak a felhasználóknak, akiknek nem kell bejelentkezniük a rendszerbe, a / bin / false vagy a / bin / nologin kapnak.
5- Blokkolja a felhasználókat, ha a bejelentkezés sikertelen [faillog], valamint ellenőrizze a rendszer felhasználói fiókját.
passwd -l pepe -> felhasználói pepe letiltása passwd -v pepe -> felhasználói pepe blokkolásának feloldása
6- Engedélyezze a "sudo" használatát, SOHA ne jelentkezzen be gyökérként az ssh, "SOHA" segítségével. Valójában szerkesztenie kell az ssh konfigurációt ennek elérése érdekében. Használjon nyilvános / privát kulcsokat a szerverein a sudo segítségével.
7- Alkalmazza rendszereinkben a „A legkevesebb kiváltság elve".
8- Időnként ellenőrizze szolgáltatásainkat [netstat -lptun], mindegyik szerverünkhöz. Adjon hozzá olyan felügyeleti eszközöket, amelyek segítségünkre lehetnek ebben a feladatban [Nagios, Cacti, Munin, Monit, Ntop, Zabbix].
9- Telepítsen IDS-eket, Snort / AcidBase, Snotby, Barnyard, OSSEC.
10- Az Nmap a barátod, használd az alhálózat / alhálózatok ellenőrzésére.
11- Jó biztonsági gyakorlatok az OpenSSH, az Apache2, az Nginx, a MySQL, a PostgreSQL, a Postfix, a Squid, a Samba, az LDAP [a legtöbbet használt] és más, a hálózatban szükséges szolgáltatások terén.
12- Titkosítson minden kommunikációt, amíg lehetséges a rendszereinkben, SSL, gnuTLS, StarTTLS, emésztés stb. ... És ha bizalmas információkat kezel, titkosítsa a merevlemezt !!!
13- Frissítse levelezőszervereinket a legújabb biztonsági, feketelista- és spamellenes szabályokkal.
14- Aktivitásnaplózás a rendszereinkben naplózással és naplózással.
15- Többek között olyan eszközök ismerete és használata, mint a top, sar, vmstat, free.
sar -> rendszeraktivitási jelentés vmstat -> folyamatok, memória, rendszer, i / o, cpu tevékenység stb. iostat -> cpu i / o állapot mpstat -> többprocesszoros állapot és használati pmap -> memóriahasználat szabad folyamatok által - > iptraf memória -> hálózati státuszunk valós idejű forgalma -> konzol alapú ethernet statisztikai monitor etherape -> grafikus hálózati monitor ss -> socket állapot [tcp socket info, udp, raw sockets, DCCP Sockets] tcpdump -> Részletes elemzés de traffic vnstat -> kiválasztott interfészek hálózati forgalomfigyelője mtr -> diagnosztikai eszköz és a túlterhelés elemzése a hálózatokban ethtool -> statisztikák a hálózati kártyákról
Egyelőre minden. Tudom, hogy ezer és még egy biztonsági javaslat létezik az ilyen típusú környezetben, de ezek azok, amelyek a legjobban megdöbbentettek, vagy hogy valamikor az általam alkalmazott környezetben kellett alkalmaznom / gyakorolnom.
Egy ölelés, és remélem, hogy szolgál téged 😀
Felhívlak benneteket a megjegyzésekben, hogy meséljetek néhány más, a már említetteken kívül végrehajtott szabályról, hogy bővítsük olvasóink ismereteit 😀
Nos, hozzátenném:
1.- Alkalmazzon sysctl szabályokat a dmesg, / proc, SysRQ hozzáférés megakadályozásához, rendelje hozzá a PID1-et a maghoz, engedélyezze a védelmet a kemény és lágy szimpla linkeknél, a TCP / IP-kötegek védelmét mind az IPv4, mind az IPv6 esetében, aktiválja a teljes VDSO-t a legnagyobb véletlenszerűség érdekében mutatókat és memóriaterület-allokációkat, és javítja a puffertúlcsordulásokkal szembeni erőt.
2.- Hozzon létre SPI (Stateful Package Inspect) típusú tűzfalakat, hogy megakadályozza a nem létrehozott vagy korábban engedélyezett kapcsolatok hozzáférését a rendszerhez.
3.- Ha nincs olyan szolgáltatása, amely távoli helyről megköveteli a megnövelt jogosultságú kapcsolatokat, egyszerűen vonja vissza a hozzáférést hozzájuk az access.conf használatával, vagy ennek hiányában engedélyezze a hozzáférést csak egy adott felhasználóhoz vagy csoporthoz.
4.- Használjon kemény korlátokat annak megakadályozására, hogy bizonyos csoportokhoz vagy felhasználókhoz való hozzáférés destabilizálja a rendszerét. Nagyon hasznos olyan környezetekben, ahol valódi többfelhasználós ember van aktív.
5.- A TCPWrappers a barátod, ha olyan rendszeren vagy, amely támogatja azt, akkor annak használata nem ártana, így megtagadhatod a hozzáférést bármelyik gazdagéptől, kivéve, ha azt korábban konfigurálták a rendszerben.
6.- Hozzon létre legalább 2048 vagy 4096 bites SSH RSA kulcsokat 16 karaktert meghaladó alfanumerikus kulcsokkal.
7.- Mennyire írható világszerte? A könyvtárak olvasási és írási engedélyeinek ellenőrzése egyáltalán nem rossz, és ez a legjobb módszer az illetéktelen hozzáférés elkerülésére a többfelhasználós környezetben, arról nem is beszélve, hogy egyes illetéktelen hozzáférések megnehezítik az olyan információkhoz való hozzáférést, amelyekre Ön nem akar. senki más nem látja.
8.- Csatlakoztasson minden olyan külső partíciót, amely nem érdemli meg, a noexec, nosuid, nodev opciókkal.
9.- Használjon olyan eszközöket, mint az rkhunter és a chkrootkit, hogy rendszeresen ellenőrizze, hogy a rendszerben nincs-e telepítve rootkit vagy rosszindulatú program. Óvatos intézkedés, ha Ön egyike azoknak, akik nem biztonságos adattárakból, PPA-kból telepítenek dolgokat, vagy egyszerűen nem megbízható helyekről fordítanak élő kódokat.
Ööö, finom ... Jó megjegyzés, adj hozzá srácokat ... 😀
Kötelező beléptető ellenőrzést alkalmazni a SElinux-szal?
nagyon jó cikk
Köszönöm barátom 😀
Helló, és ha normál felhasználó vagyok, használjam a su vagy a sudo programokat?
A su-t azért használom, mert nem szeretem a sudo-t, mert bárki, akinek megvan a felhasználói jelszavam, bármit megváltoztathat a rendszeren, helyette a su no-val.
A PC-n nem zavarja a su használatát, problémamentesen használhatja, a szervereken, nagyon ajánlott letiltani a su használatát és használni a sudo-t, sokak szerint ez annak a ténynek köszönhető, hogy auditálta, ki milyen parancsot hajtott végre, a sudo pedig ezt a feladatot ... az a sajátos, hogy a számítógépemen az övét használom, akárcsak te ...
Persze, nem igazán tudom, hogyan működik a szervereken. Bár számomra úgy tűnik, hogy a sudo előnye volt, hogy kiváltságokat adhat egy másik számítógép felhasználójának, ha nem tévedek.
Érdekes cikk, néhány fájlt a gnu-gpg-vel titkosítok, csakúgy, mint a minimális jogosultsággal, ha például egy ismeretlen eredetű bináris fájlt akarsz végrehajtani, amely elveszett a lemez hatalmas információs terein, hogyan távolíthatom el bizonyos funkciókhoz való hozzáférést ?
Tartozom neked ennek a résznek, bár úgy gondolom, hogy csak sudo / root programként kell futtatnod, olyan programokat, amelyek megbízhatóak, vagyis a repódból származnak ...
Emlékszem arra, hogy olvastam, hogy van mód a root képességek engedélyezésére a GNU / Linux és a UNIX kézikönyvében, ha megtalálom, felteszem 😀
@andrew itt az általam említett cikk és még néhány segítség
http://www.cis.syr.edu/~wedu/seed/Labs/Capability_Exploration/Capability_Exploration.pdf
http://linux.die.net/man/7/capabilities
https://wiki.archlinux.org/index.php/Capabilities
és a chown ketrecek ismeretlen binárisok futtatására?
A sudo mindenkori használata sokkal jobb.
Vagy használhatja a sudo-t, de korlátozhatja a jelszó emlékezésének idejét.
Hasonló eszközöket használok a pc monitorozására, az "iotop" helyett az "iostat", a "htop" kiváló "feladatkezelő", az "iftop" sávszélesség-figyelés.
sokan azt gondolják, hogy ez eltúlzott, de már láttam olyan támadásokat, amelyek szervert tartalmaznak egy botnethez.
https://twitter.com/monitolinux/status/594235592260636672/photo/1
ps: kínai koldusok és kísérleteik feltörni a szerveremet.
Az is kényelmes, ha chown ketreceket használunk a szolgáltatásokhoz, így ha valamilyen okból megtámadják őket, akkor nem veszélyeztetik a rendszert.
A ps parancs használata kiválóan alkalmas figyelésre is, és része lehet a biztonsági hibák ellenőrzésének. A ps -ef futtatása felsorolja az összes folyamatot, hasonló a tetejéhez, azonban mutat némi különbséget. Az iptraf telepítése egy másik eszköz, amely működhet.
Jó hozzájárulás.
Hozzátenném: a SELinux vagy az Apparmor, a terjesztéstől függően, mindig engedélyezve van.
Saját tapasztalatom alapján rájöttem, hogy rossz gyakorlat letiltani ezeket az összetevőket. Szinte mindig akkor csináljuk, amikor telepítünk vagy konfigurálunk egy szolgáltatást, azzal az ürüggyel, hogy az problémamentesen fut, amikor valójában azt kell megtanulnunk, hogy megtanuljuk kezelni őket a szolgáltatás engedélyezése érdekében.
A köszöntés.
1. Hogyan lehet titkosítani a teljes fájlrendszert? megéri??
2. Meg kell visszafejteni minden alkalommal, amikor a rendszert frissíteni fogják?
3. A gép teljes fájlrendszerének titkosítása megegyezik-e más fájlok titkosításával?
Honnan tudod, hogy tudod, miről beszélsz?
Ezenkívül ketrecbe helyezheti a programokat és akár több felhasználót is. Bár ez több munka, de ha történt valami, és volt egy korábbi példánya abból a mappából, az csak üt és énekel.
A legjobb és legkényelmesebb biztonsági politika nem paranoiás.
Próbálja ki, ez tévedhetetlen.
Csf-t használok, és amikor feloldok egy ügyfelet, aki valamilyen hozzáférésnél rosszul helyezte el a jelszavát, az késlelteti a folyamatot, de mégis. Ez normális?
Azt a parancsot keresem, hogy feloldjam az ssh-t ... bármilyen javaslat