[megoldva] OpenSSH SFTP chroot loggolassal - problema

Fórumok

Sziasztok,

A feladat: Csinalj ket SFTP szervert OpenSSHval ugy, hogy a tobb szaz usered a kozos NFS sharen levo homedirjebe legyen chrootolva. A filemuveletek loggolasa elengedhetetlen.



                 IP
                 /\
                /  \
               A    B
                \   /
                 \ /
                 NFS

A recept:

  • Csinalj egy groupot amibe az sftp usereket rakod
  • Modositsd az sshd konfigjat

Subsystem       sftp    internal-sftp -l VERBOSE
Match Group sftponly
ChrootDirectory /chroot-sftp/%u
ForceCommand internal-sftp -l VERBOSE
AllowTcpForwarding no
X11Forwarding no
  • Keszits egy log devicet az NFS sharere:

mkdir -pm 751 /chroot-sftp/dev
cd /chroot-sftp/dev
mknod log c 21 5
  • Vedd ra a syslog daemont, h figyeljen erre a log devicera (pl rsyslog eseten):
  • Inditsd ujra a syslog daemont :)

$AddUnixListenSocket /chroot-sftp/dev/log
  • Csinalj egy hardlinket a userek dev konyvtaraba, hogy ki tudd szedni a logokat a chrootbol

find /chroot-sftp/user* -iname dev -exec ln /chroot-sftp/dev/log '{}'/log \;
  • A syslog daemon initscriptjebe rakd bele, hogy ujraindulaskor krealja le ujra a hardlinket, kulonben nem fog menni a logging...

find /chroot-sftp/user* -iname log -exec rm '{}' \;
find /chroot-sftp/user* -iname dev -exec ln /chroot-sftp/dev/log '{}'/log \;
  • Orulj

Namarmost ez a setup nagyszeruen mukodik egy szerver eseten. Ugyanakkor a loggolas nem fog az elvart modon mukodni ha ket - vagy tobb szervered - van. Mindig csak ott lesz log, ahol a hardlinket krealtad. Otlet arra, hogy ezen hogy lehetne tullepni?

A masik kandidalo szoftver a feladatra a proftpd sftp modullal, de azt - sejtheto okokbol - nem feltetlenul szeretnem hasznalni.

UPDATE:

Sajnos a felhasznalhato eszkozok tekinteteben meg van kotve a kezem - ha valami nincs RHEL5-6ban akkor nem hasznalhato - ugyhogy valoszinuleg proftpd lesz a vege, pedig en nagyon szerettem volna OpenSSHt hasznalni..

Azert hrgy84 otlete alapjan dafke is megcsinaltam a dolgot pam_scripttel, masok okulasara ittvan a hogyan:

Minden szervernek kell egy kulon dev/log file az NFS sharen, mert cross-device hardlinket nem lehet letrehozni:


mkdir -pm 751 /chroot-sftp/_DEVA/dev/; cd /chroot-sftp/_DEVA/dev/
mknod log c 21 5

mkdir -pm 751 /chroot-sftp/_DEVB/dev/; cd /chroot-sftp/_DEVB/dev/
mknod log c 21 5

pam_script:

  • pam-script leszed

http://sourceforge.net/projects/pam-script/

  • Kicsomagol, leforgat

tar -xvzf pam-script-1.1.4.tar.gz
cd pam-script-1.1.4
./configure
make 
make install

*nalam:

cp ~/pam-script-1.1.4/.libs/pam_script.so /lib64/security/

  • PAM bekonfigol

/etc/pam.d/sshd
...
auth       required     pam_script.so dir=/usr/local/etc/
session    required     pam_script.so dir=/usr/local/etc/
...
  • Elmegy a pam_script konyvtaraba es megirja a scripteket
 

cd /usr/local/etc/pam-script.d

sftp-session_open:

 
#! /bin/sh

ln /chroot-sftp/_DEVA/dev/log /chroot-sftp/$PAM_USER/dev/log

# success
exit 0

sftp-session_close:

 

#! /bin/sh

rm /chroot-sftp/$PAM_USER/dev/log

# success
exit 0

A masik szerveren ertelemszeruen _DEVA helyett _DEVB


chmod 755 sftp-session_open
chmod 755 sftp-session_close
  • Beallitja a symlinkeket.

cd ..
ln -sf pam-script.d/sftp-session_open pam_script_acct
ln -sf pam-script.d/sftp-session_open pam_script_auth
ln -sf pam-script.d/sftp-session_open pam_script_passwd
ln -sf pam-script.d/sftp-session_open pam_script_ses_open

ln -sf pam-script.d/sftp-session_close pam_script_ses_close
  • Orul.

Hozzászólások

Na neee ez nem lehet ekkora pobléma!
Első lépésben felejtsd el az rsyslogot (szerintem undormányos a configja), inkább syslog-ng:
abban pedig

destination d_logserver {
  tcp("10.1.1.50" port(514));
};

log {
  source(your_source);
  filter(your_filter);
  destination(d_logserver);
};

A logot természetesen küldheti egyik server a másiknak. Olvasd a syslog-ng dokumentációját

----
올드보이
http://molnaristvan.eu/

igen én is ezt mondom, de az sftp cél ezen belül legyen.

Másik megoldás, az sftp servereken is megvannak a könyvtárak, amik a user home -ok, de azokban csak a a dev/log van:

/sftphomes/
/sftphomes/user1/
/sftphomes/user1/dev/
/sftphomes/user1/dev/log
/sftphomes/user2/
/sftphomes/user2/dev/
/sftphomes/user2/dev/log
...

/sftphomes/user99/
/sftphomes/user99/dev/
/sftphomes/user99/dev/log

ezutánn az /sftphomes/ -hoz mountolod az nfs share -t. Így az sftp serveren van a log socket, a home-ok pedig az sftp serveren

----
올드보이
http://molnaristvan.eu/

Ketto dolog:
- a /dev/log nem device, hanem socket file. Nem kell letrehozni, csak fel kell konfigolni a syslog szerverben
- a socketek tuti nem hardlinkelhetok, minden chroot device-t fel kell venni a syslogba kulon. Szerintem ez ervenyes az eszkozfajlokra is. Az, hogy hardlink keszitheto rajuk, nem jelenti azt, hogy hasznalhatok is akkent.

Egyebkent en is valami olyasmit csinalnek, hogy a /dev mappa az legyen gep-lokalis, es a user home-ok legyenek nfs-en felmountolva. Foleg, mivel unix domain socket az legfeljebb egy geprol hasznalhato, tekintve, hogy az egy machine-local named pipe.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Igen socketek, pongyola volt a megfogalmazas :)
Azert hoztam letre elore, hogy tudjam hardlinkelni, mert igy biza hardlinkelhetok es mukodik is a modszer egeszen addig amig egy szerveren van.

Az odaig oke, hogy a dev mappa legyen lokalis, de azt hogy juttatod be a chrootba? A symlink ugye nem jatszik, a hardlink plane nem. Otlet?

mknod log c 21 5

En erre reagaltam. Ez device fajl, szereny jelenlegi ismereteim szerint, nem pedig socket. Socket fajlt nem tudsz kezzel krealni, mert annak legalabb az egyik oldalara kell valami.

A dev mappat adott esetben bind mounttal. Adott esetben azt csinalnam, hogy loginkor pam-bol bemountolnam a dev mappat, logoutkor pedig a .bash_logout scriptbol pedig egyszeruen lecsatolnam, vagy valami cron script idonkent lecsatolna a feleslegesse valt dev mappakat. Igy onmenedzselove valna a cucc. Ha jol tudom, pam-hoz van mountolo meg script futtato modul is, de ha nincs is, egy session modult nem tart semmibol se irni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Hat, ha RHEL, akkor marad a mountolos jatek. Vegulis az fstabot csak egyszer kell megirni hozza, utana mar egy script tudja felugyelni.

Kettonel tobb gepes kornyezethez vannak automata config cuccok, pl puppet, amikkel az fstabot szinkronban lehet tartani.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Találtam ilyet az sftp-server manuáljában:
"-e Causes sftp-server to print logging information to stderr instead of syslog for debugging."

Ezzel nem lehet valahogy ügyesen megoldani a dolgot?
Valami jó kis wrapper script-el vagy hasonlóval?
Így esetleg az adott userek logfájlját lehetne hardlinkelgetni és lenne mindenkinek külön logja.

Meg ilyen socat szerű vagy ehhez hasonló megoldás is megfordult a fejemben.
Esetleg netcat-ba beleirányítani és valamivel fogadni a másik oldalon.

Nem látom teljesen, hogy hálozaton keresztül hogyan lehet ezt jól megoldani, de a sima fájlba irányítás esetleg jó lehet.

Az internal-sftp attol internal, hogy belul van, az sshd-n belul. Ezt nagyon nehez, hovatovabb lehetetlen wrappolni.

A tobbi meg inkabb a kokanyolas kategoria, es szvsz teljesen felesleges, mert nem az sftp-vel van a gond.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nekem egy kicsit szőrös ez a megoldás (hogy is van az a REHL5-6 -ban benne kell legyen...), mi van ha bejelentkezek - ekkor ugye megjön a hardlink - aztán megint beloginolok - ekkor keletkezik egy hibaüzenet (ami, gyanítom, generál egy újabbat, ergo: forkbomb, de ha mégsem), az első sessionből kilogin és ment a log a levesbe -> lehet észrevétlen garázdálkodni.

(Ez persze egy nagyon borúlátó jóslat és lehet, hogy teljesen téves)

----
올드보이
http://molnaristvan.eu/

Mivel csak a megoldasra torekedtem nem vizsgaltam meg minden esetet, de sztem ha megegyszer bejelentkezek csak felulirodik a hardlink es ugyanugy megy a loggolas. Ha erdekel kiprobalom.

Jo esellyel nem ez lesz a vegleges megoldas (en sem javasolnam) csak azert csinaltam meg, hogy elmondhassam, hogy ilyet is csinaltam :)