- SQL kérdések
- Az EU szerint kartelleztek az indítóakkumulátorok piacán
- Kaspersky Antivirus és Internet Security Fórum
- PHP programozás
- Mikrotik routerek
- Van, amit nehéz lett megtalálni a Google keresőjével
- A Sony szerint Japánon kívül is hódíthat az anime
- Szilárdtest-akkumulátorokat fejleszt Kína, jöhet az áttörés?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Windows 11
-
IT café
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
-
őstag
Persze, hogy ritkán látsz ilyet, hiszen nem szokták keverni a funkcionalitását a fizikai vasnak. Már csak azért sem, mert másra van szükség adott funkcionalitáshoz, más-más az optimum... de szükség törvényt bont, te meg otthonra kendácsolsz, és ehhez próbáltam hozzátenni, teljesen függetlenül attól, hogy mi van enterprise környezetben.
Még azt tudom elképzelni, hogy a KVM-nek ZVol-t adsz (iSCSI target, ahogy egy storage-ről kapnád), ha már nem LVM-ben gondolkozunk.
A fizikai diszket nem tudod könnyen költöztetni? Akármilyen környezetbe viheted, ahol van SATA csatlakozó. ZFS alatt diszket cserélni (bővíteni!!) azért rendesen szívás, de megintcsak, nem mindegy, hogy a host diszkjeit cseréled, vagy a guestnek adottat? Nem látok különbséget. Ugyanazok a ZFS problémák.
Ámde az, hogy egy fájl az egész adattárad, az ad egy extra komplexitás, amivel extra hibát viszel a rendszerbe... ha az valahogy megrottyan, vihet mindent... és igen, ez igaz a fájlrendszerre is, de olyanod ugyanúgy van (ZFS a hoston), sőt, több is egymáson (hiszen a fájlod csak egy block device a guest felé, arra tesz még ő is egy plusz FS-t, pl ext4.) És akkor a ZFS előnyeit egy óriási binárison kell értelmezni. Snapshotolni a qcow2-t, háááát, ha próbáltad, akkor tudod, hogy azt menedzselni nem könnyű. Azt csinálja, hogy lesz 2 fájlod, és az élő rendszer diffeli a régit... abból újra egyet csinálni ugye... performanciáról nem is beszélve. Menteni se poén egy ilyet, de sokat segít, ha külön van az adattár, ha az nagyjából WORM.Nem tudom ki hol találkozott enterprise-szal, vagy én vagyok túlságosan közel a hiperkonvergenciához, de mifelénk nincs a compute node (legyen az kvm vagy kubernetes worker) lokális diszkjein megőrzendő adat. És persze hívhatom a SAN-tól kapott blockdevice-t "VM diszknek", de nem teszem, mert valaki még összekeveri a lokálisan tárolt qcow2-vel. Szóval @urandom0 mondása nálam így végződne: ...minden mást a storage réteg (Ceph, Gluster, SAN, stb.) tárol.
[ Szerkesztve ]
Tegnap még működött...
-
bambano
titán
válasz lionhearted #34101 üzenetére
"Nem tudom ki hol találkozott enterprise-szal,": otthonra kell neki nas. nem enterspájz hiperkonvergált vállalati ócskavastelep
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
őstag
válasz bambano #34102 üzenetére
Ugyanezzel kezdtem, erre írja mindenki, hogy ki mit látott a cégeknél... hát értem én, de kinek az életét könnyíti meg egyetlen otthoni PCn az. Én csökkenteném a komplexitást, hogy kisebb eséllyel legyen kaki a palacsintában, és eszerint osztottam meg az ötletem.
Tegnap még működött...
-
válasz lionhearted #34101 üzenetére
Keverni? Amikor egymás mellett fut 200 gép egy Power vason, az keverés?
" másra van szükség adott funkcionalitáshoz, más-más az optimum... de szükség törvényt bont,"
Igen, ezért kérdeztem, hogy mi az, ami az adott céloknek egyszerre meg tud felelni"A fizikai diszket nem tudod könnyen költöztetni?"
Lássuk, nagyobb diszkre költöznél, akkor a RAID tömböt macerálni kell. Meghal egy diszk, RAID macera. Partíciókat kell macerálni. Stb. Egy qcow2 esetén meg a NAS-nak mindegy, mi van alatta.A plusz réteg meg minden VM esetén megvan, szóval...
"Nem tudom ki hol találkozott enterprise-szal, vagy én vagyok túlságosan közel a hiperkonvergenciához, de mifelénk nincs a compute node (legyen az kvm vagy kubernetes worker) lokális diszkjein megőrzendő adat."
Hát, mi sem ezt mondtuk, hanem hogy a VM diszkjén van adat. És khm, az sem szokás, hogy a VM local diszken, az adat meg SAN-on, akkor már a VM is a SAN-ról fut, a hostban nem is kell legyen diszk. (BTW a SAN storage is mit csinál, valamilyen saját filerendszeren tárol, szóval az is egy plusz réteg, csak nem látod. Azt se feltétlen látod, miről van kiosztva neked hely.)
BTW most muszáj volt némi gépet local diszkre tenni nálunk, mert volt olyan alkalmazás, aminek az optikán lógó SAN lassú volt (másik 20 gép szó nélkül fut róla ) , és csak local diszken hajlandó normálisan működni (magyar bérszámfejtő cégek gyöngyének cucca).Itthon meg nincs storage Szóval ha akarnám sem tudnám egy redundáns, külső SAN-ra tenni.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
őstag
> Keverni? Amikor egymás mellett fut 200 gép egy Power vason, az keverés?
Nem. Semmi köze nincs ahhoz, hogy 200 gép van-e rajta, az a compute node-ot írja körül. És egy compute node nem úgy néz ki mint egy SAN. Ezt értem keverés alatt.
> Igen, ezért kérdeztem, hogy mi az, ami az adott céloknek egyszerre meg tud felelni
Remélem, hogy értem a kérdést, és legjobb tudásom és pozitív hozzáállás mellett írom, amit írok. Tehát pipa.
> Lássuk, nagyobb diszkre költöznél, akkor a RAID tömböt macerálni kell. Meghal egy diszk, RAID macera. Partíciókat kell macerálni. Stb. Egy qcow2 esetén meg a NAS-nak mindegy, mi van alatta.
De a hostnak nem mindegy. Azt akartam itt kifejezni, hogy teljesen mindegy, hogy a HOST ZFS-t vagy a GUEST ZFS-t kell abajgatni, pontosan ugyanazzal a munkával jár. A diszk csere akkor is a HDD fizikai kicserélésével jár, és pont. Ha pedig azt értjük extra melónak, hogy ezen valamiféle OS is van, akkor mindkét esetben így van (lehet/lesz), az egyik esetben a HOST OS, a másikban a GUEST OS. Ha van plusz diszk, akkor egyik esetben sem kell.
> A plusz réteg meg minden VM esetén megvan, szóval...
Ugye a direkt hozzáférésben az a lényeg, hogy nincs meg, legalább is a storage-et illetően (jelen esetben). "Menedzselni" a KVM-et persze kell, hogy ki kapja meg, ez plusz meló. De nincs FS->QCOW2->FS, csak 1db FS van az adott pár diszkeden, és pont. Pont ott, ahol a legértékesebb adataid vannak.
> És khm, az sem szokás, hogy a VM local diszken, az adat meg SAN-on, akkor már a VM is a SAN-ról fut, a hostban nem is kell legyen diszk.
Szokásokról nem nyitok vitát, amúgy pedig nem pontosan ezt írtam. És magad is hoztál rá példát.
Tegnap még működött...
-
válasz lionhearted #34105 üzenetére
"És egy compute node nem úgy néz ki mint egy SAN. Ezt értem keverés alatt."
Ja, de ha van is local diszkje, akkor sem lesz belőle SAN.
Meg hát mi a helyzet a vSAN-szerű dolgokkal? Ezek nem feltétlen fekete-fehér dolgok."És magad is hoztál rá példát."
Nem, amit én írtam, az az volt, hogy a VM local diszken fut az egyik compute node-on, és a VM virtuális diszkjén van az adat is Egy gép, saját virtuális diszkjeivel.
Ja, meg azért raktunk pl. pár gépet local diszkre, mert olyan szinten dugig volt a közös storage, és késett a csere." A diszk csere akkor is a HDD fizikai kicserélésével jár, és pont. "
Igen, megfogtad a lényeget, az a legnagyobb meló benne, ja, nem"Ugye a direkt hozzáférésben az a lényeg, hogy nincs meg, legalább is a storage-et illetően"
És esetemben a NAS-nak majdnem mindegy teljesítmény szempontjából, hogy direktben kap-e diszket, vagy virtuálisan. Minden más esetben meg kb. kényelmesebb a virtuális diszk.Mutogatni való hater díszpinty
-
őstag
-
bambano
titán
válasz lionhearted #34107 üzenetére
unixon a diszk partíció egy hatalmas blobb...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz lionhearted #34107 üzenetére
Pont erre voltam kíváncsi. Van valami jellemző hátránya a ZFS vagy egyébnek ilyen szempontból, hogy pl. hajlamos összeborulni? Meg hát ezért lenne RAID-ben.
Amúgy az adatról van backup, a VM-ek nagy része meg nem égető fontos. Amelyik igen, arról van backup
Nyilván az egyszerűbb eset, hogy simán egy winyón vannak az adatok, de egy winyóhiba akkor is egy winyóhiba. VM diszk file meg eddigi tapasztalat alapján nem megy magától tönkre.Mutogatni való hater díszpinty
-
nagyúr
Az a baj, h nem vagy kulonosebben tapasztalt/profi infrastruktura-mernok, de el akarod kezdeni egymas tetejere pakolni az absztrakciokat. Ez az almoskonyv szerint nem vezet jora, mert ha valami elkezd rakoncatlankodni, macerasabb lehet kinyomozni, hogy mi van.
ZFS/RAIDZ1 on bare metal (HBA), ez a megoldas, ami neked kell. Konkretan azt javaslom, hogy TrueNAS-t rakjal fel. Ha gond van, diszk ki/be, resilver, kesz. Ha alkalmazasok, szolgaltatasok kellenek, akkor TrueNAS alatt virtualizalsz.
Lehet ennel bonyolultabban is csinalni, de _szerintem_ nem tartasz ott. Ha nem fontos az adat, akkor persze jatssz vele.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Nem, amúgy nem, ezért kérdezek. És konkrétan ezért érdekelnének a buktatók.
Absztrakciók egymáson, az amúgy is van, és nem látom, hogy különösebb gondot okozna, nem csak itt, hanem nagyobb cuccokon sem. (Meg most az a sok absztrakció egymáson, hogy van egy valamilyen RAID tükröm, és azon egy virtuális diszk file? Hát ha ettől baja lesz, akkor a fél világ virtualizációja össze kéne dőljön naponta...)Truenas-t? Ez volt az eredeti kérdés.
OK, ha jól látom, lehet rajta futtatni VM-et, de... na, nem arra való.
Mezei Debian lesz, a kérdés csak a megvalósítás, meg a filerendszer.Az adat fontos, ezért van róla backup, de az meg ugye online nem elérhető.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
nagyúr
Elnézést, ha úgy jött le, h esetleg az általános hozzáértésedet vonom kétségbe. Storage építésénél jellemzően a célszoftvernek próbáljuk adni a kontrollt.
TrueNAS rendes Linux, abszolút való virtualizációra. Ha sima Debiant raksz fel, az is működni fog, de a TrueNAS (Scale) ad egy csomó segítséget.
while (!sleep) sheep++;
-
-
Amúgy semmi, csak ide szerintem felesleges, túlságosan NAS. (Meg mondjuk ami most a virtuálhost, és egy ideig a NAS is ez lesz, az egy A8-3850, 16GB RAM-mal.)
Eddig is csak egy mezei Debian volt a NAS, RDP+SSH+SMB+Filebrowserrel, és elég is ez a funkcionalitás.Mutogatni való hater díszpinty
-
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. -
Lenry
félisten
válasz lionhearted #34101 üzenetére
ZFS alatt diszket cserélni (bővíteni!!) azért rendesen szívás
wut?
zpool replace tank régidiszkid újdiszkid
User részről kész, ő nyilván meg resilverel, de a kötet továbbra is használhatóGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
-
őstag
És ezt minden diszkre. Nem azzal van a gond, hogy nem egy parancs, hanem hogy mindet. Okosba, olcsón venni egy nagyobbat az nem lesz megoldás, ugyanúgy ahogy random raid tömben sem... De más szinten folyt az eszmecsere, hogy melyik vm rétegben lesz ez gond.
Tegnap még működött...
-
Ablakos
őstag
(Ubuntu 22 LTS)
Az fstab-ban van jó néhány cifs csatolás. Az a fura hiba fordul elő, hogy újraindítás után véletlenszerüen valamelyik nem kapcsolódik fel. Terminálban ilyenkor persze azonnal csatolható kézzel. Nincs olyan megoldás, hogy próbálkozzon többször is a rendszer, ha elsőre valamiért nem sikerül a mount?[ Szerkesztve ]
-
Ablakos
őstag
Még egy mount kérdésem van. A lenti fstab bejegyzést szeretném user csoport számára rw joggal felkapcsolni. cifs megosztásnál működik (gid=), de lokalis lemeznél nem. Mivel kell kiegészítenem a sort, hogy root:user 775 jog legyen? (A kapcsolati pontot beállítom(permission), de mountnál root:root lesz)
#internal disk mount
/dev/disk/by-uuid/a1e3f0e4-026f-45e2-921d-4d028e7dc1cf /media/nvme1 ext4 rw,noexec,nosuid,nodev,relatime,errors=remount-ro
-
-
Ablakos
őstag
Ezen is elakadtam, hogy egy felkapcsolandó meghajtó ./ root:root. Itt hogy tudom a groupot módosítani. (fel sincs csatolva még)
Megoldás: Felkapcsoltam root:root -ként és a csatolási pontban változtattam meg a csoportot. Ezután minden mount-ra már root:user lesz a perm.
Nem biztos, hogy ezt így kell, de működik. -
ZFS hírek. Tehát konkrétan ugyanazon a hardveren, ahol csak az ext4-es winyó cserélődött ZFS-es winyóra (mondjuk újabb, nagyobb, gyorsabbra), gyorsabban futnak a virtuálgépek... Ugyan az állandósult írás csak 40MB/s, de amikor még nincs dugig a cache, akkor 10-20x értékek is vannak...
(2x500GB RAID tükör cserélődött 2x4TB ZFS mirrorra.)Mutogatni való hater díszpinty
-
PMoon
junior tag
Sziasztok.
Elnézést, hogy ide írok, de szerintem a kezdő csoportba nem volna értelme.
Van egy vps-em, ami az utóbbi időben furán viselkedik.
Tegnap reggel egyáltalán nem működött, ssh-val sem tudtam belépni csak virtuális konzollal. Akkor Debian volt a gépen.
Tegnap napközben próbából lecseréltem Arch-ra.
Ma reggel megint nem akart megjelenni az nginx-es teszt weboldal egészen addig, amíg ssh-val be nem léptem.$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
$ systemctl status sshd
● sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset:
disabled)
Active: active (running) since Sat 2024-05-25 18:05:29 CEST; 13h ago
Main PID: 695 (sshd)
Tasks: 1 (limit: 4676)
Memory: 4.0M (peak: 4.9M)
CPU: 444ms
CGroup: /system.slice/sshd.service
└─695 "sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups"
May 25 22:47:07 vps sshd[1514]: Accepted publickey for ...
May 25 22:47:07 vps sshd[1514]: pam_unix(sshd:session): session opened for user ...
May 25 22:47:19 vps sshd[1526]: Accepted publickey for ...
May 25 22:47:19 vps sshd[1526]: pam_unix(sshd:session): session opened for user ...
May 26 04:50:14 vps sshd[1899]: Connection closed by 165.227.168.223 port 24353
May 26 04:50:34 vps sshd[1900]: Connection closed by 157.230.100.23 port 20316 [preauth]
Mi ez a 2db "Connection closed" 4:50-kor?
Mit tehetnék, hogy biztonságos legyen a VPS-em?[ Szerkesztve ]
"... Ne ess pánikba! ... Mindig legyen nálad törölköző!"
-
PMoon
junior tag
A kérdést egy kéréssel kibővíteném...
Tudnátok abban segíteni, hogy pár pontban leírnátok ...
- milyen eszközöket érdemes használnom a vps-em védelmére?
- milyen módszerekkel tudom ellenőrizni, hogy kompromitálódott-e a rendszer?Köszönöm.
"... Ne ess pánikba! ... Mindig legyen nálad törölköző!"
-
Vedelem:
- up-to-date minden
- ssh jelszavas belepes tiltasa
- auditd konfiguralasa
- tuzfal konfiguralasa
- web app pentest (ha van web app)Nyomozas: nyilvanvaloan csak a logokra tudsz tamaszkodni - sshd log, auth log, system log. Az a ket belepes lehetett a tied is, ha eltero idozonara van allitva a gep rendszerideje, de utana is nezhetsz, honnan jottek azok a kapcsolatok. Persze a VPN-ek miatt egyaltalan nem biztos, hogy helyes informaciokat fogsz talalni. Mindket IP egyebkent a Digital Ocean-re mutat.
https://www.coreinfinity.tech
-
jimmy399
senior tag
Nos, ez nem a ZFS-el kapcsolatban írom, de a gyorsulásról jut eszembe:
SSD-s rendszerindítás (ext4, default kapcsolókkal):
-------------------------------------
Startup finished in 185us (firmware) + 36us (loader) + 9.454s (kernel) + 13.969s (userspace) = 23.424s
graphical.target reached after 12.052s in userspace.HDD-s rendszerindítás (BTRFS, zstd fájlrendszertömörítés):
-------------------------------------
Startup finished in 79us (firmware) + 35us (loader) + 7.938s (kernel) + 13.138s (userspace) = 21.077s
graphical.target reached after 13.119s in userspace.SSD egy 2,5"-os USB 3.0-s házban (64 GB Kingston, BTRFS compress=zstd):
---------------------------------------------------------------------------------------------------------------------------
Startup finished in 111us (firmware) + 62us (loader) + 7.412s (kernel) + 11.186s (userspace) = 18.599s
graphical.target reached after 10.739s in userspace.Debian 12.5, legutolsó kiadott kernellel. Bár tény, hogy az első egy Xfce4-es DE
a HDD-n meg egy Openbox-os tint2-es és konzolos login van és a 3. SSD-n a külső házban szintén a HDD-ről áttelepített rendszer fut Openbox-al és tint2-vel.A Chrome indítás kb 15 másodperc az első indítás esetén, ez egy belejlentkezett profillal és bekapcsolt cache-el.
--- N/A ---
-
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... -
PMoon
junior tag
válasz sh4d0w #34137 üzenetére
sh4d0w, urandom0:
Köszönöm az infókat.Amit jelenleg is használok/használtam:
ssh
- ed25519 kulcspár (+passphrase jelszóval)
- root belépés tiltva
- jelszavas belépés tiltva
- port áthelyezve 32000+ tartományba
- pam tiltva (bár ez most nem számít, de nem használom)ufw
- kizárólag az ssh, 80/443, 8080/8443 portok vannak nyitva (ezeket használom)fail2ban
- bantime 1440m, findtime 30m, maxretry 3folyamatosan up-to-date, de manuálisan szoktam frissíteni
egyelőre nem használok külső repo-t (csak Arch esetében, Debian esetében szükséges volt)A többit nem használtam, nem ismertem, nem állítottam be. Ezeket meglesem, köszi még1x.
Log-okat nézegetem.Amúgy a 2db IP biztosan nem én voltam, minden gépem és a vpn is "Europe/Budapest" időzónával fut.
Láttam, hogy Digital Ocean az IP tartomány, de valamelyik oldal New York-ra mutat, valamelyik Frankfurtra.
Mindegy, biztosan nem én voltam. (Proton VPN-t használok a klienseken)Akkor egyelőre figyelek ... és a többi eszköz használatát megnézem.
"... Ne ess pánikba! ... Mindig legyen nálad törölköző!"
-
Az ssh portnak jobb, ha a default 22-esen van. Igen, jonni fog a brute-force attack, de a fail2ban es a paswwordless belepes blokkolni fogja. A merleg masik oldalan: ha tegyuk fel, felbukkan vami sebezhetoseg az openssh szerverben es hasznalni akarja a tamado a 22-es portot, ahhoz root jogosultsagot kell szereznie, mig a 32000+ eseten nem kell.
https://www.coreinfinity.tech
-
-
PMoon
junior tag
-
bambano
titán
válasz urandom0 #34143 üzenetére
ez így a nemlétező esemény. hogy sebezhetőség van az openssh szerverben, azt ki tudta lőni, de a 22-es portra nem tud rábindelni, annak nulla az esélye. a credentials lopásnak meg azért nincs értelme ebben az elképzelt felállásban, mert ha a jogosult user tudja, hogy nem a 22-es portra tette az ssh-t, akkor nem fog a 22-es porton próbálkozni, tehát nem fog legális azonosító adatokat kapni ott, aki meg a 22-es porton próbálkozik, az fake.
ha elköltöztetted az ssh-t a 22-es portról, akkor egy rakás cpu-t megspórolsz, amit a fail2ban elhasználna.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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. -
válasz sh4d0w #34141 üzenetére
Ha valami a helyi gépen képes a bármelyik portra indítani valamit, akkor már bent van az illető
@urandom0 : "(ha csak nincs valami local privilege escalation vulnerability a rendszerben)"
Onnantól kezdve meg nem fog ezzel szórakozni
Nekem sem a 22-n van az sshd, bár nem magason, csak kicsit máshol[ Szerkesztve ]
Mutogatni való hater díszpinty
Új hozzászólás Aktív témák
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! LEGOLCSÓBB! Automatikus 0-24
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Vírusirtó, Antivirus VPN kulcsok
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen