I’m realtively new to Linux and have used Mint for a short while, but also like Leap15.2 a lot and may start using it in preference. I am also a novice when it comes to networking.
I have 2 computers at home and wish to simply transfer files between them on my home/local network. As I won’t be sending any files externally over the internet, do I still need to be secure and set up with SSL/TLS/Certifcates? If I set up with no security, will that make me vulnerable from outside, even though I’m just using a home network?
In Linux Mint (20), I set a server up using VSFTPD, secured it & created certificates - all worked well. Tried doing this in Leap 15.2 and have problems in connecting to the Yast 2 Server. I’ve narrowed this down to using SSL/TLS/Certifcates. Without them, I can connect & transfer files, but as soon as I go secure I can’t connect.
Ultimately, I’d like to be careful and secure everything as in Mint, but if I don’t need to then that’s fine.
I’ve gone through numerous tutorials on the web in setting up Yast Server, but nothing works for me when I go secure.
Is there a really good tutorial somewhere that I can use to set Yast Server and Firewall up if I need to make things secure on a home network?
BTW - the other home PC I connect to is Windows 10 with Filezilla Client.
well - if you use it only within your home network and have a NAT router already protecting you from the outside world you could just set the firewall to either “internal” or disable it completely (as anything able to connect to it would be just your other system) and maybe even use SMB instead of FTP(S) or SFTP so you can just mount it as network share in windows - which let’s windows SMB implementation let’s do the stuff and you won’t need neither FileZilla nor WinSCP. Otherwise you should prefer SFTP over FTP(S) and use WinSCP - it has a Commander like interface and just uses the already exposed SSH port. If you really want to go FTP it shouldn’t be hard to also go FTPS - but I honestly don’t really get it why you want to “secure” data transfer within your network if it’s protected by a NAT router - you could just go plain FTP or, as said, SMB - I don’t see the point using secure protocols when not using connections over unsecure channels.
Hi
The reason is ssh/scp/sftp requires no user config aside from enabling during install or enabling the service and open the service port all via YaST…
I’m aware of that - one reason why I do prefer it within my LAN - but the question wasn’t about why to use SSH/SFTP but rather why OP wants to use secured connections within her/his private lan which is most likely protected from the internet by a NAT router. So, for me there’s no reason why s/he bothers at all to try to set up FTPS when FTP without any security seem to be sufficient as no data are transported over insecure channels.
I may not have explained my query very well - so apologies for that - but cryptearth’s last post understood my meaning.
I’ve been having trouble setting up the FTP server securely and was wondering if I really needed to be concerned about this when all I’m doing is transferring files over a LAN at home while being behind a router supplied by my ISP.
Setting up the YaST FTP Server module without security works perfectly. Use security/certificates & I can’t connect. It isn’t that I want to set up with security over LAN, I just wondered if I was vulnerable if I didn’t.
As you can see, I’m a total network novice LOL.
Incidentally, I set up vsftpd on Mint with security and it worked first time. Guess I didn’t need to set up that way as it is also on the same LAN.
I think the security aspect comes from when I first transferred files over LAN on Windows. I followed a good YouTube tutorial on how to do this using Filezilla server & client & have gone the secure route since - which now seems unnecessary. As I was having so much difficulty setting Leap 15.2 up this way, it made me wonder if I really needed it. Still can’t understand how I had no problems setting vsftpd server on Mint, but have struggled with Leap when it comes to (unnecessary) security.
If you are using vsftpd, you must disable seccomp (seccomp_sandbox=NO) for SSL to work. As far as I understand some local OpenSSL patches in openSUSE conflict with seccomp filter as implemented by vsftpd.
I may have to be corrected, but as far as I understand the linked bug report it seems an issue with openssl in a chroot environment and how vsftpd uses it - very interesting how some unexpected behaviour arise with chroot and containers (like docker and such) - and in the end it was proven many times that even implementations of chroot and docker are insecure and hence using them is about as effective as not using them in the first place.
Anyway:
About why it might had worked on Mint and 15.1 but not on 15.2: Welcome to Linux. I as a “Windows kid” (I’m only closing in on 30 - so I consider myself fine when some “veteran” still calls me “kid”) always had and still do struggle with all that diversity. There so many different versions of what’s supposed to be same - as someone only ever knew half a hand full of OS (pretty much just 98 (first edition), XP and 7) and different architectures (once used a XP x64 as a once buddy of mine got a new system the 32bit version I was used to didn’t fully worked - and 7 wasn’t public released back then) I often get confused by things as simple as DEB based vs RPM based distributions and package managers. So, why it worked and now doesn’t? Could be any of about a million of reasons - only solveable with the combined power of the internet community. On Windows it would be easy 3 steps: OS version, DotNET version, “Did you checked your firewall?” - and most often it’s the very last one.
To give you an idea how complex this can get let me tell you this story:
As a hobbyist Java developer with interest of cryptography I’ve written a simple TLS server myself. As I was developing on Windows anything worked fine. As I tested it on an openSuSE machine for some strange reason it was slowed down to about the speed of a snail. It took me days and half a dozen forums and mailing lists to get this worked out with the combined knowledge of about 30 or so people: I made the “stupid” mistake to use a “strong” instance of the random generator. The way this works on Windows is simple to call the Windows Crypto API - which in turn only uses some rather fast hashing algorithms. On Linux on the other hand it makes a difference between reading from the blocking /dev/random or the non-blocking /dev/urandom. Java knows 4 modes:
SHA1 counter
seeding from /dev/random and getting next byte from /dev/random (that’S the one used for “strong” instances)
seeding from /dev/random only but getting next byte from /dev/urandom
seeding and next byte from /dev/urandom
The issue was that the machine wasn’t able to generate enough entropy so the read calls to /dev/random became blocking after a short while. As I made the mistake to not just use a small amount of bytes for the initial strong seed but also for every new random bytes (which there’re a lot in a TLS handshake) I used up all the systems entropy in about one or two handshakes and then had to wait for the system to build up enough entropy again to return the next random data. In fact, using up all of the system entropy, this slowed down anything else relied on high entropy /dev/random. After I fixed this issue to use option 3 to only get a very small amount of high entropy data to generate the initial seed and then only use either /dev/urandom or use that high entropy random generator to seed a second one using option 1 (which is considered “secure enough for TLS”) all went as planed.
What I like to explain by it: As you’re dealing with crypto stuff there’s quite a lot that can go wrong. Luckly many rather good crypto lib implementations have countermeasures to avoid potential threats when something does go wrong - like in your case. You want to enable some secure stuff - but something odd doesn’T work out the way it should - which in the end makes it fail all together rather then using weak attackable crypto - which, although annoying, is a good thing.
As for the overall question if you actually need to use crypto within your home LAN or if you put yourself in danger if you don’T - unfortunately the answer is “it depends”. If you only have two normal PCs I don’t see a problem, even when there’re mobile devices like your phone - as these are secure enough by themselves. But if you’re using IoT devices, which often come from vague chinese manufactures with dodgy firmware - it may be a good idea to shield against them going rogue.
As an example: I myself have only seven devices in my home network: three Windows PCs (although one is my laptop running win7, win10 and 15.1 in a multi-boot config), my phone, a small server (pcengines apu - similar to raspberryPi but using an AMD x86-64 chip instead of ARM) as well as my projector and my amplifier (although the latter two don’t really need network access it makes using them a bit more comfortable) - and I do use a combination of different stuff. To connect my Windows pcs I just use regular network shares, to connect to my 15.1 running server I use ssh and sftp.
Although I also could set up SMB and telnet on it the reason why I do not: It’s simply not worth the effort. I’m fine with using Putty and WinSCP. In fact, I have actually enabled the telnet server on my win7 systems, as well as the ssh server on the win10 one, so I can remotely access them (I use this a lot when I’m not home: my server is always up and I’m able to connect to it from the outside world (a very good reason to in fact use a secured protocol like ssh) - which then has some scripts to remotely start up my other machines by using wake-on-lan - but, as I also want to shut them down again after I finished my work I need some remote access like telnet or ssh to log into them to execute a shutdown command).
This is what I would recommend to you: Just use what ever seves your needs. If you don’t have to worry about dodgy chinese IoT stuff and have a router with a “NAT firewall” (yes, I know that’s not the correct term) you could go with what ever is the easiest to set up. But if you have devices you don’t trust it may be worth the effort to set up only secured connections (although I still would recommend SFTP over FTPS). Unfortunately that’s a “it depends” topic.
Use the official LEAP reference for setting up FTP Server. Be aware though that the YaST method sets up a relatively simple configuration that’s useful only for a very, very small business or home network. More advanced configurations are installed in the documentation installed by the FTP server package.
Long story short - Due my PC locking up when going into & coming out of sleep (separate thread for that) I ended up switching from Leap to Tumbleweed. As I no longer appear to have lock-up issues I’m sticking with Tumbleweed. Not entirely sure what the fix was, but hey ho . .
Since then, I can’t get Filezilla client to connect to the vsftpd server at all - even without encryption which would work previously. Below I’ve pasted the vsftpd config file and the error I get from Filezilla.
Would somebody mind taking a look to see what I’m missing and need to do please? I think the problem is with the config file & I’ve tried loads of different options from Googling etc, with no success - just different errors from Filezilla . . .
Using YaST Control Center under Network Services, I installed the FTP Server along with vsfpd & made a back up copy of the file
**
VSFTPD CONF FILE**
write_enable=NO
dirmessage_enable=YES
nopriv_user=ftpsecure
local_enable=YES
anonymous_enable=YES
anon_world_readable_only=YES
syslog_enable=YES
connect_from_port_20=YES
ascii_upload_enable=YES
pam_service_name=vsftpd
listen=NO
listen_ipv6=YES
ssl_enable=NO
dsa_cert_file=
pasv_min_port=30000
pasv_max_port=30100
anon_mkdir_write_enable=NO
anon_root=/srv/ftp
anon_upload_enable=NO
chroot_local_user=NO
ftpd_banner=Welcome message
idle_session_timeout=900
log_ftp_protocol=YES
max_clients=10
max_per_ip=3
pasv_enable=YES
ssl_tlsv1=YES
xferlog_enable=YES
When I try to connect via Filezilla client, this error is displayed -
FILEZILLA CLIENT ERROR
Status: Connecting to 192.168.1.110:21…
Status: Connection established, waiting for welcome message…
Status: Plain FTP is insecure. Please switch to FTP over TLS.
Status: Logged in
Status: Retrieving directory listing…
Command: PWD
Response: 257 “/home/bfg” is the current directory
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Response: 227 Entering Passive Mode (192,168,1,110,117,58).
Command: LIST
Response: 150 Here comes the directory listing.
Error: Connection closed by server
Error: Failed to retrieve directory listing
As previous, I’m not transferring files to WAN or internet. I’m behind a router supplied by an ISP and it’s firewall is active.
I just want to transfer files between 2 PCs at home - one upstairs and one downstairs. As such, setting up SSL and certificates isn’t needed and I’m the only user.
I install an Samba server and I mount a CIFS and use the Linux File Program (in MATE it is caja) and just drag and drop them between the 2 windows.
You need SMB an NMB to run Samba.
Samba can be enabled at boot or started and stopped as needed. I am behind a firewall and Samba is on my second ethernet adapter so it is not on the WAN at all. (yes, I am paranoid about access to my files).
Finally got this working so thought I would post back in case it is of use to someone else in the future. I tried the above suggestion of using Samba, but failed to get that to work either.
I went back through this thread and tried arvidjaar’s suggestion regarding the use of seccomp_sandbox=NO
I added this single line to the config file as it wasn’t there and now the Filezilla client on my Windows PC connects to Tumbleweed and transfers files. I didn’t expect it work as this time, I haven’t used SSL. I confirmed it by removing the line from the config file and the client failed to connect again. Once the line was back in place, all is good.
I now need to find out what seccomp_sandbox means and does!