• #106171 PROHARDVER!

  Új Válasz 2025-08-29 16:38:34 #106171

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  PROHARDVER!

  (rögzített hozzászólás)

  Legyetek szívesek az offtopik témákat ne ebben a topikban tárgyaljátok ki. A topikgazda is jelezte, most törölni kellett jópár hozzászólást, most már maradjatok a (szakmai) topik keretei között.

Új hozzászólás Aktív témák

• #94555 urandom0 senior tag sh4d0w #94548

  Új Válasz 2024-03-13 07:06:41 #94555

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  urandom0

  senior tag

  válasz sh4d0w #94548 üzenetére

  Lehet olvasni a neten olyan javaslatokat, hogy adjunk noexec-t a /tmp-nek, mert az növeli a biztonságot. Szerintem, ha kéretlenül bekerül a rendszerbe bármi, aminek nem kellene ott lennie, az már eleve olyan súlyos probléma, hogy az egész biztonsági rendszert felül kell vizsgálni.
  És mint a mellékelt eset is mutatja, adódhatnak problémák, ha a /tmp-t bizgeráljuk.

  Pár hete találkoztam egy olyan esettel, hogy Debian stable alá, harmadik fél hanyagsága miatt (elavult szoftverkomponens + kompromittálódott SSH kulcs) kihasználásra került egy bug, és bekerült a rendszerbe egy cryptominer. Az is a /tmp-ből futott természetesen, és a /var/spool/cron alá írta be a frissítő crontabját.
  Csináltunk egy új szervert, az adatbázist átmigráltuk, új SSH kulcsokat osztottunk ki + beállítottuk a jelszavas hitelesítést IS. A régi szerverről leszedtem szinte mindent, elzártem a net elől, a /tmp-t és a cron kiürítettem, és kíváncsiságból hagytam futni. Két nap múlva ugyanúgy megjelentek a crontab bejegyzések, és ugyanúgy futott tovább a miner.
  Ha lett volna noexec a /tmp-n, nem tudott volna futni a miner, de itt nyilván az már csak a következmény volt, a rendszer attól még lyukas maradt volna. Egyébként dél-koreai IP címről léptek be az ellopott SSH kulccsal.

Új hozzászólás Aktív témák