Ezt, hogy véded ki, ssh host 'command'?

Linux-kezdő

Sziasztok!

Hogy lehet kivédeni az ssh távoli commandot. Azaz ne lehessen , csak bejelentkezés után parancsot kiadni!
Addig már eljutottam, hogy ha vaki bejelentkezik a szerverre az /etc/profile.d/akarmi.sh script lefut, és tájékoztatarról, hogy az illető bejelentkezett.
De sajnos ez nem fut le, ha "távolról" futtana valamit.
Természetesen PermitRootLogin No.
De azért, szeretem tudni ki-mit csinál. mert sajnos ezek a commandok nem kerülnek be a .bash_history ba se.

( Replaced | 2017. 03. 01., sze – 20:02 )

regi szep idok, amikor lehetett barmelyik cvs szervert proxynak hasznalni :)

--
NetBSD - Simplicity is prerequisite for reliability

( locsemege v | 2017. 03. 01., sze – 21:13 )

Aztán a

history -c

belekerül? ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bAndie9100 | 2017. 03. 02., cs – 07:59 )

Vigyázat!
a ForceCommand se véd meg mindentől!
azt is és a pubkey elején levő command restrikciót is a user shelljén keresztül futtatja az sshd, ami bármit lefuttathat a user nevében.
pl. ha bash a shell és a user írhatja a 

~/.bashrc

-t, aminek a futtatása megelőzi a force-olt parancs futását, akkor a bashrc által bármit futtathat! (nyilván csak a saját privilégiumával)

erre az esetre létezik egy restricted shell-szerű progi, ami (beállitástól, csoporttagságtól függően) nem engedi megkerülni a ForceCommand-os szigorításokat: https://github.com/bAndie91/tools/tree/master/ssh-forcecommand

a témafelvetéshez szorosabban annyit fűznék hozzá, hogy ha van a usernek interaktív shellje, akkor nehezebb lekövetni - ha jól értem, ez lenne a high level plan. a focecommand-shell épp az ellenkező irányba megy el: csak a whitelistelt parancsokat engedi futtatni. pontosabban "a parancs sorokat", mert az sshd az ssh klienstől kapott vagy a FoceCommand opcióban meghatározott stringet egy shell parancsSORként értelmezi, ezért is shellen keresztül futtatja.

ha a lekövethetőség de ugyanakkor az is a cél, hogy a userek a szokott módon használhassák a shelljüket, akkor megnézhetnél erre specializált shelleket, pl. 

rbash

.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

+1
oob működik, visszanézhető, indexelhető,
ha meg még a logok "értelmezését" / összefüggéseket is akar, akkor hozzá lehet csapni egy BlindSpottert is! ;)

Természetesen minden csak pénztárca függvénye, de ez egy valóban profi megoldás!
+ egész jól beszélni magyar a support team! :D

+sok

Időközben átnevezték SPS-re, egybe lehet nyitni a SPP-vel (Safeguard for Privileged Passwords), és további jónéhány OneIdentity termékkel. Ha mellé beállítasz egy, a saját igényeidre faszán összelőtt auditd+SELinux kombót, akkor egyrészt rengeteg dolgot ki tudsz védeni, másrészt ha mégsem, akkor utólag pontosan fogod látni, ki mikor akart pontosan mit csinálni (itt a 'ki' nem feltétlenül ember).

[szerk.] restricted shellekkel még tovább tudod szűkíteni a potenciális támadható felületet.

( zrubi v | 2017. 03. 02., cs – 08:21 )

De azért, szeretem tudni ki-mit csinál. mert sajnos ezek a commandok nem kerülnek be a .bash_history ba se.

Ha csak ez a cél, akkor (grsec) execlog és/vagy auditd ami neked kell.

BTW: az hogy eg parancsot futtat, még a legártatlanabb dolog amit egy ssh eléréseel lehet kezdeni ott, ahol az sshd adminja nincs tisztában az ssh lehetőségeivel ;)

--
zrubi.hu

+1, az SSH egyik nagy előnye hogy egy csomó dolgot (jellemzően a sok időt igénylő, nem kedvelt favágó munkát) lehet automatizálni/párhuzamosítani a távoli futtatással. Elvenni a lehetőséget hogy a sysadmin hatékonyan dolgozzon? Akkor jön pl. az expect, meg más okosságok. Ja és a history törlése, ha már szívatnak úgy fair ha kétoldalú a dolog :-)
____________________
echo crash > /dev/kmem

( golgota | 2017. 03. 02., cs – 11:04 )

Eloszor is ugye csak annak adunk SSH jogot, akinek kell.
A bejeletkezeseket meg ugye rogziti a naplo, szoval nem kell kulon script hozza (pl.: redhat /var/log/secure).

Alap felvetes, hogy csak azokat engedjuk be, akiknek be kell lepniuk. Azokat viszont nem csesztetjuk, hiszen a munkajukat vegzik.
Viszont rogzitjuk, hogy mit csinalnak. Erre meg ott van az audit.

De mondjuk a PAM-mal is lehet jatszani, ha korlatozni akarsz embereket.

Szoval amiket at kell nezned:
- ssh kepessegei
- logolas
- audit
- + esetleg PAM

( zeller | 2017. 03. 02., cs – 13:50 )

A history fájlok az userek kezelésében vannak, céljukat, megbízhatóságukat tekintve nem felelnek meg a céljaidnak. Nem, egy cseppet sem. Kikapcsolható, törölhető, felülírható a felhasználó által. Céljuk nem az audit, hanem az adott felhasználó segítése a korábban kiadott parancsok könnyű visszakereséséhez (ha nem volt bent több session-ben, ha nem mc-ből indított valamit, ha... szóval sok "ha" van az ssh-n indított remote command az csak egy a sok közül).
Audit, vagy audit jellegű feladatra lehet grsec, lehet selinux.

Igen, sőt a history nemcsak hogy nem audit eszköz, de kifejezetten sec-hole is lehet: lehetek én admin az X gépen, attól még nem feltétlenül tartozik rám, hogy a userem mit alkotott. (Pl 'sqlplus scott/tiger@remote' szerű parancsot futtatott, kiszivárogtatva egy jelszót).

( bAndie9100 | 2017. 03. 02., cs – 15:44 )

hogy ontopic legyek, debianban ez van a default .bashrc elejen: 


# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

ezt fel tudod hasznalni annak ellenorzesere hogy előre megadott parancsot akar futtatni, vagy interaktiv modban megy.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( uzsolt v | 2017. 03. 02., cs – 15:52 )

Ha jól értem, igazából nem az ssh paraméterében kapott parancsokat akarod tiltani, hanem az összes parancsról tudni akarsz, amit kiadnak a rendszerben. Ez szóba jöhet?

( mauser1 v | 2017. 03. 02., cs – 18:44 )

Köszönöm a sok jó ötlete!
Auditd tuti bevezetésre kerül.
Kár, hogy nem egyszerübb a védekezés.

Nem ertem mi ezen a nem egyszeru?

- Csak az kap privat kulcsot, akit be akarsz engedni
- Ezek az emberek viszont akkor a jogosultsaguknak megfeleloen tundak futtani dolgokat a sajat uid-juk alatt. Azaz 'root' joggal semmit sem, vagy amit TE megengedsz nekik (sudo) , innentol meg a TE felelosseged
- Termeszetesen ha nem bizol bennuk bekapcsolod az auditot (bar en mindig bekapcsolom, fuggetlenul hogy hasznalja e mas a rendszert rajtam kivul), hogy HA problma volt, megtudd ki csinalta. Bar azert kaptak kulcsot, mert bizol bennuk.
- Egy utemezett feladattal pedig riportokat gyartasz vagy monitorozod a logokat es riasztast kuldesz a levelesladadba

Mindenre megvan az eszkoz, amit egy sima apt-get/yum installal felraksz es akar ugy is hagyod.

Mi ezen a bonyolult? Meg egy SELinux bekapcsolasa is 2 masodperc.

Mivel sem az SSH kepessegeit, sem a PAM-ot, sem az auditot, sem az alap Linux security-t nem ismered - ezek szerint - elhiszem, hogy NEKED bonyolult. De kb ez olyan egyszeru, mint a faek. Ugy korulbelul ket es harom perc kozott van az ido, ami alatt mindent beallit az ember.

Szeritem meg a tuzogep bonyolult. Kar, hogy nincs ra egyszerubb megoldas. :(

Semmi szemelyeskedes nem volt.

Amiket irtam igazak.
- Ha alapvetoen az /var/log/secure monitorzoasa helyett egy scriptet futtatsz, hogy jelezze ha valaki belepett azt jelenti, hogy nem ismered a megfelelo alrendszereket es azok hasznalatat.
- Az auditd sem egy gyerekcipoben jaro project.
- A PAM-hoz sem ertesz, hiszen akkor akar egy egyszeru PAM modult is irhatnal az igenyeidnek, amivel az osszes tobbi tool hasznalatatol megkimelhetned magad. De egy sajat PAm modul fejlesztesenek es hasznalatanak termeszetesen megvan a hatranya a sztenderd eszkozok hasznalatahoz kepest.

Nem mondtam, hogy hulye vagy, meg "hahaha a kis csira nem ert hozza". Felsoroltam, hogy miert talalhatod neheznek azt, hogy valami egyszeru dolgot beallits.

Ha azt irtad volna: "Kar, hogy nem ertek hozza jobban igy nekem nagyon nehez ezt igy beallitani", egy szot sem szoltam volna. De amit irtal az nem igaz. A vedekezes tok egyszeru. Szamos modszer van ra. Mindegyiknek van elonye es hatranya a masikhoz kepest. Van akinek egyik egyszerubb, mint a masik.

Szoval ha ugy erzed, hogy ertesz a PAM-hoz, SELinux-hoz, Auditd-hez es a tobbi technologiahoz, akkor elnezest kerek. Nekem (!!!) ugy tunt, hogy nem.

Nem hordtam le, tenyeket allapitottam meg, lasd fent.

Lehet erzekenykedni, csak nincs miert. En is segiteni akartam, ezert irtam le, hogy milyen temekat kell atneznie. Az altalanositas viszont bantotta a szemem: "nekem nehez" vs. "nem egyszeru a vedekezes". Ebbol az jott le, mintha valami eszmeletlen bonyolult problema lenne, amit szeretne (hozzateszem igazabol az is fura ahogy es amit szeretne, amibol ismet az jon le, hogy nem egeszen jaratos a technologiakban. Tudom Lunix-kezdo).

En nem szoktam megsertodni, aha azt mondjak ram, hogy nem ertek valamihez es nezzek utana. Igaz nem is mondom annak aki ert hozza, hogy ez basszus milyen nehez. Vagy ha mondom, tuti megkapom, hogy csak nekem, mert nem ertek hozza. Es tok igaza van, aki ezt mondja.

Mindegy. Sajnalom, ha erzekeny lelkekbe gazoltam bele. :D

Bocsassatok meg!

Nem kvantummechanika, de azért random szolgáltatásokat összerakni vele, az nem feltétlen szokott két perc (opardon, másodperc) lenni. Pláne, ha azokat nem a gyártó csomagolta (nekem pl a fedora desktop napi szinten talál be valami faszsággal, hogy ez nem nyert, és ezeknek egy nagy része olyan, hogy a distributor akár meg is oldhatta volna), és pláne nem úgy, hogy értelme is legyen. Mert azért a selinux messze messze több hozzáértést igényel annál, hogy "setenforce 1, aztán nyomom az audit2allowt".

És biza tipikusan, ha valami már beüzemelt szerveren nyomsz egy setenfoce 1-et, akkor dolgok meg fognak állni.

--
Ja, és ha már ennyire megy, akkor ugye a setenforce után az /etc/default/selinuxba is beírod ;)

Egyetertunk. Neha az audit2allow akkora baromsagokat tud kihanyi magabol, hogy hasraesek. :D
De nem is a konfiguralasarol irtam, hanem a bekapcsolasarol. Nagyon sok mindent meg lehet tanulni a permissive modba kapcsolt SELinuxtol.

Szerintem viszonylag egyszeru eszkoz, es nem magahoz az SELinuxhoz ertes a kerdes, hanem, hogy ertelmezni tudj az ember, hogy mi is tortenik es hogy akadalyozza meg, hogy ne boritson be mast. De ez meg nem SELinux, hanem inkabb altalanos security tema.

ne viccelj már, ilyen alapon minden szög egyszerű, csak egy /etc/init.d/akármi start|systemctl start akármi| [nsert kedvenc init rendszer here].

Ráadásul de, a selinuxnál in practice érteni kell, hogy hogy működnek a policyk, milyen modell van a targetedben, milyen az mlsben, hogy függenek egymástól, milyen domainek vannak, mire valók, stb stb, egy csomó selinux specifikus domain tudás kell hozzá. Természetesen sokat segít, ha van háttérismereted, de az még önmagában kevés lesz.

( tgerczei | 2020. 11. 22., v – 09:12 )

Szerkesztve: 2020. 11. 22., v – 09:13

Ez szerintem egy érdekes project. (Ha már nekromancia...)