-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
urandom0
senior tag
Megjelent a Fedora 40: https://fedoraproject.org/
Mondjuk vasárnapig várhattak volna vele
[kép] -
urandom0
senior tag
És mi a garancia arra, hogy run0-ban nem fognak exploitokat találni? Pláne úgy, hogy ez a run0 az egész PAM mechanizmust meg a polkitet berántja maga alá, és amúgy systemd-run alapon megy, ami mögött meg ott az egész systemd. Lehet, hogy a run0 kódja 5 sor, de ott van mögött az egész systemd a 8000 soros kódjával, meg a pkexec, a polkit, meg a PAM...
Egyébként a sudo legtöbb sebezhetősége ilyen snassz buffer overflow és hasonlók voltak, ilyesmik ellen meg nem véd a systemd sem (főleg, hogy azt is C-ben írták).
A SUID/GUID koncepció lehet, hogy rossz, de erre vannak módszerek a különféle LSM-ek képében, mint pl. a SELinux és az AppArmor.
-
urandom0
senior tag
A sudo teljesen jól el van PAM és polkit nélkül is, aki akarja, mindkettőt kiírthatja alóla.
"Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik."
Nem, azért használják, mert a Debian átvette, és miután az iparban a Linuxos közösség kb. 90%-a vagy Debian, vagy RHEL alapú disztrót használ, ezért a többi kis disztró gyakorlatilag kénytelen volt adoptálni, mivel nálunk nincs erőforrás arra, hogy külön utakon járjanak.
Van egy rakat sudo alternatíva amúgy.
-
urandom0
senior tag
Egy szimpla ASCII fájl olvasásához bármilyen text editor jó, ami kéznél van. Nano, pico, joe, emacs, vi, vim, nvim, akármi. A journalt legfeljebb a journalctl-el tudod olvasni.
Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.
Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani. Vagy ha maga a journald crashel, cseszheted a logokat. Vagy ha egy szép napon Poettering azt mondja, hogy bocsi, most megváltoztattuk a journalctl-t, nem kompatibilis a régi logokkal...
-
urandom0
senior tag
Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?
Igen, láttam ilyet, volt hogy leakadt a SAN, és kb. két és fél órás művelet volt csak az, míg sikerült bebootoltatni a rendszert. Onnantól fogva, vagy vissza tudod varázsolni a journalt, vagy nem, és sok esetben sajnos nem. De amikor a
journalctl --verify
is csak annyit tud mondani, hogy "invalid argument", na akkor tudod, hogy hosszú napod lesz. -
urandom0
senior tag
Bare metalon jellemzően csak a host(ot) fut(nak), minden más a vm diszkjén van.
-
urandom0
senior tag
Másnál is vannak problémák a Fedora 40-nel, vagy csak én vagyok ilyen szerencsecsomag?
Az asztali gépemen tegnap alap dolgok nem működtek, pl. nem tudtam egy fájlkezelőt elindítani, de még csak sudozni se tudtam, az xfdesktop nem indult el, két nm-applet ikon volt a panelen, de az egyik nem reagált semmire, stb. Bebootoltam a 39-es kernelével, akkor minden jó volt. Volt vagy 900 MB-nyi update, azt feltoltam, azóta jónak tűnik.Most a laptopon csinálja ugyanezt. A fájlkezelő nem akar elindulni, sudozni tudok, de nagyon lassan dobja be a promptot, mint ha valami hálózati kapcsolatra várna. A raspberry egyik sftp meghajtója van felcsatolva, de hát az eddig is fel volt, és sosem volt vele probléma. Most itt is van 660 MB-nyi update, meglátjuk, ez megjavítja-e.
-
urandom0
senior tag
válasz urandom0 #34117 üzenetére
Most, hogy frissítettem Fedora 40-re (nem szoktam elkapkodni...), jött néhány új service is. Ilyenkor mindig meg szoktam nézni, hogy melyik mit csinál, hogy tudjam, ha esetleg nincs szükségem valamelyikre. Most pl. ilyenek vannak:
dracut-shutdown.service - This service unpacks the initramfs image to /run/initramfs. systemd pivots into /run/initramfs at shutdown, so the root filesystem can be safely unmounted.
livesys-late.service - loaded active exited SYSV: Late init script for live image.
livesys.service - loaded active exited LSB: Init script for live image.
mcelog.service - mcelog logs and accounts machine checks (in particular memory, IO, and CPU hardware errors) on modern x86 Linux systems.
pcscd.service - The pcscd daemon is used to manage connections to PC and SC smart card readers.
low-memory-monitor.service - The Low Memory Monitor is an early boot daemon that will monitor memory pressure information coming from the kernel, and, first, send a signal to user-space applications when memory is running low, and then activate the kernel's OOM killer when memory is running really low.
plymouth-quit-wait.service - Hold until boot process finishes up
plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data
plymouth-start.service - Show Plymouth Boot Screen
rpc-statd-notify.service - Notify NFS peers of a restart
systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully
systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service - Create Volatile Files and Directories
sssd-kcm.service - SSSD Kerberos Cache ManagerEgy kicsit viccesnek találom, hogy most már 3 plymouth service is van, van 3 tmpfiles service, és hogy van külön low memory service, ami azért van, hogy beindítsa a tényleges OOM killert.
-
urandom0
senior tag
válasz Archttila #34119 üzenetére
Néztem, igazából a systemd-tmpfiles-setup* serivce-ek ugyanúgy a systemd-tmpfiles-t hívják meg, csak más paraméterekkel. Konkrétan a systemd-tmpfiles-setup-dev és a systemd-tmpfiles-setup-dev-early között annyi a különbség, hogy a másodiknál van egy --graceful paraméter is.
A plymouth service-nék megint csak szinte ugyanez, a háromból kettő a /usr/bin/plymouth-ot hívja más-más paraméterezéssel, míg a harmadik a /usr/sbin/plymouthd-t, de ExecPost-nak ott is be van írva a /usr/bin/plymouth.
Végső soron nem probléma, hogy ennyi service van, de majd csinálok egy tiszta telepítést, és megnézem, hogy ott mik vannak. -
urandom0
senior tag
Én a védelmet még kiegészíteném annyival, hogy:
- SSH-hoz publikus kulcs alapú ÉS jelszavas védelmet állíts be
- a root belépést tiltsd, és explicit ad meg, kik léphetnek be (AllowUsers)
- ne RSA kulcsot használj, hanem ed25519-et
- nem baj, ha használod az openscap-scanner-t (RHEL-en oscap néven fut)
- auditd-ot már írták, azt én is tudom javasolni (https://sematext.com/glossary/auditd/)
- rendszeresen nézegesd a cron logjait, a tmp mappa tartalmát, journald-ban az SSH belépések forrását, időpontjait, ha bármiben bármi gyanúsat látsz, azonnal derítsd fel
- csinálhatsz ún. geofence-t is, ez azt jelenti, hogy rendszeresen (naponta 1x) lehúzod az országokhoz tartozó IP címek listáját, és egy scripttel tiltod azokhoz az országokhoz tartozó címeket nftables-ben, amelyek felé nem nyújtasz szolgáltatást, nálam tipikusan ilyen szokott leni Kína, Dél-Korea, Oroszország... -
urandom0
senior tag
válasz bambano #34146 üzenetére
Ebbe így még nem gondoltam bele.
Én 2000 fölé szoktam rakni az SSH portot a WAN felől elérhető eszközeimnél. Most ha lenne valamilyen kártevő valamelyik gépemen, akkor első körben le kéne állítania az sshd-t, hogy bindelni tudjon a portjára, de ehhez már eleve root jog kell (ha csak nincs valami local privilege escalation vulnerability a rendszerben), de ha már van root joga, akkor cseszhetem. Akkor ellophatja a privát kulcsomat, stb.
Te hát mindenképp kell neki root jog, ha át akar verni. -
urandom0
senior tag
De pontosan mit csinál az a bot? Más szerverek honlapjain próbálkozik 80-as vagy 443-as porton? Vagy SSH-t próbál feltörni? Vagy mit csinál?
Más szerverek felé irányuló kapcsolat indítható közvetlen a te szervereden futó bináristól, ezt a legkönnyebb észrevenni, nézegesd, hogy milyen processzek futnak a szerveren, milyen kapcsolatoknak nyitnak kifelé (lsof, netstat, ss, tcpdump, wireshark). Valamint állítsd be netfilter/iptables logot, és telepítsd az auditd-ot, és ahhoz is állíts be szabályt.
Indítható kapcsolat PHP-ból is, vagy bármilyen szerver oldali nyelvből. Ezt nem is tudom, hogy lehetne rendesen logolni, én a php-fpm log_leveljét állítanám maxra. Végső soron persze ez is az oprendszer szintjén fog kijönni.
Vagy ha más környezeted is van (Nodejs pl.), akkor annál is maxra kell állítani a log_level szintjét. -
urandom0
senior tag
Vagy wgettel, curllal indítanak kéréseket, vagy valami PHP script csinálja, de szerintem ez utóbbi. Ahogy írtam, ha az auditd fent és van rendesen be van konfigolva, az képes logolni a kimenő kapcsolatokat.
ausearch
programmal elég részletesen lehet keresgélni a logokban.
De a php-fpm logjait, és az httpd logjait is nézegesd, pl. ha sok 404-es hiba van bennük, az máris gyanús.Amit még elfelejtettem, hogy a cron logokat és a cron feladatokat is nézd át, minden usernél egyesével.
Új hozzászólás Aktív témák
- Nemzetközi bemutatókra készül az Oppo
- Politika
- Teljes verziós játékok letöltése ingyen
- Nothing Phone (2) - több, mint elsőre látszik
- Computex 2024: Ryzen 8840U dolgozik a Zotac kézi konzoljában
- Microsoft Excel topic
- Kerékpárosok, bringások ide!
- Bestbuy játékok
- Világ Ninjái és Kódfejtői, egyesüljetek!
- Ukrajnai háború
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs