On Saturday 13 May 2017 23:58:17 R0b0t1 wrote: > On Wed, May 3, 2017 at 1:40 AM, Mick <michaelkintz...@gmail.com> wrote: > > On Monday 01 May 2017 22:36:00 Nils Freydank wrote: > >> On Sat, 30 Apr 2017 19:04:06 +0200 Andrew Savchenko wrote: > >> > [...] > >> > I fail to see why FTP needs to be replaced: it works, it is > >> > supported, it is secure when used with care, it is damn fast. > >> > >> I’ll just drop the somewhat popular rant “FTP must die“[1] and a > >> follow-up > >> discussion about it[2]. IMHO the main reasons are missing data integrity > >> and authentication security issues. The latter one can be solved with > >> FTPS[3] - but honestly I never saw FTPS somewhere actually used in the > >> wild.> > > I'm not sure what you mean "used in the wild". I use lftp to connect via > > ftps with a number of webservers for updates and backups on a daily > > basis. Some of the connections are scripted. > > > >> [1] http://mywiki.wooledge.org/FtpMustDie > >> [2] https://news.ycombinator.com/item?id=11251907 > >> [3] i.e. FTP over SSL/TLS (not to mix up with SFTP, which comes from the > >> SSH family) > >> > >> Greetings, > >> Nils > > That was an interesting read. The only RFC as bad as FTP's that I know > of might be IRC's. > > On Sat, May 13, 2017 at 8:48 PM, lee <l...@yagibdah.de> wrote: > > Kai Krakow <hurikha...@gmail.com> writes: > >> Am Sat, 29 Apr 2017 20:30:03 +0100 > >> > >> schrieb lee <l...@yagibdah.de>: > >>> Danny YUE <sheepd...@gmail.com> writes: > >>> > On 2017-04-25 14:29, lee <l...@yagibdah.de> wrote: > >>> >> Hi, > >>> >> > >>> >> since the usage of FTP seems to be declining, what is a replacement > >>> >> which is at least as good as FTP? > >>> >> > >>> >> I'm aware that there's webdav, but that's very awkward to use and > >>> >> missing features. > >>> > > >>> > What about sshfs? It allows you to mount a location that can be > >>> > accessed via ssh to your local file system, as if you are using > >>> > ssh. > >>> > >>> Doesn't that require ssh access? And how do you explain that to ppl > >>> finding it too difficult to use Filezilla? Is it available for > >>> Windoze? > >> > >> Both, sshfs and scp, require a full shell (that may be restricted but > >> that involves configuration overhead on the server side). > > > > I wouldn't want them to have that. > > > >> You can use sftp (FTP wrapped into SSH), which is built into SSH. It > >> has native support in many Windows clients (most implementations use > >> PuTTY in the background). It also has the advantage that you can > >> easily restrict users on your system to SFTP-only with an easy > >> server-side configuration. > > > > From what I've been reading, sftp is deprecated and has been replaced by > > ftp with TLS.
MSWindows does not do ftps, only unencrypted ftp. The solution is to use a MSWindows ftp client, life filezilla. If the users can be trained, or have their PCs set up with Filezilla bookmarks for required connections to the ftp server, then this problem can be overcome. > >>> > Also samba can be a replacement. I have a samba server on my OpenWRT > >>> > router and use mount.cifs to mount it... > >>> > >>> Does that work well, reliably and securely over internet connections? > >> > >> It supports encryption as transport security, and it supports kerberos > >> for secure authentication, the latter is not easy to setup in Linux, > >> but it should work with Windows clients out-of-the-box. > >> > >> But samba is a pretty complex daemon and thus offers a big attack > >> surface for hackers and bots. I'm not sure you want to expose this to > >> the internet without some sort of firewall in place to restrict access > >> to specific clients - and that probably wouldn't work for your scenario. SMB is being patched on a regular basis by MS to improve its security - the recent global Wannacry attack being a case in point. I would think SMB is the most attacked protocol on a daily basis and trying to configure a SMB server from scratch, when an ftp server is already available would not be the wisest investment of time. > > At least it's a possibility. I don't even know if they have static IPs, > > though. > > > >> But you could offer access via OpenVPN and tunnel samba through that. > > > > I haven't been able yet to figure out what implications creating a VPN > > has. I understand it's supposed to connect networks through a secured > > tunnel, but what kind of access to the LAN does someone get who connects > > via VPN? Besides, VPN is extremely complicated and difficult to set > > up. I consider it an awful nightmare. > > > > Wireguard seems a lot easier. I hadn't heard of its dev, Jason A. Donenfeld, who has trademarked the Wireguard name and website, until I visited the Wireguard website. I don't know how many people are part of the team, but Jason appears to be the only person answering questions on the M/L. The website advises that wireguard is work in progress and therefore not to be relied on for production environments. > I had some problems setting up OpenVPN that were solved by using > per-client public keys. That seems to be the best supported > configuration (as well as the most secure). Windows-side using > OpenVPN-GUI is very easy. > > OpenVPN tends to have poor bandwidth due to overhead, but that may be > in large part due to my connection. OpenVPN is not the most efficient VPN implementation for connections to a server because it is not multithreaded and also because unlike IKE/IPSec it operates in userspace, not in kernelspace. If you have more than one client connecting to the server at the same time you will need to set up multiple instances with different ports or different protocols. With IKE/IPSec you don't. MSWindows PCs come with IKEv2 natively so they can be configured to use it without installing additional client applications. A VPN connection will expose each endpoint's LAN to the other and therefore additional firewall configurations could be required. > >> By that time, you can as easily offer FTP, too, through the tunnel > >> only, as there should be no more security concerns now: It's encrypted > >> now. > > > > The ftp server already doesn't allow unencrypted connections. > > > > Now try to explain to ppl for whom Filezilla is too complicated how to > > set up a VPN connection and how to secure their LAN once they create the > > connection (if we could ever get that to work). I haven't been able to > > figure that out myself, and that is one of the main reasons why I do not > > have a VPN connection but use ssh instead. The only disadvantage is > > that I can't do RDP sessions with that --- I probably could and just > > don't know how to --- but things might be a lot easier if wireguard > > works. If the users are helpless then you may be better configuring a VPN tunnel between their Internet gateway and the server, so they can access the server as if it were a local share, or using the built in ftp client that MSWindows comes with. SMB will work securely in this case too. > >> OpenVPN also offers transparent compression which can be a big > >> plus for your scenario. > > > > Not really, a lot of data is images, usually JPEG, some ZIP files, some > > PDF. All that doesn't compress too well. > > > >> OpenVPN is not too difficult to setup, and the client is available for > >> all major OSes. And it's not too complicated to use: Open VPN > >> connection, then use your file transfer client as you're used to. Just > >> one simple extra step. > > > > I'm finding it a horrible nightmare, see above. It is the most > > difficult thing you could come up with. I haven't found any good > > documentation that explains it, the different types of it, how it works, > > what to use (apparently there are many different ways or something, some > > of which require a static IP on both ends, and they even give you > > different disadvantages in performance ...), how to protect the > > participants and all the complicated stuff involved. So far, I've > > managed to stay away from it, and I wouldn't know where to start. Of > > course, there is some documentation, but it is all confusing and no > > good. > > Feel free to start a thread on it. As above, I recommend > one-key-per-client and running your own CA. For secure connections you will have to set up CA and TLS keys with any option. Even ftps - unless the ftp server is already configured with its TLS certificates. > > The routers even support it. In theory, it shouldn't be difficult to > > set up, but that's only theory. They do not have any documentation as > > to how to protect the connected networks from each other. I could > > probably get it to work, but I wouldn't know what I'm doing, and I don't > > like that. > > Routers often ship with extremely outdated packages. Highly recommend > using purpose-built "appliances" for this. > > > I admit that I don't really want to know how VPN works because it's > > merely an annoyance and not what I need. What's needed is a simple, > > encrypted connection between networks, and VPN is anything but that. > > > > Wireguard sounds really simple. Since I need to set up a VPN or > > VPN-like connection sooner than later, I'm considering using it. > > WireGuard seems to solve every major exception that could be had with > existing transport security solutions. I have been keeping my eye on > it ever since noticing it in eix-sync's output. I suggest the simplest solution is to install Filezilla on client PCs and preconfigure an ftps connection to the server for them. Then all they have to do is point and click followed by drag and drop. Someone will have to make it their job to keep all these client PCs Filezilla installations updated, if they can't do it themselves. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
