- Elkészült és telepíthető az Android 16
- Új térképfunkciók érkeztek az Amazfit T-Rex 3-ba
- Milyen okostelefont vegyek?
- Xiaomi 14T Pro - teljes a család?
- Befutott a megígért HRV-mérés a Withings órájára
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Apple Watch Sport - ez is csak egy okosóra
- iPhone topik
- MIUI / HyperOS topik
-
Mobilarena
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
-
#34919
sh4d0w
félisten
fekete.puma
#34918
válasz
fekete.puma
#34918
üzenetére
Processzor mindegy, videobol vagy Intel, vagy AMD, nem akarsz szopni a szar nV driverrel...
Egyebkent meg hogy erted, hogy miert? Azert, mert oob megy.
Bocs, P sorozatot kifelejtettem, az is jo. -
#34917
sh4d0w
félisten
fekete.puma
#34915
válasz
fekete.puma
#34915
üzenetére
Lenovo Thinkpad. Nem Ideapad, nem lof.szpad, Thinkpad T, X, L sorozat. Wifi ne Broadcom legyen.
-
Biztos, hogy ugyanazt nezitek? Lenry a qemu csomagot mutatja, daninet meg a virtualis UEFI firmware csomagot...
-
-
Ez nem human readable?
2025-03-18 19:29:51 status triggers-pending man-db:amd64 2.11.2-22025-03-18 19:29:51 status unpacked dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 startup packages configure2025-03-18 19:29:52 configure dkms:all 3.0.10-8+deb12u1 <none>2025-03-18 19:29:52 status unpacked dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 status half-configured dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 status installed dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 trigproc man-db:amd64 2.11.2-2 <none>2025-03-18 19:29:52 status half-configured man-db:amd64 2.11.2-22025-03-18 19:29:52 status installed man-db:amd64 2.11.2-2 -
válasz
Rhino666
#34669
üzenetére
Valojaban a systemd egyetlen dolgot sem csinal jol: itt tobben tobbszor is emlitettek, hogy mekkora jo feature, hogy barmibol tudsz service-t csinalni. Nos, ez teljesen nem igaz, nalam altalaban 3 alkalombol 2x nem sikerul (pedig sem hulyenek, sem tapasztalatlannak nem tartom magam) - miutan ez a kelletenel tobbszor fordult elo, igy mar nem is probalkozom vele.
-
válasz
urandom0
#34670
üzenetére
"De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál."
Visszautalnek bambano mondandojara: miert kell elbaltazni valamit, ami jol mukodik?
"Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el."
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
"Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt."
Mas meg screent es igen, lelovi a tavoli processt - semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process, lehet, hogy az a dolga (csak a teljesseg igenye nelkul: DB reorg, sha checksumok stb.).
"Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez."
https://github.com/systemd/systemd/issues/2402
Ezen felul persze azt is tudta a systemd (nem tudom, hogy ez igy van-e meg): ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal, maga Poettering is kihasznalta ezt a bugot.
-
válasz
urandom0
#34666
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo. A text logot 10 ev mulva az akkori okoshajcsaton is el fogom tudni olvasni, a binarist meg nem, mert ahhoz kell egy futo systemd, meg az, hogy ne korruptalodjon a binarist log addig - ami nem erossege a journalnek.
De ha mar systemd: lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot? Vagy ha mar mindenaron felhuzza, akkor szoljon a sysadminnak, hogy szaros a palacsinta? Lehetne, hogy a screenben inditott tavoli processeket ne loje le? Lehetne, hogy egy printer install miatt ne baszodjon el a tuzfal konfig? Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Hja, Poettering azota elment fejlesztonek a Microsofthoz - roluk azert mult penteken feltettem a kerdet, hogy minek irnak egyaltalan programokat: a marciusi javitocsomag 57 biztonsagi hibajabol 44 magas, vagy kritikus besorolasu a CVSS 3 szerint...
szoval igen, osszenott, ami osszetartozik. -
válasz
urandom0
#34542
üzenetére
Bocs, de ez most nyafi-nyafi.
Igenis baj, hogy mindent is felzabal a systemd, de ha mar ezt teszi, akkor meg igenis elvarhato, hogy meg tudja kulonboztetni a lokalis filesystemet a remote-tol.
A peldaddal (es a man oldallal) szembeallitva bennem megint felmerul, miert nincs egy sajat adatbazisa az eldonthetetlen mountokrol, valoszinuleg ebbol nincs sok, ahogy maga a man is referal ra.
De vegul is mindegy, legfeljebb ujabb fekete pont a systemd bizonyitvanyaba. Reszemrol a tema lezarva, ha meg jon valasz, persze szivesen elolvasom. -
-
#34289
sh4d0w
félisten
Speeedfire
#34287
válasz
Speeedfire
#34287
üzenetére
Azert az a nehany K/s disk iras es olvasas engem aggasztana...
-
válasz
#78522999
#34140
üzenetére
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.
-
válasz
#78522999
#34136
üzenetére
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.
-
Mar nemigen emlekszem, mit akartam elinditani vele service-kent; ha jol remlik, 2-3 ilyen probalkozasom volt, aztan hagytam a francba - mert cseszett elindulni. A resolved is hasonlo kaland volt, meloban kellett volna valami flexibilis megoldas, mindenki a resolved-ra mutogatott, hogy az a tuti, de a vege mindig az lett, hogy le kellett tiltani es manualisan konfiguralni az interface-eket. A binaris log, meg mint mondtam, egy egetvero baromsag: ha van text logom, akkor hajszaritoval is elolvasom, mi vagyon irva bele, a binaris loghoz meg kell a sajat kornyezete, hogy olvashato legyen - hurra.
Ez meg messze nem minden, ami miatt a systemd szar, de mivel mar ezeken a hasabokon is leirtam jonehany alkalommal ezeket, nem kezdem elolrol.
-
Kivéve, hogy rosszabbak. Nem volt még másik *nix probléma, amivel annyit szívtam, mint a resolved ökörségei, a bináris logolás egyenesen baromság, amikor meg unitot kellett volna használnom, sosem működött.
Az "ipar elfogadta": nem, az ipar csak spórol vele, a Red Hat megírja a unitokat, a többiek meg használják. Mindjuk kíváncsi leszek, mit csinál az ipar, ha a Microsoft benyögi annak az arrogáns marhának, hogy conflict of interest nekik a systemd fejlesztése, ezért abba kéne hagyni.
-
-
-
válasz
bambano
#33986
üzenetére
Valoszinuleg utobbi miatt esett az xz-re a valasztas. A systemd felzabal mindent, korbe dependalnak egymasra, atlathatatlan az egesz, igy a tamadok felteteleztek, atcsuszik a kod.
Egyes feltetelezesek szerint nem is backdoor, hanem RCE - es mivel az sshd root kontextusban fut, a dalnak vege lett volna.
Az azert nem hagy nyugodni: ha egy Intel mernok nem futtat benchmarkokat es nem tunik fel neki, hogy tul sok CPU-t zabal az ssh, meddig terjed szet a kod?
-
válasz
#79484416
#33860
üzenetére
"nem lokális hivatkozásról beszéltem, hanem remote-ról"
Teljesen mindegy, meg egyszer mondom. AIX+ksh is helyesen ertelmezte, meg mindenfele Linux shell is. Levedeni akkor kell, ha valamilyen szerencsetlen ok miatt ezen karakterek vmelyike bekerul a file nevebe (pl. egy rosszul kivitelezett website mirroring eseteben).
-
válasz
5leteseN
#33621
üzenetére
Nem, attol, hogy Linux-alapu, meg lehet fizetos a termek. A VMware virtualizacios megoldasai mind Linux-alapuak, de maximum az ESXi-t, meg a Playert hasznalhatod ingyen.
Linuxon a legjobb virtualizacios teljesitmenyt KVM-mel (Kernel-based Virtual Machine) kapod, alig van hardver overhead, de nem annyira egyertelmu es kenyelmes a hsznalata, mint a VMware-nek, vagy a VirtualBoxnak.
-
-
Egyebkent meg javitva van a legutobbi AGESA-ban, de alkalmazas oldalon is lehet vedekezni ellene.
-
#33407
sh4d0w
félisten
Dr.FantastiK
#33406
válasz
Dr.FantastiK
#33406
üzenetére
Végül is a 10 bit helyett a 24 olyan rossz...
-
#33399
sh4d0w
félisten
Dr.FantastiK
#33398
válasz
Dr.FantastiK
#33398
üzenetére
Rosszul tetted fel a kérdést: az nV driver működése az nV-n múlik, nem a Linuxon.
-
Ez meg egy erdekes hsz Redditen:
"Long story short, illegal contracts have no validity in law and thus they do not impose any obligations (and licence agreements are technically contracts). So, if it's proven during the trial that IBM violates the terms of GPL by imposing their own EULA, then this EULA is invalid and IBM has no suit against their customers, Alma and Rocky included, and these customers are not obliged to follow the EULA terms. That's why the terms of GPL do matter." -
Ez itt egy erdekes megfogalmazas. Konkretan nincs megtiltva, de ha megosztod, nagy valoszinuseggel kihajitanak a fizetovendegek kozul.
Nem csak en gondolom azt, hogy ez GPL violation, hanem meg jo sokan, Internet-szerte - ami persze nem jelenti azt, hogy tenyleg violation, en azt remelem, hogy ez megfut valami birosagon, ami kimondja, mi az abra.
-
Oke, ugy latom, nem voltam eleg ertheto: a forraskodhoz jelenleg hozzaferoknek a GPL alapjan nem tilthatja meg, hogy megosszak azt masokkal (aka "visszatenni a kozosbe").
A GPL arrol szol (nagyjabol), ha barmilyen szinten hasznot huzol az igy licencelt open source kodbol, akkor nem gatolhatod az altalad hozzaadottak nyilvanossagra keruleset - igy adva vissza a sajat hasznodbol.
-
Ebbol csak az latszik, hogy vagy nem tudod elolvasni, ami le vagyon irva, vagy annak ertelmezese nem megy.
Es bizony megeshet, hogy a Red Hat GPL-t sert, mert a fizetos ugyfelek ugyan kapnak hozzaferest a forraskodhoz, de ok mar nem oszthatjak meg senkivel. A forraskodnak resze a kernele is; a vanilla kernel forrasat megtalalod mashol is, de aligha valoszinu, hogy a Red Hat vanilla kernelt hasznal (derivative work), viszont a forraskod visszatartasaval (impose restrictions) nem teszi vissza a kozosbe, amit onnan kivett - es az az a pont, ahol valoszinuleg GPL-t sert a ceg.
Nem kell elajulni a cegtol, korabban is sertettek mar GPL-t, nincs ra garancia, hogy nem teszik megint.
Ertem en, hogy az Oracle van a celkeresztben, az Alma meg a Rocky csak collateral damage - de ettol meg megeshet, hogy licencet sert.
-
-
Na, a Red Hat atmegy closed source-ba es/vagy GPL-t sert?
-
válasz
ViZion
#33300
üzenetére
A mail küldéshez 2 dolog kell: egy agent, ami kezeli a leveleket lokálisan (pl. sendmail), meg egy relay, ami továbbítja azt. Korábban elég volt az agentből bejelentkezni Gmailbe, de ha jól tudom, ez már nem műxik.
Másik opció, ha esetleg az ISP-d kérésre kinyitja feléd a 25-ös portját, akkor azt a relayt használhatod. Esetleg keresel open mail relayt. -
#33211
sh4d0w
félisten
Neil Watts
#33209
válasz
Neil Watts
#33209
üzenetére
Az infra védelme szükséges, de nem elégséges.
-
#33208
sh4d0w
félisten
Neil Watts
#33207
válasz
Neil Watts
#33207
üzenetére
Ket dolgot nem ertek csak belole: az Ubuntu Pro membershipet, meg a ClamAV-t. Utobbi nem fut rezidensen, mint Windows-on, tehat mindig kezzel, vagy cronbol utemezetten kell futtatni.
Az viszont nincs sehol sem megemlitve, hogy a felelossegbol Rad tartozo reszeken hogy tartod frissen a firmware-t/software-t, hogyan biztositod a programod altal hasznalt adatokat szivargas ellen. Gondolom valamilyen webalkalmazast irsz, tehat OWASP Top 10, BSIMM/OpenSAM, pentest, ha alkalmazhato, akkor PCI/GDPR/HIPAA compliance-et hogyan fogod biztositani etc.
-
En nem tudom kiprobalni, nincs hozza vasam, de technikailag erdekelnenek a reszletek - remelem, kiderul, mert ez komoly problema lehet az AMD szamara. Nem azert, mert drukkolok nekik, hanem mert mindenkinek jo, ha egeszsegesek a piaci reszesedesek (ez pl. olyan, amit nem latunk a GPU piacon).
-
-
A Debian ad egy stabil alapot, amit úgy alakítasz, ahogy tetszik. Linux Mint, Ubuntu pont ezt teszik (más tészta, hogy szarul). Ha haladóbb kell, RHEL, SLES, vagy ezek vmilyen deriváltja.
Amúgy akkor szerinted DDoS egy fűzfal esetében nem security probléma?
Ezt a fasságot honnan sikerült leszűrni?
-
válasz
Shyciii
#32565
üzenetére
Oké, mivel szemmel láthatóan erőlteted, hogy magas lóról oszd az észt, hasonló stílusban válaszolok.
Szervert nem szoftveres tűzfallal védünk elsősorban, hanem hardveressel. Ha kell az otthoni szerver, tegyél elé rendes eszközt: Bitdefender, WatchGuard, Mikrotik, Netgear - és akkor nem probléma, hogy az iptables kicsit többet eszik a CPU-dból, mint az nftables.
Ez egy. Kettő: ha a te otthoni hálózatodat DOS/DDOS-olják, akkor nincs az a szoftveres tűzfal, amivel talpon maradsz - nftables-szel sem. Az xmas TCP floodot is illik felismernie egy korrekt hardveres eszköznek. Nem mellesleg az ISP-d is érdekelt abban, hogy megállítson egy ilyen támadást.
Egyáltalán maga a feltételezés hogy egy tűzfal, vagy bármilyen biztonsági eszköznél nem számít a performance...ez nagyon az úristen kategória.
Ad egy, olyan dolgokat tulajdonítasz nekem, amit nem mondtam. Ad kettő: otthoni környzetben lásd fentebb.
Bocs, de pont ezért nem válaszoltam értelmesen, mert ez a dőlt betűs részed borzalmasan leírja, hogy mi a véleményed a biztonságról, és a hozzá kapcsolódó technológiáról, és működéséről. Amivel nem is lenne baj, csak akkor nem feltétlenül neked kellene diktálnod ebben a kérdésben, főleg nem egy haladó topicban.
Maradjunk inkább annyiban, hogy azért nem válaszoltál értelmesen, mert fingod sincs erről, FUD-olsz. Azt meg végképp nem neked kell bizonyítanom, mi az én hozzáállásom a cyber security-hez. Vannak, akiknek a véleményére adok, de momentán te nem tartozol közéjük. Tanácsot kértek, adtam, de nem diktáltam senkinek sem - mindenki úgy védi meg magát, ahogy a szája ízének, vagy a rizikótűrő képességének megfelel.
Részemről itt ez befejezve, ha folytatni akarod, hozzál nekem egy friss CVE-t, 0day-t, vagy egy működő POC-ot arra, hogy az iptables nem biztonságos egy up-to-date Debian stable-ön.
-
Nofene, csak nem (8 éve Debian a fő rendszerem)?
Egyébként meg, Debian alapon is lehet cutting edge-en lenni, csak akkor pont odavész az a stabilitás, amit a kitesztelt csomagok adnak.@Shyciii: komolyan kérdeztem, milyen security issue-k jönnek, ha iptables-t használsz? Ha most sem válaszolsz értelmesen, akkor úgy veszem, hogy Te sem tudod, csak megemlítetted, hátha valaki összecsinálja magát. Nekem megfelel bármilyen publikusan olvasható link (a paywallos nem ilyen), ha nem akarsz túl sokat gépelni.
-
válasz
Shyciii
#32559
üzenetére
Már akkor téma volt az nftables, amikor Debian 10-et raktam a 9-es után... Mi több, 2014 óta van kernel támogatása, mégsem mainstream.
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság?
szoval igen, osszenott, ami osszetartozik.
Új hozzászólás Aktív témák
Hirdetés
- Házimozi haladó szinten
- Le Mans Ultimate
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- HiFi műszaki szemmel - sztereó hangrendszerek
- Elkészült és telepíthető az Android 16
- Futás, futópályák
- Parkside szerszám kibeszélő
- Formula-1
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Építő/felújító topik
- További aktív témák...
- 15db töltő egybe (65W + 90W) kerek végűek (ELKELT)
- Lenovo Legion Slim 5 82Y900BVHV Notebook
- BESZÁMÍTÁS! Asus B760M i7 12700KF 32GB DDR4 512GB SSD RX 6800 16GB Rampage SHIVA FSP 700W
- LG UltraGear Gaming Monitorok: FRISS SZÁLLÍTMÁNY -30%
- Geforce GTX 1050, 1050 Ti, 1060, 1650, 1660 - GT 1030 - Low profile is (LP)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged