SFTP--> advies nodig

[Razwer]

aiight, ik werd gevraagd een SFTP server op te zetten (SSH dus) voor mijn werk. Dit besluit is genomen op hogerhand door een groep mensen die net weten hoe ms word en outlook werkt en verder niets. Ik kan hier niets tegen inbrengen dus het moet maar.
De situatie is als volgt. Een client krijgt een login, moet inloggen op SFTP op poortje 443 (slaat ook al nergens op maargoed). GEEN shell toegang, helemaal niets, alleen dus SFTP. moet kunnen uploaden en downloaden in zijn eigen home folder. Er moet een "master" account komen die dingen in de home folder kan proppen van alle users.
Ik heb draaien: windows 2003 sp2 (dat werd mij opgedragen) en nu ook redhat enterprise 5 in een vmware sessie op diezelfde box met de netwerk kaart bridged, dus zijn eigen ip adres.
geprobeerde software: FreeSSHD, FreeSFTPD, SSH Tectia server en nog een paar.
op linux open ssh.
De eerste 2 tools zijn erg buggy, en deze site mag dus niet down gaan, staat veel geld op het spel. SSH tectia server kan geen custom home folders aan, behalve dus %userprofile% wat dus "C:\documents and settings" is.
Niets werkt echt zoals ik het wel. Open SSH komt nog het meest in de richting maar je kan 0,0 aan de SFTP opties configureren, en de users mogen niet in de shell loggen.

Ik ben niet echt een linux guru om daar een goede oplossing voor te vinden, maar zelfs onze AIX expert had niet zo 123 een oplossing bedacht.

advies, anyone?

tnx

[Jungian]

Misschien moet je eens wat gaan lezen over shells ? Die AIX "expert" had daar wel op kunnnen komen lijkt mij. Poort 443 is security by obscurity en openSSH doet precies wat je wilt (misschien ook maar wat lezen over SSH voordat je hieraan gaat beginnen ?).

[ Voor 41% gewijzigd door Jungian op 19-06-2007 19:09 ]

[Verwijderd]

Juist, OpenSSH en verdiepen........

[BCC]

Verwijderd schreef op dinsdag 19 juni 2007 @ 19:21:
Juist, OpenSSH en verdiepen........

Inderdaad, aangezien SFTP FTP over SSH is, is het makkelijkste om gewoon iedereen een dichtgetimmerde shell access te geven.

[Razwer]

ik had de docs van openssh doorgespit maar echt niets aan configuratie opties voor de sftp server, als je mij in de goede richting zou willen helpen met wat links naar bruikbare docs zou ik erg dankbaar zijn. hoet moet dus voor 99% van de gebruikers dicht zijn voor de shell en alle beheerder moeten uiteraard wel de shell in kunnen.

[ Voor 23% gewijzigd door Razwer op 19-06-2007 19:38 ]

[BCC]

Heb je ergens een user DB waar je mee moet communiceren? LDAP / SQL? Anders dien je gewoon standaard users aan te maken op je unix bak en dan ben je eigenlijk al klaar. Je zou evt de rechten nog wat kunnen aanscherpen, maar dat lijkt me hier eigenlijk al niet nodig.

[Jungian]

Razwer schreef op dinsdag 19 juni 2007 @ 19:37:
ik had de docs van openssh doorgespit maar echt niets aan configuratie opties voor de sftp server, als je mij in de goede richting zou willen helpen met wat links naar bruikbare docs zou ik erg dankbaar zijn. hoet moet dus voor 99% van de gebruikers dicht zijn voor de shell en alle beheerder moeten uiteraard wel de shell in kunnen.

OpenSSH is ook geen SFTP-server. OpenSSH is een set SSH-tools met opensshd als SSH-server (daemon). Door gebruikers een ongeldige (of geschikte) shell te geven maak je normaal inloggen onmogelijk, maar kan diegene wel files overpompen.

[DJ Buzzz]

Ik zou je eens verdiepen in b.v. het gebruiken van rssh als shell voor users. Dit soort documentatie is prima te vinden via Google, zie b.v. het eerste artikel dat ik vind bij zoeken op:

sftp without shell

http://gentoo-wiki.com/HO...out_shell)#Defining_Users

Het is dan wel gericht op Gentoo, maar Linux is Linux en je kunt dus erg veel zaken hier simpelweg van overnemen (b.v. dus de tip om rssh als shell voor je users te gebruiken). Verder kun je idd kijken of je kunt koppelen met bestaande authenticatiesystemen zodat je niet je gebruikers dubbel moet beheren.

[Verwijderd]

Je kan access limiten door zoiets te doen, het is wel op basis van passwordless connections.

in je authorized key file:
from="$ip",command="/home/$user/bin/validate-commands" ssh-rsa <snip, de rest van de rsa key>

In de validate-commands file zet je dan zulke dingen:

code:

#!/bin/sh

#echo $SSH_ORIGINAL_COMMAND > /tmp/sshorig

case "$SSH_ORIGINAL_COMMAND" in
        ls\ -la\ *)
                $SSH_ORIGINAL_COMMAND
                ;;
        *)
                echo "Command rejected $SSH_ORIGINAL_COMMAND"
                ;;
esac

Je kan nu een user limiten om alleen ls -la * te kunnen laten uitvoeren (* is dus alles wat een user erna wilt neerzetten).

Ik gok dat je zo een aanpak kunt gebruiken om alleen sftp toe te laten en de rest te weigeren. Zie ook ForceCommands in de sshd_config file.

[GX]

Wel users aanmaken met een andere homedir dan default; dan heb je een soort 'gedeelde ftp bak', de man-page van adduser legt je uit hoe je dat doet.

Bedoelden ze niet gewoon FTP over SSL? Dat kan ook nog namelijk.

[Razwer]

GX schreef op dinsdag 19 juni 2007 @ 21:32:
Wel users aanmaken met een andere homedir dan default; dan heb je een soort 'gedeelde ftp bak', de man-page van adduser legt je uit hoe je dat doet.

Bedoelden ze niet gewoon FTP over SSL? Dat kan ook nog namelijk.

jammer genoeg niet, anders had ik wel genoeg aan mijn serv-u licentie op windows.

anyways, thanks iedereen voor de info, ik ga morgen weer aan de slag met die bak. de waardering is groot

[Razwer]

Jungian schreef op dinsdag 19 juni 2007 @ 20:11:
[...]

OpenSSH is ook geen SFTP-server. OpenSSH is een set SSH-tools met opensshd als SSH-server (daemon). Door gebruikers een ongeldige (of geschikte) shell te geven maak je normaal inloggen onmogelijk, maar kan diegene wel files overpompen.

Yeah zoiets had ik nu dus opgezet vanmiddag maar dat vind ik een beetje een houtje touwtje oplossing. Ik had gehoopt dat iemand had gekomen met "hier kijk dit geweldige software pakket doet alles wat je wilt en poetst ook je schoenen nog eens" maar jammer genoeg niet dus. dus met een beetje pech zal ik toch deze oplossing moeten implementeren.

ter duidelijkheid, dit is dus puur voor "software distributie". Praktisch gezien: zip files dus. Vanwege het feit dat dit de financiele sector is, MOET het dus over SFTP. Wat mij betreft kan het allemaal ook nog veiliger, maar ik heb totaal geen inspraak daar op.

Wat het nog vervelender maakt is dat de users administered moeten worden door een niveau secretaresse die nog niet eens met outlook overweg kan. heb webmin draaien op die bak maar die is ook redelijk limited in het user management. aanmaken en deleten gaat prima, aanpassen had ik zo 123 niet iets van gevonden in de 20 mins dat ik er mee bezig ben geweest.

[Jungian]

@ eerste en tweede stuk van je opmerking

Je weet totaal niet waar je het over hebt volgens mij. Ik heb het nog geprobeerd uit te leggen, maar je schijnt het niet te willen/kunnen begrijpen. Wat ik schets is geen houtje touwtje oplossing, maar DE oplossing, die wereldwijd door een veelvoud van bedrijven en users gebruikt wordt.

@ derde stuk van je opmerking

Systeemadministratie op zo'n laag niveau ? Lekker bedrijf waar jij werkt dan.

[ Voor 65% gewijzigd door Jungian op 19-06-2007 22:25 . Reden: *zucht* ]

[Verwijderd]

Kijk de oplossing Junian is gewoon het allermakkelijkst. Je moet je alleen wel even je neus in de docu steken.

Ten tweede snap ik niet waarom je het veilig moet zijn, terwijl je een typmuts de useradmin laat beheren, en webmin kan je zelf natuurlijk ook een beetje in elkaar scripten zodat je meer kan configureren voor gebruikers. Dat is een kwestie van een beetje php/perl/bash...
Dan kan je na het werkend te krijgen ook nog een beetje trots op je opgelegde project zijn...

[BCC]

Razwer schreef op dinsdag 19 juni 2007 @ 22:01:
[...]
jammer genoeg niet, anders had ik wel genoeg aan mijn serv-u licentie op windows.

Serve U heeft nou niet een bepaald vlekkeloos security verleden. Misschien niet echt handig voor gevoelige financiële gegevens ?

[Razwer]

Jungian schreef op dinsdag 19 juni 2007 @ 22:13:
@ eerste en tweede stuk van je opmerking

Je weet totaal niet waar je het over hebt volgens mij. Ik heb het nog geprobeerd uit te leggen, maar je schijnt het niet te willen/kunnen begrijpen. Wat ik schets is geen houtje touwtje oplossing, maar DE oplossing, die wereldwijd door een veelvoud van bedrijven en users gebruikt wordt.

@ derde stuk van je opmerking

Systeemadministratie op zo'n laag niveau ? Lekker bedrijf waar jij werkt dan.

Je hoeft je niet zo beledigd te voelen als ik zoiets houtje touwtje noem. De reden waarom ik dat zo noem is omdat je een "error" creeert en zodoende iets laat afsluiten of vast lopen. Als jij een professioneel systeem op zet dan wil je toch niet dat je iets afsluit/vast loopt door zoiets. Je wilt een access denied forceren op dat niveau.
Ik had allang begrepen zoals je hier boven kan lezen dat dit waarschijnlijk de enige gangbare oplossing is. Spijtig, maar het zij zo. Mij is ook al uitgelegd dat het SFTP protocol niet gemaakt is voor standalone server en daarom er dus ook niet echt een goede standalone service voor is.

Over de systeem administratie, breek mij de bek niet open. Maar die administratie van de users is te weinig om een fulltime iemand op te zetten, dus worden mensen met meer vrije tijd er op gezet. Dan hou je de "office managers" over. Ik heb daar ook weer niets over in te brengen. Het bedrijf waar ik voor werk zal je niets zeggen maar het heeft een dow jones notering en doet software voor hele grote banken waaronder dus de core software voor een nederlandse bank. De distributie voor die software (en updates) zal dus via deze server verspreid worden.

BCC schreef op dinsdag 19 juni 2007 @ 22:28:
[...]

Serve U heeft nou niet een bepaald vlekkeloos security verleden. Misschien niet echt handig voor gevoelige financiële gegevens ?

ik had de keuze IIS of Serv-U. Welke heeft het slechtste security verleden? juist... Ik ben uiterst gefrustreerd over dit project gezien de druk die op mij gelegd word en de weinige bewegingsvrijheid die ik heb. De vele foute beslissingen die genomen zijn hebben al tienduizenden euros gekost, maar het project schijnt vele malen meer op te leveren... (en dan bezuinigen ze op salaris )

[Razwer]

Jungian schreef op dinsdag 19 juni 2007 @ 19:06:
Misschien moet je eens wat gaan lezen over shells ? Die AIX "expert" had daar wel op kunnnen komen lijkt mij. Poort 443 is security by obscurity en openSSH doet precies wat je wilt (misschien ook maar wat lezen over SSH voordat je hieraan gaat beginnen ?).

btw had deze post van je over het hoofd gezien. 443 is niet gekozen vanwege security by obscurity. Zo intelligent zijn ze niet bij ons. Dit hebben ze gekozen omdat de gemiddelde bank alleen poortje 80 en 443 open heeft op de proxy. dan is de keuze snel gemaakt toch. En idd die AIX expert had dat shell gebeuren al voorgedragen en iemand anders ook al, maar ik ben daar niet direct tevreden mee. Uitleg staat hier boven. Dat is drama wanneer tiepmiep het moet instellen. Je zal vast een berg kunnen scripten, maar ik ben een microsoft man, geen linux guru, vandaar dat ik hier om advies kom vragen. Aldoende ken ik dingen van Linux maar het is niet prio 1.

[benoni]

Ik gebruik inmiddels al een paar jaar SCPonly om jailed home directories te maken op de Linux webservers. Het is niet klik-en-klaar te installeren, je moet vanuit de terminal een script opzoeken en starten met de juiste parameters om jailed home directories te maken. De manier waarop je de home directory indeelt is direct van invloed op de veiligheid van de 'sandbox', dus je moet weten waar de mogelijke onveiligheden zitten, en deze nakijken als je een nieuwe homefolder hebt gemaakt. Maar als je 't eenmaal doorhebt werkt het simpel en safe.

De implementatie komt hierop neer:

• Men neme een BSD of Linux systeem;
• SCPonly installeren met je favoriete pakkettenmanager;
• Terminal openen en op zoek gaan naar /usr/share/doc/scponly/setup_chroot. Het beste kun je het script eerst doorlezen voordat je het uitvoert, zodat je ongeveer ziet wat het doet. De handleidingen op internet zijn niet allemaal even duidelijk, en per Linux/BSD versie verschilt de opbouw van de jailed home folders. Waar het allemaal op neerkomt is dat de jailed home folders een eigen /bin, /etc, /lib en /usr krijgen met daarin een beperkte mini-commandoset (ls, mv, rm enz.). Om met die commando's te kunnen werken krijgen de SCP-gebruikers een beperkte shell (/usr/bin/scponly). Dit is bij elkaar precies genoeg om met WinSCP en Fugu te kunnen inloggen en bestanden te kunnen up- en downloaden.
• Nakijken of de home folders goed zijn opgebouwd, let vooral op de rechten op de lokale /bin, /etc, /lib en /usr mappen, die directories mogen onder geen beding aanpasbaar of overschrijfbaar zijn door de gebruiker (net zoals de vergelijkbare mappen in de echte root). Om dat dicht te timmeren moet je het eigenaarschap van de jailed homefolder omzetten naar root, en dat betekent dat de gebruiker geen bestanden direct in zijn jailed root mag plempen. Je moet dus submap(pen) maken (bijvoorbeeld 'Documents', of 'Upload') die op naam staan van de gebruiker en writable zijn.

Zo ziet zo'n jailed home folder er dan bijvoorbeeld uit:

code:

drwxr-xr-x  10 root      root       4096 Jul  3  2006 .
drwxr-xr-x   6 root      root       4096 Jul  3  2006 ..
drwxrwxr-x   2 gast      users      4096 Jul 25  2006 Documents
drwxr-xr-x   2 root      root       4096 Jun  3  2006 bin
drwxr-xr-x   2 root      root       4096 Jun  3  2006 etc
drwxr-xr-x   3 root      root       4096 Jun  3  2006 lib
drwxr-xr-x   4 root      root       4096 Jun  3  2006 usr

Zo ziet de bijbehorende gebruikersaccount (/etc/passwd) eruit:

code:

gast:x:2577:2577:,,,:/home/gast//Documents:/usr/sbin/scponlyc

Dus 'scponlyc' in plaats van de normale shell. De '//Documents' achter de gebruikersmap loodst de gebruikers bij het inloggen meteen door naar deze submap, zodat ze hun jailed root (met /bin, /etc, /lib en /usr) niet te zien krijgen. Ze kunnen wel terugbladeren naar dat niveau.

[Jungian]

Razwer schreef op woensdag 20 juni 2007 @ 00:25:
De reden waarom ik dat zo noem is omdat je een "error" creeert en zodoende iets laat afsluiten of vast lopen. Als jij een professioneel systeem op zet dan wil je toch niet dat je iets afsluit/vast loopt door zoiets. Je wilt een access denied forceren op dat niveau.

Het gaat helemaal langs me heen wat je nu probeert te zeggen (care to explain ?) Door een ongeldige shell / geschikte shell te gebruiken disable je alleen de toegang tot de shell, meer niet (en kan ook zo aangepast worden). Helaas geen praktische oplossing als dit beheerd moet worden door minder gekwalificeerde personen (alhoewel er met een GUI altijd wel een mouw aan te passen valt).

Wikipedia had ook nog een lijstje SFTP-servers :

http://en.wikipedia.org/wiki/List_of_SFTP_servers

Ook voor Windows en ook nog eens commerciële oplossingen ook (dan kan het al bijna niet eens meer mis gaan en anders kun je de fabrikant schoppen, aangezien je toch betaald hebt ).

[ Voor 19% gewijzigd door Jungian op 20-06-2007 02:11 ]

[BCC]

Jungian schreef op woensdag 20 juni 2007 @ 02:08:
[...]
Het gaat helemaal langs me heen wat je nu probeert te zeggen (care to explain ?)

Hij vind het verwijderen van de link naar een shell een hack, terwijl jij het common practice vindt. Waarschijnlijk wederom omdat de TS niet helemaal thuis is in de materie. Ik denk dat het gewoon een nette oplossing is

[ Voor 19% gewijzigd door BCC op 20-06-2007 09:30 ]

[benoni]

BCC schreef op woensdag 20 juni 2007 @ 09:16:
Ik denk dat het gewoon een nette oplossing is

Inderdaad, het is een geaccepteerde standaard, bij mijn weten. Bij de user management frontends (zoals bijvoorbeeld Apple bij een xServe levert) kun je per gebruiker gewoon kiezen met een menu-knopje: /bin/bash of /usr/bin/false. Je kunt /usr/bin/false wel starten maar deze zegt niets terug.

Ik lees van TS dat in principe één van de gebruikers gaat uploaden, de rest hoeft alleen te kunnen downloaden. In principe kun je dus één jailed home directory maken voor het uploaden, en voor download gebruikers accounts aanmaken zonder eigen home directory, in plaats daarvan de home directory aangeven van de upload gebruiker. Als bijvoorbeeld de 'Documents' en de bestanden die erin staan leesrechten hebben voor de gezamenlijke groep (of gewoon 'users') kunnen ze downloaden.

Voordeel hiervan is dat het gebruikers toevoegen en weghalen met een enkel shellcommando kan. Er is ook natuurlijk ook een front end voor te maken zodat Miep simpelweg op een formulier een nieuwe naam en wachtwoord kan intikken en een knopje 'Toevoegen' kan drukken

Addit
Iedereen in één jailed home folder gaat misschien niet meteen helemaal werken. In zo'n jailed home folder zit ook een /etc/passwd met alleen de useraccount van de eigenaar van de home folder erin (een kopie van de betreffende regel uit de 'echte' /etc/passwd). Het kan zijn dat een gastgebruiker van deze jailed root dus toegevoegd moet worden aan dit bestand.

Ook heb ik wat verkeerd gelezen, TS ging uit van een eigen home folder per gebruiker, met een submap waarin de 'upload' gebruiker bestanden kan posten. Dit kan TS bijvoorbeeld doen door de upload gebruiker een gewone account te geven zodat deze naar de andere home folders mag bladeren en in een submap daarvan mag bewaren. Je zou ook iets kunnen doen met symlinks. Of met geneste home folders

Voor een flexibeler beheer van de user accounts kun je de authenticatie natuurlijk ook koppelen aan een directory systeem (LDAP).

Even in 't algemeen: als er gevraagd is naar een duurzame, 100% veilige en stabiele oplossing zou ik deze oplossing niet voor onbepaalde tijd 'erbij' blijven draaien op een server die in principe voor allerlei andere taken is bedoeld. Het is beter om het in overleg met de automatiseringsafdeling een eigen plaats te geven (hetzij virtueel of als losse server) en ervoor te zorgen dat een Linux systeembeheerder het systeem in in het beheerprogramma heeft en de veiligheidsupdates regelmatig bijwerkt. Let er daarbij ook op dat de beperkte GNU-commandoset in jailed home directories niet uit zichzelf wordt geupdate.

[ Voor 39% gewijzigd door benoni op 02-07-2007 18:56 ]

[Verwijderd]

Even tussen door, zit je bij Citybank?

[Razwer]

sorry voor de late reply, maar nee zit niet bij citibank werk uberhaupt niet voor een bank. Mijn bedrijf werkt voor een nederlandse bank, naja, het nederlandse kantoor. wereldwijd werken we met heel banken. Dit is een wereldwijd project.

[ Voor 26% gewijzigd door Razwer op 02-07-2007 12:19 ]

[BCC]

Razwer schreef op maandag 02 juli 2007 @ 12:18:
sorry voor de late reply, maar nee zit niet bij citibank werk uberhaupt niet voor een bank. Mijn bedrijf werkt voor een nederlandse bank, naja, het nederlandse kantoor. wereldwijd werken we met heel banken. Dit is een wereldwijd project.

Op de een of andere manier is mijn vertrouwen in banken net weer een stukje gedaald..:X