Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hello everybody
My questions here are not STRICTLY related to the dns-323 only, but they apply directly to this unit and the use of it. The subject is: FTP or SFTP?
It have a dns-323 since one week now, moved to FW 1.03, RAID1 on 2 250Gb HD's, loaded Fonz's fun_plug on it great stuff, thank you Fonz), started nfs3. Everything works great.
I want to give restricted access to files loading (only!) from internet (some directories in RO only, and one or several given directories in RW), to some friends and/or colleagues. I have also a family (internal users!!!) who can have access to more or less all files. The dns323 is located on my local network, behind a netgear router. Internal users use Linux (myself and "some" of the family) and Windows (the family).
I can achieve the "external access for file loading feature" using the native FTP server, or sftp (or both!)
- FTP: using FTP server is straightforward. Stock DNS323 allows to declare users and groups, and give access directories and RW/RO access independantly to each other. It is only needed to open "Inbound service" for FTP on the router. Nice thing with FTP is that users coming into the system cannot visit the parent directory. "Bad" thing with ftp is that logging id and password are NOT crypted, neither the transferred data.
Basically, this fits my needs (so, what's the problem?). I want to improve the security, internet community "tells me": switch to sftp, much more secure. OK, let's go:
- SFTP: I started dropbear/sftp-server from Fonz's fun_plug. Works great, no problem. What needs to be done on the router is forward port 22 (instead of 20/21). The good thing is SSH2 protocol (crypted data), basically more secure than standard FTP.
Now questions:
- allowing sftp from internet access implies that ssh is also accessible from internet: port 22 is forwarded, so, if you can connect through sftp, you can also connect through ssh, i.e log into my system! I know the password is crypted (good protection against "crackers"), but my colleagues/friends, to which I give access through sftp (and I would like ONLY sftp), can also open an "ssh" session with the same id/pswd. Am I right? For me, this is a lack of security. Is there any way to prevent this?
- once connected through sftp, parent directory is also accessible! So, any connected user can have a look "up" in the directory tree, which is not the case with standard FTP. I know that Unix file permissions can be used to solve this, but it is a headache when you have local users (which can access everything) and "external" users and groups which have only "restricted access". Is there a way to configure sftp so that "parent" directory is NOT accesible ("à la" FTP)?
Thanks in advance.
Offline
Two ideas (haven't tried myself):
dkl wrote:
can also open an "ssh" session with the same id/pswd
/etc/passwd contains the users' default shells. If you set it e.g. to "/bin/false" for your remote users, it should prevent them from gaining shell access.
dkl wrote:
once connected through sftp, parent directory is also accessible!
A common approach to prevent this is to use a chroot. It's not that easy to set up, though, and probably interferes with local ssh access.
Offline
Thanks a lot for your fast answer Fonz.
Actually, I had tried yesterday to suppress the /bin/sh from the /etc/passwd file, but it was replaced each time by the default value. I will try "/bin/false" instead this evening (I am at work for the moment...)
Considering the second point, I have found at "http://mysecureshell.sourceforge.net/fr/confman.html" (sorry, that's a french site) the use of "StayAtHome true", to prevent from the possibility to go up. This is related to "MySecureShell" with a config file in "/etc/ssh/sftp_config". By the way "VirtualChroot true" allows also to make a chroot. Is there a similar config file (where is it?) and entry for our sftp-server?
Offline
Hum...Does not seem to work. Any string I put in /etc/passwd is replaced at boot time by "/bin/sh". I've tried with /bin/false (which is an existing link), an empty string, and even /bin/dummy which I have created as an empty file.. No chance... No solution for the moment...
Offline
dkl wrote:
Any string I put in /etc/passwd is replaced at boot time by "/bin/sh". I've tried with /bin/false (which is an existing link), an empty string, and even /bin/dummy which I have created as an empty file.. No chance... No solution for the moment...
Try the web interface after you made changes. This maybe makes the firmware save your changes as well. Or store your version somewhere on disk and add a funplug script to copy it into /etc.
Also, it's not working with /bin/false, because I intentionally made dropbear ssh ignore the shell setting ;-)
Still two options:
1. A non-existent home directory works
2. Remove "-l ${BINDIR}/sh" option in fun_plug.d/start/dropbear.sh
Offline
Yes, the last one suits me, and it works. You can log in through SSH but get no prompt and can't do anything. I don't normally need myself to log in from internet, so it's OK for me. Option 1 is not suitable (did not try) because I think that if I enter a wrong directory, sftp connexion will also fail (at least, won't come into the wanted directory).
Now it's OK for SSH.
Could you explain me in a few words (or give me a link) how I could do a chroot (to prevent from the possibilty to go up when connected in SFTP? ) Where is sftp-server exactly located here? In dropbear executable? No chance to get a sftp.conf somewhere?
Offline
Isn't this what scponly is for? I found it on the wiki.
http://sublimation.org/scponly/
Last edited by kruzes (2007-06-21 23:58:24)
Offline
If I understand the Wiki, what I have to do to "secure" my SFTP access, is install a Debian Sarge (http://dns323.kood.org/howto:chroot_debian), and follow the steps described in "http://dns323.kood.org/howto:securing_sftp". Am I right? Can I have, at the same time, my current fonz's fun_plug running, AND Debian Sarge's one?
thanks
Offline
dkl wrote:
If I understand the Wiki, what I have to do to "secure" my SFTP access, is install a Debian Sarge (http://dns323.kood.org/howto:chroot_debian), and follow the steps described in "http://dns323.kood.org/howto:securing_sftp". Am I right? Can I have, at the same time, my current fonz's fun_plug running, AND Debian Sarge's one?
Yes, that's what it says, and yes I believe you can.
My sugestion, though, was more for you to have a look at scponly itself (http://sublimation.org/scponly/). It is capable of chrooting itself (there's really no "need" for jailkit at all), and I have every reason to believe it would work fine with dropbear and fonz's fun_plug. You'd just have to compile it and try it out.
Obviously, you can always do what I do, and use debian, which makes all this easier, but that's a totally different philosophy (I thing 64MiB RAM is more than enough, others might disagree).
Offline
I have found a good (I think) alternative to this: I have compiled MySecureShell in the "etch" environment, and it works fine. No need for jailkit, as sftp-server in MySecureShell does not allow to "visit" parent directory (this is configurable in /etc/ssh/sftp-config). I have not yet completed a full installation from scratch, but I'm confident it's quite straightforward. MSS needs only open_ssh, which is easily installed on debian etch:
- apt-get install ssh
- dowload MSS from source forge
- configure - make - make install (no problem)
- sftp-verif to check
- declare user "toto" with "adduser --home /home/toto --shell /bin/MySecureShell toto" and your done!
- Connection (login) through ssh is not allowed, only sftp. And sftp won't let you go else where needed. Nice isn't it?
Offline
fonz and everyone else:
Is there any easy (or atleast reliable) way to parse out the contents of the shell field in /etc/passwd so that dropbear launches that instead of "-l ${BINDIR}/sh" to the users logging in through ssh?
Or could I add a request for next fun_plug to add an option to dropbear to not ignore the shell setting?
I have many friends using the ftp server and their password security level is rather low so I don't want to allow ssh shell access for them, but I must have it myself... and by adding illegal home directories, they can't log in through ftp...
Best regards
Offline
saltisol wrote:
fonz and everyone else:
Is there any easy (or atleast reliable) way to parse out the contents of the shell field in /etc/passwd so that dropbear launches that instead of "-l ${BINDIR}/sh" to the users logging in through ssh?
Have you tried removing the "-l ${...}/sh" option from dropbear?
Offline
Based on fun-plug 0.3, from fonz - thanks, I have experimented a bit on a chroot environment setup for SSH and SFTP clients in the natives environment (not debian chrooted).
A few comments before you start reviewing my script:
* It is intended to be located in .../fun_plug.d/start folder and it is intentional named zz_.. to ensure it to be loaded last by fun_plug, because it needs unfsd started first.
* By doing mount –t nfs, control of RO and RW access gets easy. I just uses two folders, temporary and readonly, which “links” back to the files on real system.
* The .../start/dropbear.sh is executed from this script. The idea is to create an add-on to the fun_plug, but the actual implementation ended up being a bit redundant.
.../start/zz_JAILdropbear.sh:
#!/bin/sh RSAF=${ETCDIR}/dropbear/dropbear_rsa_host_key DSAF=${ETCDIR}/dropbear/dropbear_dsa_host_key PIDF=${LOGDIR}/dropbear.pid LOGF=${LOGDIR}/dropbear.log JAILDIR=/tmp/jail dropbear_start() { if [ ! -x "${FUNPLUGDIR}/start/dropbear.sh" ]; then chmod a+x ${FUNPLUGDIR}/start/dropbear.sh if [ ! -d "${ETCDIR}/dropbear" ]; then mkdir -p ${ETCDIR}/dropbear fi if [ ! -e /dev/random ]; then mknod /dev/random c 1 8 fi if [ ! -e "$DSAF" ]; then echo "Generating DSA host key..." ${BINDIR}/dropbearkey -t dss -f ${DSAF} fi if [ ! -e "$RSAF" ]; then echo "Generating RSA host key..." ${BINDIR}/dropbearkey -t rsa -f ${RSAF} fi if [ ! -e "/dev/ptmx" ]; then mknod -m 0666 /dev/ptmx c 5 2 fi if [ ! -d "/dev/pts" ]; then mkdir -p /dev/pts fi mount | grep devpts 1>/dev/null 2>/dev/null if [ $? -ne 0 ]; then mount -t devpts devpts /dev/pts fi # sftp-server: /dev/null must be writeable chmod a+w /dev/null # need /usr/bin/scp # http://dns323.kood.org/forum/t529-without-password.html if [ ! -e /usr/bin/scp ]; then ( cd /usr/bin; ln -s ${BINDIR}/scp ) fi mkdir -p $JAILDIR mkdir -p $JAILDIR/tmp mkdir -p $JAILDIR/home/ftp mkdir -p $JAILDIR/usr/bin mkdir -p $JAILDIR/lib mkdir -p $JAILDIR/bin mkdir -p $JAILDIR/etc mkdir -p $JAILDIR/dev mkdir -p $JAILDIR/proc mkdir -p $JAILDIR/mnt/HD_a2/fun_plug.d mount --bind /lib $JAILDIR/lib mount --bind /bin $JAILDIR/bin mount --bind /etc $JAILDIR/etc mount --bind /dev $JAILDIR/dev mount --bind /dev/pts $JAILDIR/dev/pts mount --bind /proc $JAILDIR/proc mount --bind /mnt/HD_a2/fun_plug.d $JAILDIR/mnt/HD_a2/fun_plug.d mkdir -p $JAILDIR/home/ftp/readonly mkdir -p $JAILDIR/home/ftp/temporary mount -o ro -t nfs 192.168.1.10:/mnt/HD_a2/readonly $JAILDIR/home/ftp/readonly mount -o rw -t nfs 192.168.1.10:/mnt/HD_a2/temporary $JAILDIR/home/ftp/temporary chmod a+x ${FUNPLUGDIR}/start/dropbear.sh echo "calling dropbear starter ..." #${BINDIR}/dropbear -d ${DSAF} -r ${RSAF} -P ${PIDF} -E -l ${BINDIR}/sh 1>${LOGF} 2>&1 & ${BINDIR}/chroot $JAILDIR ${FUNPLUGDIR}/start/dropbear.sh chmod a-x ${FUNPLUGDIR}/start/dropbear.sh else echo "ERROR: ${FUNPLUGDIR}/start/dropbear.sh is executable" fi } dropbear_stop() { killall dropbear sleep 10 umount $JAILDIR/home/ftp/readonly umount $JAILDIR/home/ftp/temporary umount $JAILDIR/mnt/HD_a2/fun_plug.d umount $JAILDIR/proc umount $JAILDIR/dev/pts umount $JAILDIR/dev umount $JAILDIR/etc umount $JAILDIR/bin umount $JAILDIR/lib #rm -r $JAILDIR } dropbear_status() { if [ -n "$(pidof dropbear)" ]; then echo "running" else echo "stopped" fi } case "$1" in stop) dropbear_stop ;; restart) dropbear_stop sleep 1 dropbear_start ;; status) dropbear_status ;; start|'') dropbear_start ;; *) echo "Usage: $0 start|stop|restart|status" ;; esac
If you need another dropbear demon in a not chroot’ed environment as well, I think you can start an additional dropbear (e.g. dropbear2222.sh) demon running concurrently, just on another port (-p 2222) and on separate logfiles. This was what I saw by my initial tests.
I have set a password LOPT="-l ${BINDIR}/login" in .../fun_plug.d/start/telnetd.sh to ensure SSH clients can start a telnet session and easy be root. I replicate the password from admin to root by setrootpwd.sh, see below. If I change the admin password on the web interface, I need to restart to update the root password.
.../start/setrootpwd.sh
#!/bin/sh # Desc: Dublicate user admin password to root # Read the admin password line rootpwd=`grep -e "^admin:" /etc/shadow` # Replace user name admin by root, but keep admin properties rootpwd=root:${rootpwd#admin:} # Start creating new shadow file echo $rootpwd > /tmp/shadow # Append the remaing users, but remove root if already exist grep -v -e "^root:" /etc/shadow >> /tmp/shadow # Clear work parameter unset rootpwd # Store new shadow file mv -f /tmp/shadow /etc/shadow
I got a security concern. From the SSH session or via the SSH tunnel my home LAN is accessible, like router, media center, PCs, VoIP adapter, etc. Password on theses devices is mandatory. Can the dropbear options below protect my LAN?
-j Disable local port forwarding
-k Disable remote port forwarding
Btw. an associated subject. I have limited the ip addresses on the internet, which are able to access my port 22 (SSH) on my router. If you like to go on this path and got a linux based home router, the command iptables is a command to look into.
I hope you will review this and add you comments to my fun.
Last edited by FIB (2007-08-21 23:07:49)
Offline
Hye,
I think I have another chroot FTP problem, but maybe it is related. I searched google but did not find a solution yet.
I have a CH3SNAS with Fonz fun_plug 0.3 and Etch. When I make a SFTP connection to my CH3SNAS I am able to connect. I can read every directory on the hardisk, writing is something else. Outside the Etch directories I can also write. But once inside the Etch directories I am not able to write anymore.
First I thought my userrights were not OK. At the lowest level I have a /etc/passwd and on the Etch level I also have a /etc/passwd. So on the Etch level I also added the same user and password as I login with SFTP, but still no improvement.
I asked a friend of mine who also has a CH3SNAS, but he also has the same problem. What do we do wrong? Is there someone who can help us out?
Offline
Hi guy's!
I have a ch3snas for a few weeks now and I'm trying out all the stuff thats possible with fun_plug.
Unfortunately I cant find a lot about dropbear's ssh as I want to use it to sftp and use remote shell.
As security I wanted to set it up to only accept connections with a key (with or without extra password) as I now have on my windoze server, but I cant find exactly how to set that up.
Done so far:
- installed bugbear
- created a user
- created ~/.ssh dir for that user as in http://dns323.kood.org/forum/t529-witho … rd....html except I skipped the part with the home dir, as I only want that user to be able to log in with the give key and not the admin/root user.
- read any thread containing the words dropbear, dropbearkey, openssh
- Questions still unanswered: how do I make the correct key for the user as accepted key, how do I make a matching key for the (putty) client and how do I force dropbear/fun_plug/nas to only accept connections with that key only.
I lack a lot of experience so it could well be that this question is sooooo simple. I know its possible with openssh which I set up years ago on my windoze box following a lot of google pages and helpme's.
Is this possible with dropbear on this box?
Any link available to help me learn how to do it myself?
Thanx in advance!!
P.S.: anybody got lighttpd with gallery/jhead/etc working without chrooting it and be able to upload large pictures?
Offline
This is what I used to do on my Linux server. Just make a new shell that points to a dead end, a folder with a simple webpage saying under construction works. Haven't set this up in years but the directions are easy to find on the web or Debians site if I recall correctly.
I'll be looking into this again when I have time but spring, after tax season, is the earlyest I'll have a chance to play.
fonz wrote:
Two ideas (haven't tried myself):
/etc/passwd contains the users' default shells. If you set it e.g. to "/bin/false" for your remote users, it should prevent them from gaining shell access.
Offline