Talk:Very Secure FTP Daemon

/etc/hosts.allow

Could one add a column that explains the security in /etc/hosts.allow like there is in the ssh wiki page:

/etc/hosts.allow

# let everyone connect to you
vsftpd: ALL

# OR you can restrict it to a certain ip
vsftpd: 192.168.0.1

# OR restrict for an IP range
vsftpd: 10.0.0.0/255.255.255.0

# OR restrict for an IP match
vsftpd: 192.168.1.

--Burra 17:11, 11 June 2008 (EDT)

/etc/hosts.allow / deny

Starting vsftpd from xinetd and solo tells me that the /etc/hosts.allow / deny are only used when the vsftpd is started from xinetd.

—This unsigned comment is by Raca (talk) 17:21, 29 July 2008‎ (UTC). Please sign your posts with ~~~~!

My addition about "PAM with 'virtual users'"

I don't even know if I've done it the right way, and its the first time ever I do something like this. Hence please give feedback on the quality of it, and let me know if I've done some mistakes.

-- KimTjik

If your intention was to create a hashed password user database to do the PAM authentication then it is not correct. db_load does not handle password hashing by itself, it merely creates a binary database file from the input. A user needs to specify what type of database dump the input to db_load is (hashed, Btree, queue or recno). To show that db_load does not hash passwords you can use the 'strings' command on your database file. It will translate the binary file back into strings and you will be able to read your passwords (password and username have switched places though). For instance place the following into test.txt

user1
password1
user2
password2

Then do

# db_load -T -t hash -f test.txt test.db
# strings test.db

this should exactly print the following on your command line

password1
user1
password2
user2

Thus no password hashing has happened and Someone that obtained the right to access the database could thus read all passwords.

Neburski (talk) 19:05, 7 December 2013 (UTC)

As you can see I've updated this section. As I wrote above it's mainly because PAM doesn't provide pam_userdb.so anymore. I choose this method because it's not complicated and at the same time I think it addresses the issue about security. -- KimTjik (talk) 22:04, 27 February 2014 (UTC)

The information that `pam_userdb.so` is not provide by pam anymore seems to be outdated.

On the other hand the suggested alternative `pam_pwdfile.so` is unmaintained since 2021.

I suggest rewriting this section with `pam_userdb.so` setup. Fnin (talk) 13:11, 16 January 2024 (UTC)

I was mistaken. pam_userdb is not included in arch linux, so it makes sense to use pam_pwdfile instead in this case. Fnin (talk) 13:17, 16 January 2024 (UTC)

Examples for configuring vsftpd

I'm running a private ftp-server here which has some additional features which might not be needed for everyone, like PAM with postgres as backend, IP-based-rules and per-user-settings. Would it make sense to add instructions for this to the wiki, or is it too special?

--IncredibleLaser 08:53, 31 January 2009 (EST)

ip_conntrack_ftp module

I found that I need to load ip_conntrack_ftp module so I can connect to the server in Passive Mode and with iptables running.

If iptables is configured in a stateful firewall manner, then some connections in FTP won't be allowed. I found that loading the ip_conntrack_ftp module on the kernel workder.

--Jstitch 17:35, 1 June 2011 (EDT)

Iptables rule in relation to Simple Stateful Firewall article.

I had followed previously `Simple Stateful Firewall` article to protect the server. It is also mentioned in this article (I mean that Simple Stateful Firewall is mentioned in the vsftpd article). However I was not able to allow incoming ftp request implementing suggested entry `iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT` instead I did `iptables -A TCP -p tcp --dport 21 -j ACCEPT` and this allowed for an incoming ftp connection. Which config line is right / more appropriate? Soocki (talk) 21:23, 10 December 2018 (UTC)

To me this reads as if you may have missed the extra steps to get connection tracking to work with kernel >4.7 in Very Secure FTP Daemon#Configuring iptables, but I'm not a user of the daemon so I can't tell what works here. --Indigo (talk) 23:48, 10 December 2018 (UTC)

All I had to do to allow ftp traffic through the Simple_stateful_firewall was `iptables -A TCP -p tcp --dport 21 -j ACCEPT`. I was able to pull and put files on the server. The commands mentioned in this artictle did not work. It is quite misleading the way Simple_stateful_firewall article is directly mentioned and right after some command is given yet to extend functionalities of Simple_stateful_firewall another command can (must/should?) be used. Soocki (talk) 10:06, 12 December 2018 (UTC)

I'm not sure I follow. In your opening statement you write

`iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT` did not work. Now you use

`iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT` ?

Please reconfirm. — Indigo (talk) 19:56, 12 December 2018 (UTC)

Sorry, copy-paste hell, my bad. I will modify the above so there's no confusion. What I mean is that adding a simple rule like so: `iptables -A TCP -p tcp --dport 21 -j ACCEPT` seems to be working with Simple_stateful_firewall setup, at least in my case. -- Soocki 20:06, 12 December 2018 (UTC)

Please don't modify talks after they got a reply in the future. It gets utterly confusing for everyone else trying to follow/reply. Copy-paste errors happen. Have a look at Simple stateful firewall#Bruteforce attacks. It explains about --state NEW in general referred to in the subsection, you miss it in your rule. --Indigo (talk) 20:39, 12 December 2018 (UTC)

Guide for write-access

Is the following correct?:

Using vsftp with enabled "local user" will give the FTP users access to the whole root.
To limited this you can chroot the user to a personal folder, but only with read permission.
If you want to give your FTP users access to only a personal folder with write-permission you must setup vsftp with virtual users.

If so it should be added in the beginning of the document. Secondly, it would be nice if the guide actually showed a way to setup a "classic" SFTP configuration, where the user only have access to it's own personal folder with write-permission. MrCalvin (talk) 08:06, 16 May 2019 (UTC)

Rare regression bug causing problems with directories containing more than 32 files

I've recently spent an entire day fixing this on my machine and want to conserve it for posterity, in case somebody else runs into the same problem. Not really sure if this belongs into the Wiki article, so I'll deposit it here for now. The printer in question was a Kyocera M5526cdn.

In early 2021, some printers stopped being able to deposit FTP files into directories containing more than 32 files via vsftpd. This is a regression of a nearly 10 year old bug (see https://bugzilla.redhat.com/show_bug.cgi?id=845980). As a workaround insert the following line into your /etc/vsftpd.conf

seccomp_sandbox=NO

Sentenza (talk) 09:15, 03 April 2021 (UTC)