[OpenBSD 4.1-stable] OpenSSH 6.4: sftp beveiligen

[cafemartin]

Hoi,

Ik heb kort geleden mijn eerste openbsd installatie gedaan. heel tof en leerzaam. De machine moet een gateway worden en als sftp server mijn ftp server gaan vervangen. Met die sftp server ben ik nu bezig uit te zoeken hoe je dat het beste kan opzetten en beveiligen. Ik hoop dat ik genoeg huiswerk heb gedaan om dit zo te kunnen posten, er zijn dagen zoek- en leeswerk aan vooraf gegaan.

De bedoeling is een systeem waarop vanaf het wan alleen een bepaalde gebruiker, zeg 'sftponly', kan inloggen met gebruikersnaam en wachtwoord en vervolgens bestanden kan neerzetten en weghalen.

Voor zover ik begrijp is het onvermijdelijk om met adduser een systeemaccount aan te maken en bestaat de kunst erin die daarna alle rechten te ontzeggen die het niet nodig heeft. Ik zit hier al een tijdje op te studeren, maar aangezien ik met *nix nog een redelijke n00b ben, ontbreekt het overzicht.

Verschillende mogelijkheden die ik tegen ben gekomen tijdens het grasduinen:

restricted shell:
-scponly
-rssh
Een uitgebreide handleiding voor het implementeren van scponly voor sftp in solaris 9 en red hat 9 vond ik hier.
-Uit het archief van een ssh nieuwsgroep leerde ik dat de volgende functie in openssh zit sinds 4.4

code:

Match User sftponly
    AllowTcpForwarding no
    X11Forwarding no
    ForceCommand /usr/libexec/sftp-server -l INFO

Nu ben ik zo benieuwd naar jullie ervaringen en ideeën hierover. Wat is degelijker, wat is makkelijker te onderhouden (ook in verband met de halfjaarlijkse upgrades), wat is het minst foutgevoelig (voor scponly en rssh zijn nog geen packages uit en de code ervan is niet zo streng geaudit als de rest van het systeem).

Alvast bedankt voor jullie reacties!

[Verwijderd]

Begin idd met een sftp only shell instellen, daarmee voorkom je dat ze een "normale" login krijgen op je bak. Zie ook dit topic, wat boordevol staat met ssh security truukjes =)

[p@dd0]

In de Mailing list ARChives is een hoop te vinden.

Je aanmelden op [e-mail] is ook aan te bevelen, komt een hoop info voorbij. Zie hiervoor de OpenBSD site. Leer alleen wel beter te zoeken voor je een vraag stelt!

Meh, en ik moet de hele SP lezen...

[ Voor 6% gewijzigd door p@dd0 op 05-06-2007 13:30 ]

[Sir Isaac]

Ik heb onlangs rssh op een machine gezet nadat ik had gemerkt dat een apparte user account met /bin/false als shell niet werkte voor sftp. rssh werkt prima, met scponly heb ik geen ervaring.

[cafemartin]

Bedankt!

@ r3boot: handige link! ik heb er een checklist van gemaakt:

• rssh (of andere beperkte shell)
• met firewall en tcpwrappers per ip toegang verlenen (niet praktisch voor mij, ik wil er vanaf iedere plek bijkunnen, óók vanaf niet-vertrouwde clients (speciale maatregelen?)
• Root-logins uitschakelen (check)
• Maximaal aantal pogingen voor je wachtwoord op 1 zetten (te doen, nu max 3 x voordat je wordt toegevoegd aan de bruteforce table)
• SSH op een andere poort dan 22 draaien (check)
• IgnoreRhosts op yes (controleren)
• AllowUser/AllowGroup in sshd_config (komt, icm Match & ForceCommand
• alleen sshv2 (check, ook voor clients)
• gebruik sudo (check)
• UsePrivilegeSeparation aanzetten (controleren: standaard in obsd?)
• Banner (netjes)
• bruteforce en expiretable ingesteld in pf (check)
• volgt: snort
• volgt: monitoring (tripwire ed.)

Ik ga me nog wat verder verdiepen in de combinatie van Match en
Forcecommand /usr/libexec/sftp-server -l INFO Ik ben erg benieuwd naar de precieze werking ervan.

@ Sir Isaac: Ik denk dat ik eerst rssh ga proberen, het lijkt iets aantrekkelijker. Dit is een link naar een post van de maker uit MARC.info (over rssh en scponly).

Hij rept óók over chroot, terwijl het bijvoorbeeld in de post die r3boot noemde (Automatisch inloggen met ssh) weer helemaal niet ter sprake wordt gebracht. In de obsd man page van chroot staat de waarschuwing "There are ways for a root process to escape from the chroot jail." Valt dat te voorkomen, ook bij PrivilegeSeparation is er toch nog een root process? Verder begrijp ik uit die manpage dat zo'n user nog steeds lees en zoekrechten moet hebben op de bovenliggende directories. dus als /home/sftponly dan kan gebruiker sftponly nog steeds de namen van de overige directories en bestanden in /home lezen? Lijkt niet ideaal.


edit:

• "keys genereren en naar authorized_keys catten"

uit de lijst gehaald: in dit geval is een wachtwoord juist wel wenselijk.

[ Voor 5% gewijzigd door cafemartin op 05-06-2007 15:59 ]

[Verwijderd]

waarom gebruik je geen combinatie van keys + password ? Keys zijn echt een sterke vorm van beveiliging.

[deadinspace]

cafemartin schreef op dinsdag 05 juni 2007 @ 15:48:
• ik wil er vanaf iedere plek bijkunnen, óók vanaf niet-vertrouwde clients (speciale maatregelen?)

In het gelinkte topic stond ook iets over OPIE one time passwords, dat is misschien handig om vanaf niet-vertrouwde clients in te loggen?

• Maximaal aantal pogingen voor je wachtwoord op 1 zetten (te doen, nu max 3 x voordat je wordt toegevoegd aan de bruteforce table)

1 poging mis en dan al gefirewalled? Lijkt me onpraktisch

• SSH op een andere poort dan 22 draaien (check)

Dat is security through obscurity. Kan alsnog nuttig zijn, maar realiseer je dat wel

• gebruik sudo (check)

Ben ik zelf niet zo heel erg van gecharmeerd, en ik zie niet in hoe dat helpt bij security. Liever gewoon su icm de wheel group (standaard op OBSD) als je admin-taken wil verrichten. Sudo staat meestal geconfigureerd om het password van de gebruiker te accepteren, waardoor nog maar 1 wachtwoord nodig is voor inloggen + root. Zeker icm access van untrusted hosts (keyloggers) is dat minder veilig.

Ok, als iemand jouw user heeft, dan loop je sowieso een groot risico, ivm eventuele local root exploits. Ook is de kans dat zo iemand het root password kan snoopen dan vrij groot (denk aan een trojaned 'su' in je PATH zetten). Maar toch

"There are ways for a root process to escape from the chroot jail." Valt dat te voorkomen

Kort door de bocht - als dat makkelijk te voorkomen was dan hadden ze dat wel gedaan

Ik meende overigens dat OpenBSD sterkere chroot jails had dan GNU/Linux chroots, waar een root process relatief makkelijk uit kan breken, maar blijkbaar valt dat een beetje tegen?

ook bij PrivilegeSeparation is er toch nog een root process?

Ja, dat klopt. Met PrivilegeSeparation gebeurt alleen het hoogstnoodzakelijke in een root process, de rest gebeurt in een user process. Dit verkleint de kans op een root exploit in ssh - hoe minder je als root doet, hoe minder als root exploitable zou kunnen zijn.

Verder begrijp ik uit die manpage dat zo'n user nog steeds lees en zoekrechten moet hebben op de bovenliggende directories. dus als /home/sftponly dan kan gebruiker sftponly nog steeds de namen van de overige directories en bestanden in /home lezen? Lijkt niet ideaal.

Dat is vrij simpel op te lossen door /home go-r te maken. Users kunnen dan niet zien wat er in /home staat, maar entries in /home waarvan ze de naam weten (zoals hun homedir) kunnen ze wel gebruiken.

Overigens... Is het zo'n probleem als users kunnen zien welke andere users er op het systeem zijn? Dat kunnen ze sowieso wel in /etc/passwd.